图片

前端工程化体系中的一环:搭建持续集成/部署环境。终于有机会实践出来了。
本文简单地介绍了持续集成/部署的基本概念,着重地讲解了如何基于 Gitlab CI/CD 进行快速地构建持续集成/部署环境,还介绍了其基本功能入门操作流程。

通俗易懂的解释

其实理解这个概念或者功能非常简单,平时我们从开发到上线,一般会经历如下流程:

1
开发(包含版本管理) -> 交付(体验) -> 测试1 -> 构建 -> 测试2 -> 发布(包含部署)

这整个过程就像是流水线一样,那么工厂为了简化劳动力,提升生产效率,一般都会根据自动化工程去构建一套作业流水线,能让机器做的就不让人去参与,因为在某种重复性劳动上来说,机器的出错概率会比人的出错概率低,而且效率会更高,成本会更低。工人只需要参与一些机器无法合理完成的作业即可。

那么我们把这套概念借鉴到我们的软件代码开发上来,那就是构建自动化工程体系。我们只需要关注开发过程、体验过程、测试结果、构建结果以及上线部署的效果即可。上面图示的流程,我们就可以来构建一个自动化工程环境,让机器控制项目自动去跑。

以前我们需要利用 SVN 或者 Git 去进行代码的一系列版本控制,开发完之后还要产品来体验,没问题后交付第一轮测试,通过之后进行手动构建,比如前端就会在项目所在的目录中打开命令行,输入 npm run build 之类的构建打包命令,然后打包出来的产品代码发布到测试环境,供第二轮测试,通过之后,又得在原目录打开命令行,输入 npm run deploy 之类的部署命令,让代码自动上传到正式服务器进行上线部署,有的团队还没有那么方便呢,还得人工手动去把产品代码包拖到远程部署文件夹覆盖掉原来的产品代码进行上线工作。

那么这时候就会涉及到一个问题,就拿前端来说,如果需要修改一处字体的颜色或者一处简单的业务逻辑计算公式,那么我们开发人员又得经历如上的一次操作:切换到分支,然后修改,然后合并到主干,即使免体验免测试,那还得进行构建,然后再发布,这明明是机器可以帮忙完成的事情,为什么还需要我们人为来管控?我们只想「沉浸式开发」,编写更优雅的代码,创造更美好的未来。

所以我们设想只需要进行代码的开发和版本的管理就好了,当我们提交代码的时候,有机器能自动帮我们跑流程,当一切环节通过以后,它还会帮我们部署到正式环境。而当我们进行版本回滚或者再 push 一个微小改动的时候,我们仅仅只需要做版本的控制,后续的流程,机器又自动帮我们干了,线上环境的产品代码自动更新。或许这就可以说是基于版本管理控制的工程自动化体系。

刚好,CI,就是我们想要的东西。

基本概念

持续集成

持续集成并不能消除Bug,而是让它们非常容易发现和改正。—— Martin Fowler

CI: Continous Integration, 即“持续集成”

持续集成指的是,频繁地(一天多次)将代码集成到主干。

其目的就是让产品可以快速迭代,同时还能保持高质量。

其核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

好处如下:

  1. 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易;
  2. 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

持续交付

Continous Delivery, 即“持续交付”

持续交付指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

持续部署

Continous Deployment, 即“持续部署”

持续部署是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别,可以参考下图。

图片

流程说明

以上概念并不局限于是本地仓库还是远程仓库,以下流程也均适用于各种代码仓库的环境。

根据持续集成的设计,代码从提交到生产,整个过程有以下几步。

1. 提交

流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交,(可以是本地仓库也可以是远程仓库,一般来说是push到远程仓库)。

2. 测试

代码仓库对commit操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。

测试有好几种:

  • 单元测试:针对函数或模块的测试
  • 集成测试:针对整体产品的某个功能的测试,又称功能测试
  • 端对端测试:从用户界面直达数据库的全链路测试

第一轮至少要跑跑单元测试。

3. 构建

通过第一轮测试,代码就可以合并进主干,就算可以交付了。交付后,就先进行构建(build),再进入第二轮测试。

所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS脚本、图片)等等。

常见的构建工具:

  • Jenkins
  • Travis
  • Codeship
  • Strider
4. 测试(2nd)

构建完成,理论上就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。

第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。

需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。

5. 部署

通过了第二轮测试,当前代码就是一个可以直接部署的版本。将这个版本的所有文件打包 ( tar filename.tar * ) 存档,发到生产服务器。

