持续集成的简单实现

[bydmm]

最近在进行 DevOps 的工作，主要方向是从持续集成做到持续交付。

一个人闷头做事容易走上歧途，于是把我的思路分享出来和大家交流一下

---

全文阅读: https://iqing-dev.gitbooks.io/easy-ci-cd/

全自动的 CI(持续集成) + CD(持续交付)是许多公司所追求的目标。

轻文轻小说技术团队在实际的工作中发现一种比较便捷的去实践 CI+CD 的方法，特此分享。

此方法只依赖阿里云容器服务(Docker)和 Gitlab CI。涉及到的开发和上线流程都高度可定制且不限定于某种特定的语言。

对于使用阿里云容器服务之外的持续交付流程，本书的内容也可以提供一些参考。

2017 年 武汉空文网络科技有限公司出品

1. 在任务分支上开发代码
2. 通过 Merge Request，申请合并
3. 通过对 Gitlab CI 的配置，Merge Request 会触发 Gitlab Runner 去跑自动化任务
4. Gitlab Runner 启动指定的测试专用 Docker 去运行自动化测试
5. 测试通过之后，将代码合并到 master 分支
6. 阿里云容器仓库服务会检测到 master 分支的变更，开始构建新的 docker 镜像
7. 阿里云容器服务会检测到 docker 镜像的变更，然后自动部署

1. 在任务分支上开发代码

最基本的分支管理方案就是不要直接在主分支上做开发。那么从最基本的分支管理策略入手，在任务分支上先进行代码开发。

2. 通过 Merge Request，任务分支申请合并 Master

Merge Request 是 gitlab 的术语，类似于 Github 的 Pull Request。

Merge Request 是两个分支的一次预合并，Gitlab CI 可以对这个预合并后的代码进行测试， 测试完成之后才允许合并到 Master。

这样就可以对 Master 分支进行保护，确保每次合并进来的代码满足预设的一系列条件。

3. 通过对 Gitlab CI 的配置，Merge Request 会触发 Gitlab Runner 去跑自动化测试

Merge Request 产生之后，会产生一个任务。Gitlab Runner 接收到任务后就会去处理。

但是 Gitlab Runner 在这里只是起一个调度的作用，接收到请求后会呼叫 Executor （执行者）去真正的执行编写的自动化任务。

4. Gitlab Runner 启动指定的测试专用 Docker 去运行自动化测试

可以跑 Gitlab 自动化测试的的 Executor 有很多种，这里我们选择了用 Docker 作为 Executor 去跑自动化测试。

运行自动化测试用的 Docker 镜像是可以根据需求自行构建的。启动测试的时候启动这个镜像，跑完之后直接释放掉这个镜像。

这样每次测试的时候都是全新的干净的测试环境。特别当后面的运行环境也跑在 Docker 之内的时候，接近于真实环境的测试更具有优势。

自动化测试不限于单纯的测试，根据需要还可以加上代码风格审查这样的环节。

5. 测试通过之后，将代码合并到 Master 分支

Merge Request 会显示出自动化测试的结果，如果自动化测试通过的话，可以把代码合并到 Master 分支了。

6. 阿里云容器仓库服务会检测到 Master 分支的变更，开始构建新的 Docker 镜像

通过比较简单的配置，阿里云容器仓库服务就可以和私有 Gitlab 整合，从指定仓库的 Master 分支获取代码，然后构建出镜像。

7. 阿里云容器服务会检测到 docker 镜像的变更，然后自动部署

通过比较简单的配置，容器仓库服务在构建完成之后就会触发容器服务的钩子，然后镜像之内的新代码就会有序更新到生产环境中去了。