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

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

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

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

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

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

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

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

flow.ci

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

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

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

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

flow.ci

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

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

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

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

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

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

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

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

flow.ci

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


【参考】

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

持续集成系统的演进之路

Meng

WeChat: dongmeng412