持续集成

持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

真正的持续集成:

好处:

特点

流程

构建

代码提交到代码仓库后,触发Hook,通知集成服务器拉取最新代码进行构建

测试

部署之后,就会根据源代码的类型准备环境并运行相关测试

持续集成不应该运行太久,所以不应该运行重量级的测试,只有在基础功能验证的基础上,结合与本次 CI 的变更点相关的测试任务,发现问题的概率才会大大提升

部署

将构建完成之后的工件发布到服务器上,以供访问

构建提速

弹性

为了要实现弹性扩缩容,需要考虑构建环境依赖等的准备,这点在虚拟机中就很麻烦,如果使用容器化,则可以针对不同技术栈定义通用镜像,降低环境的维护成本,最后,想要弹起来,还要依靠一些容器调度实现slave节点的扩缩容

可持续集成的提交

为了达到每次提交都能进行构建集成的地步,开发人员就要对自己编写的代码做出良好的规划,分解出若干小的任务,而且任务最好是按照一个功能的端到端的场景来划分,而不要按技术层级去划分,是一种迭代式的演进过程

构建流水线与持续集成

把一个复杂的构建流程分成许多个阶段,称之为构建流水线,不仅能更早地发现错误,而且可以很好地反映软件的质量

持续集成流水线

分级构建

对构建进行分级,把那些执行速度快、反馈质量高的步骤放到一级构建中,将执行速度慢的步骤放到次级构建环节,这样就能较早发现问题并改正

工件晋级

流水线的产物是artifact,不同的测试环境有各自的artifact库,当一个artifact满足了相应环境的要求后,就可以晋级到这个环境中

持续部署

署的频率越高,每次部署的风险和成本也越低,部署时间和 Bug 修复的时间也越少

实际部署到生产环境之前肯定需要一定的人工卡点,如引入必要的检查以及人工测试来做最后的兜底保障

持续部署的一些要素:

  1. 自动部署
  2. 低风险发布 主要是通过[灰度发布](/运维/灰度发布.html)与回滚实现

持续集成工具