目录

1、定义

2、核心理念

3、持续集成涵盖的三个阶段

3.1 第一阶段：每次提交触发完整的流水线（快速集成）

3.2 第二阶段：每次流水线触发自动化测试（质量内建）

3.3 第三阶段：出了问题可以在第一时间修复

4、总结

CI：Continuous Integration （持续集成），集成什么？为什么要持续？

1、定义

Martin Fowler一篇博客中定义了持续集成：它是一种软件开发实践，团队成员频繁地将他们的工作成果集成到一起（通常每人每天至少提交一次，这样每天就会有多次集成），并且在每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早地发现集成问题。

2、核心理念

持续集成的核心理念是：越是痛苦的事情，就要越频繁地做。持续集成越靠后做风险越大，不确定性越大。把集成的频率提高，让每次集成的内容减少，这样可以快速定位和修复问题，降低了最后阶段的返工所带来的浪费，提升了软件交付效率和质量。

3、持续集成涵盖的三个阶段

3.1 第一阶段：每次提交触发完整的流水线（快速集成）

  这一阶段的关键是快速集成，这也是对CI 核心理念的最好诠释。如果想做到每次提交都触发持续集成的话，首先就需要打通版本控制系统和持续集成系统，其次实施提交触发流水线，还需要如下前置条件。
（1）统一的分支策略
CI 的目的是集成，那么首先就需要有一条以集成为目的的分支。这条分支可以是研发主线，也可以是专门的集成分支，一旦这条分支上发生任何变更，就会触发相应的 CI 过程。那么，可能有人会问，很多时候开发都是在特性分支或者版本分支上进行，难道这些分支上的提交就不要经过 CI 环节了吗？这就引出了第 2 个前置条件。
（2）清晰的集成规则
对于研发特性分支而言，目的主要是快速验证和反馈，那么速度就是不可忽视的因素，所以这个层面的持续集成，主要以验证打包和代码质量为主；而对于系统集成分支而言，它的目的不仅是验证打包和代码质量，还要关注接口和业务层面的正确性。所以，根据分支策略选择合适的集成规则，对于 CI 的有效运转来说非常重要。
（3）标准化的资源池
资源池作为 CI 的基础设施，首先资源池需要实现环境标准化，也就是任何任务在任何节点都具备可运行的能力；其次资源池的并发吞吐量应该可以满足集中提交的场景，可以动态按需初始化资源池；最后还要兼顾成本因素，如果大量资源的投入没有被有效利用，会造成巨大浪费。
（4）足够快的反馈周期
CI 的运行速度是一个需要纳入监控的重要指标，它需要环境、平台、开发团队共同维护。对于不同的系统要约定能够容忍的 CI 最大时长，如果超过这个时长同样会导致 CI 失败。

3.2 第二阶段：每次流水线触发自动化测试（质量内建）

这一阶段的关键词是质量内建。CI 的目的是尽早发现问题，包括构建失败和质量不达标。这一阶段我们主要关注以下几点。
（1）匹配合适的测试活动
对于不同层级的 CI 需要根据集成规则来确定需要注入的质量活动。比如，最初级的提交集成快速的代码检查和冒烟测试即可；对于系统层的集成，质量要求会更高，接口测试、UI 测试等就可以纳入到 CI 。
（2）树立测试结果的公信度
我们要对 CI 失败进行分类分级，重点关注那些异常和误报的情况，并进行相应的持续优化和改善。
（3）提升测试活动的有效性
在最短的时间内运行最有效的测试任务。在基础功能验证的基础上，结合与本次 CI 的变更点相关的任务进行测试。

3.3 第三阶段：出了问题可以在第一时间修复

    首先，人不是关键，建立机制才是关键。机制就是一种约定，人们愿意遵守这样的行为，并且做了会得到好处。对于 CI 而言，保证集成主线的可用性，其实就是团队成员间的一种约定。这不在于谁出的问题谁去修复，而在于我们是否能够保证 CI 的稳定性，足够清楚问题的降级路径，并且主动关注、分析和推动问题解决。
    其次，团队要建立清晰的规则，比如 10 分钟内没有修复则自动回滚代码，比如当 CI“亮红灯”的时候，团队不再提交新的代码，因为在错误的基础上没有办法验证新的提交，这时需要集体放下手中的工作，共同恢复 CI 的状态。

4、总结

真正让 CI 发挥价值的关键，在于团队面对持续集成的态度，以及团队内是否建立了持续集成的文化。

参考原文：12 | 持续集成：你说的CI和我说的CI是一回事吗？-极客时间