固定链接 Gitlab CI&CD 在前端项目自动化构建部署中的实践

Gitlab CI&CD 在前端项目自动化构建部署中的实践

Gitlab CI&CD 在前端项目自动化构建部署中的实践

引言

现在大部分的公司都搭建了自己的Gitlab,除了Git的代码管理能力,Gitlab的CI&CD在项目的持续集成和部署上也尽力提高大家的工作效率。下面用我们项目的例子为大家引荐一下这套工具带来的便利。

Gitlab CI&CD是什么

如上官方图示,可以理解为Gitlab给开发者提供了一项功能,在代码提交后自动触发一段开发者自定义的脚本,以此来完成诸如但不限于构建部署的工作。

为什么我们需要使用
1. 项目业务较多,多个业务并行联调或测试(不要问我分支怎么管理的,后面说);
2. 不断有新人进入;
3. 测试机器时常有被更换的风险;
4. 项目依赖包时常会更新,每个人环境的依赖包小版本可能不一致。

因此我们迫切的需要一个新人低成本或零成本的、快速自动化的构建部署方案。

解决方案
1. 为环境指定不同的分支,如dev1 代表联调环境1,test2 代表测试环境
2. testN 代表测试环境N。如下图,各分支与环境的关系

3. 利用Gitlab CI&CD工具执行自动化构建,并根据分支部署到不同机器,如上图,发布到个环境前都经过了CI阶段的自动化构建等操作,线下测试和联调还可以在CD阶段自动部署到对应服务器

执行步骤
1. 在仓库里面配置.gitlab-ci.yml
2. 在可以访问git仓库的服务器部署Runner
3. 在git仓库网页上配置对应的Runner

项目配置

配置文件 .gitlab-ci.yml
在项目的根目录下创建文件.gitlab-ci.yml

Keyword Required Description
script yes CI&CD过程需要执行的shell脚本
stage no 一个job流程,默认test
variables no 定义变量
only no 指定当前job适用的git refs(分支、Tag)列表
except no 与only相反
tags no 通过标签管理或匹配runner
allow_failure no 指定当前job是否容错,正常job失败会跳过后续job流程
before_script no 在当前job执行前执行的shell脚本
after_script no 在当前job执行后执行的shell脚本
when no 依赖的上一个job执行什么状态后执行当前job, on_success on_failure always manual 默认on_success
dependencies no 指定依赖的job列表,默认顺序执行

查看其他可配置属性

如果
– 你的CI Runner的执行环境没有权限访问你们公司的Gitlab仓库(一般使用docker模式的Runner或者项目底下有子模块submodule,且需要在Runner中构建的时候checkout)
– 当前项目构建完后需要部署到其他服务器,或者需要执行sshrsync等需要认证命令时

你需要
– 给你的git仓库账户下添加Runner宿主的SSH Key公钥。注宿主机中创建如何生成我的SSH密钥
– 【推荐】使用ssh-agent来管理你的SSH Key私钥(同上,如公钥id_rsa.pub;对应私钥id_rsa), $SSH_PRIVATE_KEY是在 https://git.xx公司.com/当前仓库/settings/ci_cd下添加Secret variables

在本文中你可以认为ssh-agent是一个用来在ssh会话过程中管理你的ssh私钥,并在git仓库或服务器需要ssh key认证的时候自动提供与对应公钥匹配认证的工具

除了自己配置的变量,Runner也提供了一些 预置变量

shell模式的Runner需要添加

docker模式的Runner可直接关闭ssh登录目标host key检查

CI Runner

安装
Runner的安装比较简单,根据官方流程即可, 以Linux x86-64为例

配置
注册项目

1. 配置项目ci的仓库地址 如下图灰色mask部分2
2. 配置项目唯一标识Token 如下图灰色mask部分3
3. 给当前Runner一个描述,或者命名
4. 配置当前Runner的Tag, 可以多个,tag可以用来管理和关联项目和Runner,以实现部署到不同服务器等

5. Runner的其他属性配置, 也可以在界面配置如下图

6. 配置当前Runner的模式,

成功

如图,配置成功后当你提交代码到对应配置了CI&CD stage的分支,Gitlab就会自动触发执行脚本,当然如图所示,你也可以直接在界面上重试或新建pipelines

一次提交触发一次CI&CD即执行一次脚本对应一个pipeline;一个pipeline对应stages下的所有job;一个stage对应一个job;一个job可以允许失败,比如我们的例子中,每次清除就得docker容器的时候可能失败,因为新机器上没有对应的容器或者其他一些不影响主流程的操作可以添加容错配置。

结语
1. 除了给Gitlab仓库配置CI&CD,同时他也支持其他仓库如Github等;
2. Gitlab也定义了一下API可以结合其他工具来执行CI&CD任务;
3. 如果使用gitlab>=v11的版本还可以根据需要配置Auto DevOps

这是我们使用的例子,如有其他需求和问题可以评论讨论或回复不及时时请查看https://docs.gitlab.com/ee/ci/README.html#advanced-use

本文是滴滴云开源工具教程系列文章的一篇,作者 石联乐

您的留言将激励我们越做越好