简单介绍一下Gitlab CI

Gitlab CI 是一个功能非常强大的持续集成系统，有很多不同的功能，而且每次发布都会增加新的功能。它的技术文档也很丰富，但是对那些要在已经配置好的 Gitlab 上使用它的用户来说，它缺乏一个一般性介绍。设计师或者测试人员是无需知道如何通过 Kubernetes 来实现自动伸缩，也无需知道“镜像”和“服务”之间的不同的。

在 fleetster， 我们搭建了自己的 Gitlab 实例，而且我们大量使用了 Gitlab CI。我们的设计师和测试人员也都在用它，也很喜欢用它，它的那些高级功能特别棒。

但是，他仍然需要知道什么是“管道”，知道如何查看部署到一个“环境”中的分支。因此，在本文中，我会尽可能覆盖更多的功能，重点放在最终用户应该如何使用它们上；在过去的几个月里，我向我们团队中的某些人包括开发者讲解了这些功能：不是所有人都知道持续集成(Continuous Integration)（CI）是个什么东西，也不是所有人都用过 Gitlab CI。

如果你想了解为什么持续集成那么重要，我建议阅读一下 这篇文章，至于为什么要选择 Gitlab CI 呢，你可以去看看 Gitlab.com 上的说明。

简介

开发者保存更改代码的动作叫做一次提交(commit)。然后他可以将这次提交推送(push)到 Gitlab 上，这样可以其他开发者就可以复查(review)这些代码了。

Gitlab CI 配置好后，Gitlab 也能对这个提交做出一些处理。该处理的工作由一个运行器(runner)来执行的。所谓运行器基本上就是一台服务器（也可以是其他的东西，比如你的 PC 机，但我们可以简单称其为服务器）。这台服务器执.gitlab-ci.yml 文件中指令，并将执行结果返回给 Gitlab 本身，然后在 Gitlab 的图形化界面上显示出来。

开发者完成一项新功能的开发或完成一个 bug 的修复后（这些动作通常包含了多次的提交），就可以发起一个合并请求(merge request)，团队其他成员则可以在这个合并请求中对代码及其实现进行评论(comment)。

我们随后会看到，由于 Gitlab CI 提供的两大特性，环境(environment) 与 制品(artifact)，使得设计者和测试人员也能（而且真的需要）参与到这个过程中来，提供反馈以及改进意见。

管道(pipeline)

每个推送到 Gitlab 的提交都会产生一个与该提交关联的管道(pipeline)。若一次推送包含了多个提交，则管道与最后那个提交相关联。管道就是一个分成不同阶段(stage)的作业(job)的集合。

同一阶段的所有作业会并发执行（在有足够运行器的前提下），而下一阶段则只会在上一阶段所有作业都运行并返回成功后才会开始。

只要有一个作业失败了，整个管道就失败了。不过我们后面会看到，这其中有一个例外：若某个作业被标注成了手工运行，那么即使失败了也不会让整个管道失败。

阶段则只是对批量的作业的一个逻辑上的划分，若前一个阶段执行失败了，则后一个执行也没什么意义了。比如我们可能有一个构建(build)阶段和一个部署(deploy)阶段，在构建阶段运行所有用于构建应用的作业，而在部署阶段，会部署构建出来的应用程序。而部署一个构建失败的东西是没有什么意义的，不是吗？

同一阶段的作业之间不能有依赖关系，但它们可以依赖于前一阶段的作业运行结果。

让我们来看一下 Gitlab 是如何展示阶段与阶段状态的相关信息的。

Gitlab CI 基础知识Gitlab CI 基础知识

pipeline-overview

pipeline-status

作业(job)

作业就是运行器要执行的指令集合。你可以实时地看到作业的输出结果，这样开发者就能知道作业为什么失败了。

作业可以是自动执行的，也就是当推送提交后自动开始执行，也可以手工执行。手工作业必须由某个人手工触发。手工作业也有其独特的作用，比如，实现自动化部署，但只有在有人手工授权的情况下才能开始部署。这是限制哪些人可以运行作业的一种方式，这样只有信赖的人才能进行部署，以继续前面的实例。

作业也可以建构出制品(artifacts)来以供用户下载，比如可以构建出一个 APK 让你来下载，然后在你的设备中进行测试; 通过这种方式，设计者和测试人员都可以下载应用并进行测试，而无需开发人员的帮助。

除了生成制品外，作业也可以部署环境，通常这个环境可以通过 URL 访问，让用户来测试对应的提交。

做作业状态与阶段状态是一样的：实际上，阶段的状态就是继承自作业的。

running-job

制品(Artifacts)

如前所述，作业能够生成制品供用户下载来测试。这个制品可以是任何东西，比如 Windows 上的应用程序，PC 生成的图片，甚至 Android 上的 APK。

那么，假设你是个设计师，被分配了一个合并请求：你需要验证新设计的实现！

要该怎么做呢？

你需要打开该合并请求，下载这个制品，如下图所示。

每个管道从所有作业中搜集所有的制品，而且一个作业中可以有多个制品。当你点击下载按钮时，会有一个下拉框让你选择下载哪个制品。检查之后你就可以评论这个合并请求了。

你也可以从没有合并请求的管道中下载制品

我之所以关注合并请求是因为通常这正是测试人员、设计师和相关人员开始工作的地方。

但是这并不意味着合并请求和管道就是绑死在一起的：虽然它们结合的很好，但两者之间并没有什么关系。

download-artifacts

环境(environment)

类似的，作业可以将某些东西部署到外部服务器上去，以便你可以通过合并请求本身访问这些内容。

如你所见，环境(environment)有一个名字和一个链接。只需点击链接你就能够转至你的应用的部署版本上去了（当前，前提是配置是正确的）。

Gitlab 还有其他一些很酷的环境相关的特性，比如 监控(monitoring)，你可以通过点击环境的名字来查看。