生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。

这方面的部署工具有如下:

  • Ansible
  • Chef
  • Puppet

当然很多团队都是没有这么讲究的,而是会直接构建出代码,直接扔到发布目录下,相同文件会进行替换罢了。

6. 回滚

一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。

Gitlab CI/CD

Continous Integration can help catch bugs by running your tests automatically, while Continuous Deployment can help you deliver code to your product environment. ——From Gitlab

持续集成可以通过自动化测试项目来帮助你捕捉bug,而自动化部署可以帮助你提交代码到生产环境

在这里选择 Gitlab 作为我们的远程代码仓库的原因有二:

  1. Gitlab 可以让我们安装到自己的服务器,打造属于我们自己的远程代码仓库集
  2. Gitlab 提供 Gitlab CI 和 Gitlab Runner,能够让我们很好的进行快速集成和发布,而且可视化也完善和强大

图片

GitLab 提供持续集成服务。如果你添加一个 .gitlab-ci.yml 文件到你的仓库的根目录下,并且配置你的 GitLab 项目使用一个 Runner,那么每一次提交或者推送都会触发你的 CI Pipline

.gitlab-ci.yml 文件告诉 GitLab Runner 该做什么。默认情况下,它运行有三个流水线阶段:buildtest,和 deploy。你不需要使用全部三个阶段,没有工作的阶段将被忽略。

如果 CI 服务一切运行正常(没有非零返回值),你会得到一个绿色复选标记与提交记录相关联。在查看代码之前,可以很容易地看到提交是否导致有测试失败。

简而言之,需要有一个工作CI的步骤可以归结为:

  1. 添加.gitlab-ci.yml到您的存储库的根目录
  2. 配置一个跑步者

然后,在每次推送到 Git 仓库时,Runner 将自动启动管道,管道将显示在项目的 Pipelines 页面下。

前提条件:

  1. 你在自己的服务器部署了 Gitlab 实例(version >= 8.0),或者正在使用 Gitlab 官网提供的仓库服务;
  2. 在 Gitlab 中有想使用 CI 的项目

Gitlab CI/CD 中的一些基本概念

在正式使用 Gitlab CI/CD 来搭建持续集成环境之前,来一起疏通一些基本概念。

  • Pipeline
    一次完整的构建任务
  • Stages
    构建任务中,构建阶段的集合
  • Jobs
    构建阶段里,构建工作的集合

Pipeline

一次 Pipeline 其实相当于一次构完整的建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
任何提交或者 Merge Request 的合并都可以触发 Pipeline,如下图所示:

1
2
3
4
5
+------------------+           +----------------+
| | trigger | |
| Commit / MR +---------->+ Pipeline |
| | | |
+------------------+ +----------------+

Stages

Stages 表示构建阶段,说白了就是上面提到的流程

我们可以在一次 Pipeline 中定义多个 Stages,这些 Stages 会有以下特点:

  • 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
  • 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
  • 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败

因此,Stages 和 Pipeline 的关系就是:

1
2
3
4
5
6
7
8
9
+----------------------------------------------------------+
| |
| Pipeline |
| |
| +-----------+ +------------+ +------------+ |
| | Stage 1 |--->| Stage 2 |--->| Stage 3 |--->...|
| +-----------+ +------------+ +------------+ |
| |
+----------------------------------------------------------+

Jobs

Jobs 表示构建工作,表示某个 Stage 里面执行的工作

我们可以在 Stages 里面定义多个 Jobs,这些 Jobs 会有以下特点:

  • 相同 Stage 中的 Jobs 会并行执行
  • 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
  • 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败

所以,Jobs 和 Stage 的关系图就是:

1
2
3
4
5
6
7
8
9
+---------------------------------------------+
| |
| Stage 1 |
| |
| +---------+ +---------+ +---------+ |
| | Job 1 | | Job 2 | | Job 3 | |
| +---------+ +---------+ +---------+ ... |
| |
+---------------------------------------------+

基于 Gitlab CI 搭建持续集成环境

准备 .gitlab-ci.yml 文件

在创建 .gitlab-ci.yml 文件前,我们需要了解下该文件的用途和定位

什么是 .gitlab-ci.yml

.gitlab-ci.yml 文件是你配置CI在您的项目中执行的位置。它存在于你的仓库的根目录。

在任何推送到你的远程仓库时,Gitlab 将根据文件的内容自动查找该.gitlab-ci.yml 文件,如果文件存在,Runners 则会根据该文件的配置启动作业。

