不可错过的「持续集成」进阶指南

随着软件部署的越来越成熟，敏捷、 DevOps 、 CI/CD 、 Docker 等词语慢慢出现在工程师的视野中。对于持续集成，业界也没有一个通用的模式，每个团队可能习惯的方式和关注点都不一样。持续集成最关键的在于「持续」与「自动化」，这篇文章根据这两个关键点，将 CI 系统分为四个进阶过程，来看看你们的团队处在哪个阶段。

第一进阶 — 代码级别的集成，这是最初的持续集成

在最初的持续集成过程中，不依赖独立的持续集成工具，一般语言的 build 工具基本内置，比如 java 的 maven/gradle/ant/ivy ， c/c++ 的 make /premake ，同时也会加入代码风格检查，静态代码分析，单元测试调用，测试覆盖率检查等增强功能。接下来的交付准备环境、运行测试、备份旧版本、新版本打标签以及反馈机制等其他重复的事情全由手工完成 ，会花费很多时间。

第二进阶 — 集成 Workflow ，基本实现了真正的持续集成

单一的编译-构建工具逐渐地不能满足产品快速交付的需求。

整个开发流程的重心从「代码级别的集成」转移到了更自动化地编译和更完美的测试验证，致力于在最短的时间内发现问题，缩短开发周期，提高软件质量。比较常见的一个场景，某个团队先进行代码 Build ，触发单元测试、集成测试，打包测试完毕后再自动部署到测试环境，循环往复，形成「编译-构建-测试-集成-部署到测试环境」的 Workflow.

flow.ci 是融入了 workflow 机制的持续集成（ CI ）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程，帮助你们塑造一个更优秀智能的持续集成系统。

第三进阶 — 持续交付与部署，相对成熟的持续集成系统

在上个进阶中，产品是自动部署在测试环境，手动部署在生产环境。之所以这样选择，是因为产品在从需求到部署的过程中，会经历若干种不同的环境，例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，在不同环境中的具体部署是比较复杂的。经常会遇到这么一种场景：明明在测试环境已经部署成功，但线上环境又出现部署故障。这种情况很可能是生产环境和测试环境的异构造成的。

这时候需要改进你的 CI 系统，建立标准化的环境部署顺序，在 Workflow 中增加部署预生产环境并进行灰度集成测试的流程，做好线上环境部署后的回归测试。到这里，已经真正做到了持续交付。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。而“持续部署”，即自动部署到生产环境中而无需手工干预：得到一个版本后，自动部署该版本到生产环境中。实践证明，相对独立快速地部署新功能是一个核心竞争力，可以减轻大规模功能变更的风险。

持续部署，是相对成熟的持续集成系统。

“开发人员提交代码，持续集成服务器获取代码，执行单元测试，根据测试结果决定是否部署到预演环境，如果成功部署到预演环境，进行整体验收测试，如果测试通过，自动部署到产品环境，全程自动化高效运转。”

第四进阶 — 并行多 workflow 集成以及个性化集成，基于 Docker 的持续集成

随着项目和团队规模增长，模块之间依赖关系变得复杂，如何确保代码质量的同时，保证代码构建的一致性和稳定性，成为一大挑战。 Docker 可以方便地以“容器化”的方式部署，它就像集装箱一样，打包了所有依赖，在其他服务器上部署很容易，不至于换服务器后发现各种配置文件散落一地，这样就解决了编译时依赖和运行时依赖的问题。

还有一个问题，开发的分支越来越多，每个活跃分支都进行环境部署和集成测试，对持续集成环境的维护成本也就越高。 Docker 的快速启动和镜像仓库是天生为 CI/CD 设计的，以前启动一个虚拟机需要几分钟，而启动 Docker 只需要几秒钟，让并行的持续集成才能成为可能。

目前，比较常见的基于 Docker 进行持续集成的流程如下：

• 开发者提交代码
• 触发镜像构建
• 构建镜像上传至私有仓库
• 镜像下载至执行机器
• 镜像运行

PS ：目前 flow.ci 尚未支持 Docker. 下图以 Jenkins 作为 CI/CD 的测试运行引擎，在整个持续集成系统中使用 Docker 的流程图。

最后，开发团队面对越来越复杂的环境，需要结合团队的实际情况，定制出适合的方案，不断优化整个自动化开发工作流，从而打造出一套更适合的持续集成系统。

[参考]

谈谈持续集成，持续交付，持续部署之间的区别

持续集成系统的演进之路