持续集成之理论篇

本文作者：CODING 用户 - 何健

持续集成 ？——？

大概数周前，突然有学长问我有没有接触过“持续集成”。

在我脑海中，这是一个陌生的词汇，于是百度了解了一番。实际上有开发和部署经验的小伙伴对持续集成不会非常陌生的，特别是那些喜欢自己写 webhook 的小伙伴。这篇文章来聊聊持续集成。

互联网软件从开发到上线，后续迭代更新，已经有一套近乎标准的流程。其中 持续集成（ Continuous integration，简称 CI ）则是核心流程。像「 CODING 持续集成」也直接支持自定义配置流程。

概念

大师 Martin Fowler 对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

简单说，持续集成就是指频繁自动将代码集成到主干和生产环境，比如「 CODING 持续集成」所实现的功能。

目的

持续集成的目的，快速迭代，保持高质量，避免不必要的成本投入。

优点

1. 快速定位错误，测试环节可以及时暴露问题；
2. 避免大幅度偏离主干，借助统一的代码库；
3. 减少不必要的成本投入，可以自动化解决的重复乏味的事情，没必要浪费人力和时间；
4. 实际上还有很多有点，大家慢慢感受啦~

一般步骤

持续集成的核心措施， 集成到主干前， 自动化测试， 只有通过，才可以集成到主干。

成功集成到主干后，也意味着可以部署上线。 这便牵扯出另外两个相关概念，持续交付、持续部署。

这里一起看一下集成的一般步骤：

1. 设计
2. 开发
3. 测试
4. 发布

每次集成都是这样的步骤，因此持续集成会时这些基本步骤合体的循环，只要项目还在迭代，我们就会不停重复这个步骤。

持续交付 （ Continuous delivery ）

这里借用阮一峰老师的说法：

持续交付（ Continuous delivery ）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

注意，持续交付在自动化测试和集成结束后，不一定会自动部署。如果有自动部署，则是持续部署的概念了。

持续部署 （ continuous deployment ）

持续部署（ continuous deployment ）则是持续交付的下一步，代码通过评审，自动化部署到生产环境。

其目的时可以随时部署，迅速投入生产阶段。

持续部署这一步，意味着产品和观众见面，但是要通过重重考验，测试、构建、部署等步骤，而且每一步都是自动的。

流程

通常如下几步：

1. 提交

就是常见的代码提交到 CODING 仓库

2. 单元测试

这个过程 通常是一个针对 commit 操作的钩子，只要由提交，就会跑自动化测试，测试通过才可以推代码到主干。（这轮测试至少要有单元测试）

常见测试：

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

3. 构建

第一轮测试通过，代码可以成功合并到主干，交付。

那么接下来，就要构建（ build ），进入第二轮测试。

但是，构建并不是绝对必须的过程，构建就是为了让源码变成可以运行的程序或代码。如果是 java、golang 项目，通常要 build 后才可以运行。但如果是 php、python，可能并没有构建过程，只要更新代码到对应的 cgi 容器的工程目录就可以了。

构建过程，我们可以自己写一些脚本和接口，挂到对应的钩子里。当然，也可以用一些成熟的构建工具：

• jenkins （开源免费）
• Travis
• codeship （开源免费）
• Strider
• 「 CODING 持续集成」

4. 全面测试

这轮测试 ，应该是一次全面测试，除了前面提到的自动化测试，还应该包含一些无法自动化测试的部分。如果第一轮测试已经很全面（意味着前一步和第一轮测试合并了，不构建，自然无法全面测试），那么这轮测试可以作为第一轮测试的补集存在。

这里需要注意的是，测试的覆盖率。每次版本更新，更新点都应测试到位。

要素

1. 统一的代码库
2. 自动构建
3. 自动测试
4. 每个人每天都要向代码库主干提交代码
5. 每次代码递交后都会在持续集成服务器上触发一次构建
6. 保证快速构建
7. 模拟生产环境的自动测试
8. 每个人都可以很容易的获取最新可执行的应用程序
9. 每个人都清楚正在发生的状况
10. 自动化的部署

原则

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向版本控制库中提交一次代码。
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4. 需要有专门的集成服务器来执行集成构建，每天要执行多次构建。
5. 每次构建都要 100% 通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
8. 测试是未来，未来是测试

小结

从开发到上线，整体流程：

持续集成——>持续交付——>持续部署

可以用「 CODING 持续集成」进行实践。

Jenkins 和持续集成什么关系

Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

没错，它就是一个具体的持续集成解决方案。基于 Java 实现。 可以实现：

1. 持续版本发布 /测试；
2. 监控外部调用执行的工作；

持续集成和 webhook 什么关系

说到这里，一些有 php 开发经验的小伙伴很容易联想到写 webhook。

没错，php 程序通常由 Http Server （比如 apache2、nginx 等）通过反响代理 fpm-cgi 或者直接内置 cgi 来执行 php 程序。这个过程更像是直接请求了 html 文档。说这里是因为，一些 php 写手为了方便更新线上代码，并不想每次都手动 scp 命令上传新的代码，特别时有时候有些代码可能是有问题的。这时候，大家都想到用版本管理，git 就是很好的选择，其中 github 和 CODING 都是不错的选择。

我们的话题是持续集成，为什么会突然扯到 php 和 git 呢？

那是因为，github 和 CODING 很早就都支持了 webhook 功能。换句话说，我们可以通过开放一个特别的接口，这个接口就一个功能，执行一系列操作，每当接口被调用时，接口可以执行我们预设好的一系列任务指令。这样，我们每次写好代码，只要 push 到仓库，触发 webhook，github 等平台就会去请求我们开放的接口，用来执行更新代码和重启服务等操作。

简单说，我们给服务器上留了一个“小工”，指派给他一个接头人，接到信号就做预先安排好的事儿。

这个过程，是不是很像持续部署最后自动部署的阶段？

没错，就是这样，这个过程很可能时没有自动测试环节，直接自动交付，自动部署。

当然，如果 webhook 写复杂点，完全可以配合一些脚本命令做自己的一套 CI\CD。

总结

CODING 是一个面向开发者的云端开发平台，提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务，其中实现了 DevOps 流程全自动化，为企业提供软件研发全流程管理工具，打通了从团队构建、产品策划、开发测试到部署上线的全过程。「 CODING 持续集成」集成了 Jenkins 等主流企业开发流程工具。