由于 .gitlab-ci.yml 文件放在仓库里,所以这个文件是受版本控制的, 旧版本的 .gitlab-ci.yml 仍然能 build 成功。利用 CI 可以很方便的创建 forks, branch(分支) 可拥有不同的 pipelines 和 jobs,并可以从 CI 获取你所期望得到的源码。

创建一份简单的 .gitlab-ci.yml 文件

注意: .gitlab-ci.yml是YAML文件,所以你必须特别注意缩进。总是使用空格,而不是标签。

在项目根目录中新建 .gitlab-ci.yml 文件,然后写上如下的简单内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 定义 stages
stages:
- test
- build
# 定义 job
test: # 这是 Job 的名字,不用与 stage 选项一致,也可以写成 job1
stage: test
script:
- echo "I am job1"
- echo "I am in test stage"
# 定义 job
build:
stage: build
script:
- echo "I am job2"
- echo "I am in build stage"

这是最简单的一个例子,一开始先使用关键字 stages 来声明各个构建阶段,然后用一些非关键字来定义 jobs,每个 job 中使用 stage 关键字来指定该 job 对应哪个构建阶段;而 job 中的 script 关键字对应的内容是最关键的地方,表示每个 job 需要执行的命令。

Jobs 的运行顺序会按照 stages 关键字所定义的顺序来,所以会先执行 test 任务,然后再执行 build 任务,预测结果如下:

1
2
3
4
I am job1
I am in test stage
I am job2
I am in build stage

好了,到这里你一定有疑问,谁来执行这些任务,谁来运行这些脚本的?!答案就是 Gitlab Runner!如果我们的代码使托管在 Gitlab 官方平台上的话,那么就可以继续看下一小节,使用官方提供的 Shared Runners 共享的构建客户端来体验运行一下;否则就可以跳过下一节。

使用 Gitlab Inc 提供的 Shared Runners 体验

在项目的 设置 -> CI/CD 页面中,如下图启用 Shared Runners:
图片

然后推送构建配置文件 .gitlab-ci.yml

1
2
3
$ git add .gitlab-ci.yml
$ git commit -m "Add .gitlab-ci.yml"
$ git push origin master

推送完成后,到 CI/CD 面板中查看构建状态:
图片

点击每个 Job 还可以看到终端交互情况。

常用的关键字

我们先把 .gitlab-ci.yml 中的关键字大概过一遍,有点印象,在下一章节我们再来着重看 Gitlab Runner

下面介绍一些常用的关键字,想要更加详尽的内容请前往官方文档
关键字官方文档地址:https://docs.gitlab.com/ce/ci/yaml/README.html

stages

定义 Stages,默认有3个 Stages,分别为:build, test, deploy
顾名思义:

  • build
    构建阶段
  • test
    测试阶段
  • deploy
    部署阶段
types(Deprecated)

Stages 的别名

before_script

定义任何 Jobs 运行前都会执行的命令。

after_script

要求 GitLab 8.7+ 和 GitLab Runner 1.2+

定义任何 Jobs 运行完后都会执行的命令。

variables && Job.variables

要求 GitLab Runner 0.5.0+

定义环境变量。
如果定义了 Job 级别的环境变量的话,该 Job 会优先使用 Job 级别的环境变量。

cache && Job.cache

要求 GitLab Runner 0.7.0+

定义需要缓存的文件。
每个 Job 开始的时候,Runner 都会删掉 .gitignore 里面的文件。
如果有些文件 (如 node_modules/) 需要多个 Jobs 共用的话,我们只能让每个 Job 都先执行一遍 npm install
这样很不方便,因此我们需要对这些文件进行缓存。缓存了的文件除了可以跨 Jobs 使用外,还可以跨 Pipeline 使用。

Job.script

定义 Job 要运行的命令,必填项。

Job.stage

定义 Job 的 stage,默认为 test。

Job.artifacts

定义 Job 中生成的附件。
当该 Job 运行成功后,生成的文件可以作为附件 (如生成的二进制文件) 保留下来,打包发送到 GitLab,之后我们可以在 GitLab 的项目页面下下载该附件。

Gitlab Runner

在上一章节说道谁来运行 .gitlab-ci.yml 中的任务呢?那就是这章节要讲的 Gitlab Runner了。

