分析持续集成

• 4 分钟

持续集成是 DevOps 八项功能中的一种。

了解持续集成的必要性

1999 年 9 月 23 日，火星气候轨道飞行器收起了其太阳能电池组，以便在暂时下降到火星上层大气中时，可保护其免受损害。

在成功进入轨道后，这个飞行器预计在之后几年会向地球传送火星的照片。 但不幸的是，飞行器在火星大气层中燃烧起来。

由第三方提供的地面控制软件中出现了一个错误，它在计算值时使用了英制单位，即磅秒。 而由 NASA 构建的软件预期该值采用公制单位，即牛顿秒。 由于这些数值没有得到正确换算，在数百万英里的航程中，飞行器定位的微小差异致了严重的后果。

尽管 NASA 当时的编码标准要求使用公制单位，但质量保证部门没有注意到外部软件使用的是英制单位。 由于文件格式错误和其他错误，计算是手工完成的，而不是使用提供的软件完成的。 这种情况就是需要持续集成的一个例子。

探索持续集成

持续集成是一种“思维方式”和“团队策略”。 除此之外，作者兼演讲者马丁·福勒表示，持续集成是一种软件开发实践，在此过程中团队成员会频繁集成他们的工作，通常每个人至少每天集成一次，从而导致每天发生多次集成。

每个集成都通过自动生成（包括测试）进行验证，以尽快检测到集成错误。

如果操作正确，此方法可通过尽早在过程中发现问题来减少集成问题。

持续集成的“目标”是：

• 利用协作
• 实现并行开发
• 最小化集成债务
• 充当质量门
• 使一切自动化！

但是，如果没有持续集成，会发生什么？ 缺乏持续集成通常会导致：

• 长开发周期
  • 非编译代码
  • 在任何时候，源代码都可能出错而无法正常工作
  • 代码冻结
• 生成失败/错误频发
  • 长时存在的分支，造成多日的合并工作
  • 源代码管理中缺少代码
  • 在开发周期后期发现安全漏洞
  • 大量技术债务
  • 无代码或代码覆盖率低
  • 整体质量下降
• 交流和协作受限
  • 代码未遵循编码标准
  • 没有或很少进行代码评审
  • 开发周期后期才进行测试
  • 大多数情况下，甚或完全是手动操作

集成点是用于改进系统的快速反馈循环。 集成点的执行时间出现偏差时，项目会出现问题。 下面是 Dantar Oosterwal 在《精益计算机》一书中对它们的描述：

集成点的主要作用是控制产品的开发。 它们是改进系统的手段。 集成点的执行时间出现偏差时，项目会出现问题。

Dantar Oosterwal，《精益计算机》

© Scaled Agile, Inc.

如果想知道你的团队是否确实在进行持续集成，可借助下面的问题来确认。

• 是否所有开发人员都执行基于 trunk 的开发？
• 是否对 trunk 的每一次更改都会启动生成进程？
• 当生成和测试失败时，团队是否能在几分钟内修复生成？

持续集成的存在与否也会影响性能。 由 Nicole Forsgren、Jez Humble 和 Gene Kim 撰写的《DevOps 科学 - 加速 - 如何构建和扩展高效技术组织》一书中收集和分析的数据显示，当低效执行者进入市场的速度增加时，他们的质量就会下降。

但高效执行者可以在提高进入市场速度的同时保持质量。 他们的部署周期较短（且不太复杂），并使用持续集成来快速解决问题，从而提高流程和效率。