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

随着软件部署的愈来愈成熟，敏捷、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 的流程图。

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

---

【参考】

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

持续集成系统的演进之路