或者你会在想,为什么不是由 Gitlab CI 来完成那些任务,而是还要再提炼出一个 Gitlab Runner呢?
一般来说,构建任务都会占用很多的系统资源 (譬如编译代码),而 Gitlab CI 又是 GitLab 的一部分,如果由 Gitlab CI 来运行构建任务的话,在执行构建任务的时候,GitLab 的性能会大幅下降。

Gitlab CI 最大的作用是管理各个项目的构建状态,因此,运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做拉!

因为 GitLab Runner 可以安装到不同的机器上,所以在构建任务运行期间并不会影响到 GitLab 的性能。
比如说我们用的是官方网站 gitlab.com 提供的代码存储、版本管理以及 CI 服务,然后 GitLab Runner 可以安装到我们自己的线上 linux 服务器,类似地,我安装在了自己购买的阿里云 ECS 服务器,我在上面安装了一份 gitlab runner 的程序,并且在 gitlab.com 和 自己的服务器都进行了相关设置,当 CI 服务解析 .gitlab-ci.yml 文件上的任务时,它就会通知部署了 runner 的服务器去执行指定的相关任务,逻辑很简单很清晰。

概念

GitLab Runner 是一个开源项目, 它用来运行你定制的任务(jobs)并把结果返回给 GitLab。 GitLab Runner 配合GitLab CI(GitLab 内置的持续集成服务) 协调完成任务。

GitLab Runner 是由 Go 语言开发的,可以作为一个独立的二进制程序运行, 所以它没有特定语言的环境需求。

Runner 可运行在 GNU/Linux, macOS 和 Windows 操作系统上。 如果是其他平台的操作系统,只要你编译一个 Go 的二进制程序, 也是可以运行的。如果你想用 Docker 运行 Runer , 请确保 [Docker 的版本][dockerrepos]不低于 v1.5.0

安装

其实安装挺简单的,官方文档上就根据宿主机的不同提供了多种安装方式,在这里讲两种,没有涉及到相关机型的同学,可以根据以下网址自己去看安装教程(“Install GitLab Runner” 一节)。

https://docs.gitlab.com/runner/

在这里要注意一点:有同学可能会在网上看到安装 gitlab-ci-multi-runner 的,不用怀疑,这是 <10 的版本,安装="">=10 的新版本就是以下我写的方式,官网文档中有安装旧版本的方式,有需要的同学可以去看看。

Important: With GitLab Runner 10, the executable was renamed to gitlab-runner. If you want to install a version prior to GitLab Runner 10, visit the old docs.

推荐安装方式

使用 YUM/APT 仓库安装 Runner

首先,添加 GitLab’s 官方仓库:

1
2
3
4
5
# For Debian/Ubuntu/Mint
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# For RHEL/CentOS/Fedora
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

然后安装:

1
2
3
4
5
# For Debian/Ubuntu/Mint
$ sudo apt-get install gitlab-runner

# For RHEL/CentOS/Fedora
$ sudo yum install gitlab-runner

手动下载安装及更新方式

手动下载二进制包进行安装

说实话我更推荐这种方式,我的阿里云ECS服务器,Ubuntu 14.04 LTS 32位系统,更换了 N 个包源,且苦于不是 64 位系统,用不上清华大学的 gitlab runner 安装包镜像,最后选用这种方式,却是又快又顺畅。

下载相对于的二进制编译包:

1
2
3
4
5
6
7
8
# Linux x86-64
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Linux x86
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386

# Linux arm
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm

增加文件执行权限:

1
$ sudo chmod +x /usr/local/bin/gitlab-runner

为系统创建一个 Gitlab Runner 用户:

1
$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

安装并以服务形式运行:

1
2
$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
$ sudo gitlab-runner start

至此安装完成。

如果日后想更新安装包,同以下操作即可。
停止 gitlab runner 在本机上的运行:

1
$ sudo gitlab-runner stop

下载最新的包:

1
2
3
4
# Linux x86-64
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386
# Linux x86
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

添加可执行权限:

1
$ sudo chmod +x /usr/local/bin/gitlab-runner

启动服务:

1
$ sudo gitlab-runner start

注册 Runner

注册 Runner 就是把 Runner 绑定到一个 GitLab 实例的过程。

为什么还要注册 Runner 呢?Gitlab 实例上提供 CI 服务,我们的机器上安装提供 Runner, CI 服务被启用后需要通知 Runner 开始执行任务,所以注册就是让 Runner 和 Gitlab CI 建立其连接方式的过程。

