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