持续集成
持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。
- 持续集成的一个主要作用是保证新提交的代码与已有代码进行集成
真正的持续集成:
- 代码应该频繁地被集成
- 应该有测试来验证正确性
- 构建失败后的第一任务是修复失败
好处:
- 自动化集成部署,提高了集成效率
- 更快的修复问题
- 更快的进行交付
- 提高了产品质量
特点
- 它是一个自动化的周期性的集成测试过程,从检出代码、编译构建、运行测试、结果 记录、测试统计等都是自动完成的,无需人工干预
- 需要有专门的集成服务器来执行集成构建
- 需要有代码托管工具支持
流程
构建
代码提交到代码仓库后,触发Hook,通知集成服务器拉取最新代码进行构建
测试
部署之后,就会根据源代码的类型准备环境并运行相关测试
- 单元测试(必需的)
- 集成测试
- 端到端测试(自动化UI测试等)
持续集成不应该运行太久,所以不应该运行重量级的测试,只有在基础功能验证的基础上,结合与本次 CI 的变更点相关的测试任务,发现问题的概率才会大大提升
部署
将构建完成之后的工件发布到服务器上,以供访问
构建提速
- 硬件资源 根据构建特点,有针对性地升级硬件资源,是最简单粗暴的方法
- 私有仓库 从外网下载一些代码或者依赖的速度往往是瓶颈,使用自建仓库提速
- 本地缓存 增量构建极大提升了构建效率,本地三方依赖缓存也能减少网络开销
- 规范构建流程 对于某些流程,可以异步穿插到流水线,减少整体等待时间
- 合理利用构建工具
- 像maven加大内存、跳过单测、-T 2C 命令进行并行构建等
弹性
- 构建软件像 Jenkins 可以支持高可用部署,即一个master带多个slave,再同时部署多个master
为了要实现弹性扩缩容,需要考虑构建环境依赖等的准备,这点在虚拟机中就很麻烦,如果使用容器化,则可以针对不同技术栈定义通用镜像,降低环境的维护成本,最后,想要弹起来,还要依靠一些容器调度实现slave节点的扩缩容
可持续集成的提交
为了达到每次提交都能进行构建集成的地步,开发人员就要对自己编写的代码做出良好的规划,分解出若干小的任务,而且任务最好是按照一个功能的端到端的场景来划分,而不要按技术层级去划分,是一种迭代式的演进过程
构建流水线与持续集成
把一个复杂的构建流程分成许多个阶段,称之为构建流水线,不仅能更早地发现错误,而且可以很好地反映软件的质量
- 持续交付(CD)基于以上概念,它频繁地将软件的新版本,交付给质量团队或者用户,以供评审
分级构建
对构建进行分级,把那些执行速度快、反馈质量高的步骤放到一级构建中,将执行速度慢的步骤放到次级构建环节,这样就能较早发现问题并改正
工件晋级
流水线的产物是artifact,不同的测试环境有各自的artifact库,当一个artifact满足了相应环境的要求后,就可以晋级到这个环境中
持续部署
- 在持续交付的基础上,把部署到生产环境的过程自动化
署的频率越高,每次部署的风险和成本也越低,部署时间和 Bug 修复的时间也越少
实际部署到生产环境之前肯定需要一定的人工卡点,如引入必要的检查以及人工测试来做最后的兜底保障
持续部署的一些要素:
- 自动部署
- 低风险发布 主要是通过[灰度发布](/运维/灰度发布.html)与回滚实现
持续集成工具
- jenkins 可私有化部署
- travis-ci
- github action
- ...