这里只提供在 GNU/Linux 上注册 Runner 的步骤,如果想在 Mac 或 Windows 下注册的话,请参考官网文档。

Step 1: 打开在 Gitlab 实例上的项目主页,然后进入到项目设置下的 CI/CD 页
图片
把 token 记录下来

Step 2: 在 Gitlab Runner 宿主机上运行注册命令,并根据问题完成交互设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 运行注册命令
$ sudo gitlab-runner register
# 提示输入 GitLab 实例 URL:
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
# 尖角符号和空格符号不要输入,只是做个输入与输出的区分,比如说我们用的就是官方网站的实例进行代码托管的
> https://gitlab.com
# 提示输入用于注册的 token
Please enter the gitlab-ci token for this runner
# 把 Step 1 中获取到的 Token 输入就好
> <token码>
# 提示输入对该 runner 的描述
Please enter the gitlab-ci description for this runner
# 输入名字
> [hostame] my-runner
# 提示输入该 runner 的标签,并以逗号分隔
Please enter the gitlab-ci tags for this runner (comma separated):
# 输入一些标签
> my-tag,another-tag
# 选择 Runner 是否接收未指定 tags 的任务(默认值:false)
Whether to run untagged jobs [true/false]:
# 我们选 true
> [false]: true
# 选择是否为当前项目锁定该 Runner
Whether to lock Runner to current project [true/false]:
# 我们选 true
> [true]: true
# 提示输入 Runner Excutor
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
# 我们一般用 shell 就好,看个人
> shell
# 至此,注册流程结束

当注册号 Runner 之后,可以用相关命令来查看各个 Runner 的状态:

1
2
3
$ sudo gitlab-runner list
Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml
irm-cybertron Executor=shell Token=<你的token> URL=https://gitlab.com/

推送 .gitlab-ci.yml 文件到远程仓库

如果在上面已经经历过 “使用 Gitlab Inc 提供的 Shared Runners 体验” 一节的话,这节可以忽略了,因为你们都掌握了

1
2
3
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master

然后到 Gitlab 实例网站上的 CI/CD 面板即可查看构建状态,如下图:
图片

点击每个 Job 还可以看到终端交互情况。

实战例子

下面贴出一个比较基本的实战例子,我自己是用过的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# 定义 stages
stages:
- install_deps
- test
- build
- deploy
# 设置缓存
cache:
key: ${CI_COMMIT_REF_NAME}
paths:
- node_modules/
- dist/
# 定义 job
install_deps:
stage: install_deps
only:
- develop
- master
script:
- npm install
# 定义 job
test:
stage: test
script:
- echo "STAGE test:\n\t test job is empty for now."
# 定义 job
build:
stage: build
only:
- develop
- master
script:
- npm run dll-build
# 定义 job
deploy:
stage: deploy
only:
- master
script:
- bash scripts/deploy.sh

上面的配置把一次完整的 Pipeline 分成了四个阶段:

  • 安装依赖(install_deps)
  • 运行测试(test)
  • 编译(build)
  • 部署正式服务器(deploy)

设置缓存的原因之前有说过,每一次 Job 开始的时候,.gitignore 文件中忽略的文件或文件夹都会被删除,为了提高速度和避免重复安装,所以把 node_modules/ 文件夹与 dist/ 文件夹加入缓存中。

设置 Job.only 是为了对应到 developmatser 上的提交时,才执行对应的 Job。炒鸡人性化!

这是我自己的小项目所用的,所以就没有涉及到测试以及部署到测试服务器,大家可以自行发挥。

福利:启用构建邮件通知

Gitlab CI 提高了一些 Service, 比如邮件通知,可以配置一系列接受邮件的地址和是否只有成功或失败的时候才发送邮件。

如下图示进入配置邮件通知的页面:
图片

如图注解进行配置:
图片

然后重新触发 pipeline,根据刚才设置的情况下就有邮件通知了!

参考链接

歪果仁对 CI 的解释:
https://codeship.com/continuous-integration-essentials

Gitlab 官方文档集合:
Gitlab CI/CD 文档入口页(中文版)
Gitlab CI/CD 文档入口页(英文版)
.gitlab-ci.yml 的 jobs 配置项说明
GitLab CI/CD 的一些预定义变量
https://about.gitlab.com/features/gitlab-ci-cd/
https://docs.gitlab.com/runner/

教程:
https://scarletsky.github.io/2016/07/29/use-gitlab-ci-for-continuous-integration/