警告：小心被假持续集成骗了

刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI，可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成（CI）过程中的一些错觉，然而这些并不是真正的CI实践。

基于持续集成，我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的，为什么我们建议你“暂缓或谨慎使用”，以及预防伪CI的方法。

持续集成

我最喜欢的CI定义来自于continuousdelivery.com

CI开发人员定期（至少每天）将他们所有的工作集成到主干（也称为主线或主干分支）

这个引用中暗含了CI实践的两个基本原则。

第一个是“把他们所有的工作集成到主干”; 第二个是“至少每天”。

对于CI还有一系列其他原则和实践，例如：将所有内容都检入您的代码库，构建每个提交，自动化构建，保持快速构建，并有可以自我验证的代码， 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。

我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。

伪CI是什么样的?

这是我们调研到的一个故事，一位经验丰富的开发人员（让我们称他为David）来自湾区的一个中型创业公司，每周有两次产品交付。

David说他的组织正在践行CI，他说：“是的，我们用Circle CI”，他描述了一个具有挑战性的场景，曾经在一个分支上工作了一段时间，大约修改了100个文件和7000行代码，然后在代码审查阶段就开始招架不住了，因为他要向他的同事解释所有的代码变更的原因。

“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里，因为它们都是这个组件的一部分”，他解释说：“我希望有一个更好的方式来分解这些提交，因为很难把所有事情(变更历史)记在脑子里。”

如果这个情况你听起来很熟悉，那么你也在做伪CI。 如果有下面的这些场景，那么你们就是在做伪CI:

当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具

在我们的调查中，只有10％的参与者承认有CI服务器与CI践行不一样。 相反，90％的个人表示他们正在践行CI，无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”，这就清楚地表明是在做“伪CI”。

使用长期开发分支，但不会定期检入master主干

在David的故事中，他们并没有实践每天检入master主干，这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式，其中团队在master主干上运行CI，但不频繁构建，也不是每天都在提交。 或者他们在分支上运行CI，但不会频繁的集成到master主干。 只对特性分支运行CI，其实应该称之为持续隔离(continuous isolation)才对.

合并分支时感到焦虑和疲惫

真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”，或是“我的错误导致构建被破坏”，而是“我们的代码”和“我们的失败”。

David遇到焦虑和疲惫的事实清楚地表明，他忽略了CI的一个重要的优势：持续反馈和代码集体所有权。

伪CI还有更多的一些现象，虽然我们发现有一些并不那么常见，但它们仍然存在一些问题,

1. 构建的时候，仅有极少的测试覆盖
2. 允许构建长时间处于失败状态

虽然David的团队引入了一个备受尊崇的CI工具和常见的流程，如特征分支和代码审查，但他们并没有实施全套CI实践，因此错过了许多好处。 我们遗憾的发现，在我们的研究的组织中90％发生了这种情况。

一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈，代码集体所有权，并准备达成持续交付

如何避免，预防和解决伪CI的问题?

如果您确定可能正在遭受伪CI之苦，则可以通过三种方式来解决问题并进行持续改变。

1. 提交更频繁

回到根本，尽量频繁地提交，每天至少提交一次应该是最低目标。 如果你还没有开始做CI，这就是你可以开始的地方，即使你在做CI，依然会有改进的空间。

我喜欢“频率降低难度”的说法。 往往我们在做一些事情时，任务变得越小，则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支，至少每天集成一次”。

2. 基于主干分支开发

有很多论坛在讨论基于主干还是基于开发分支进行开发，我不想讨论那些血淋淋的细节。 然而，在我们的调研中，当我们与一些曾经在实践CI过程中感到痛苦的人交谈时，没有引入主干开发的团队对此有更深刻的感受。

DevOps现状调查报告-2016 还发现，基于主干开发和持续集成是达成持续交付的关键因素，同时也能建设更高效能的团队。

基于主干的开发肯定会有一定的挑战，但它可以把问题提前暴露出来，而不是要等到代码合并、代码审查甚至到延迟发布的时候。

如果你想达到更好效果的CI和CD，我建议在主干上做开发，或者如果你更愿意使用短周期的临时分支（合并到主干之前不到一天）进行开发，那么最好同时不要超过三个以上的活跃分支。

3. 自动化

自动化是做好持续集成的基石，所以如果你还没有自动化一切，现在是开始的好时机。 如果你认为已经实现了所有自动化的功能，那么每次有人手动地做任何事情超过一次，便要问自己“这个为什么不能自动化”？ 我已经观察到自动化不仅可以帮助您在CI中变得更好，还可以帮助您开始持续交付。

总结

现在你知道什么是伪CI了，如果你的团队正在这么实践伪CI，那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑，我建议你在Martin Fowler的博客“CI Certification test”做一个测试， 以确认你的组织是否正在做可靠的CI。