持续集成认证

持续集成是软件开发中一种流行的技术。在各种会议上，许多开发者都会谈论他们是如何使用它的，而且持续集成工具在大多数开发组织中都很常见。但我们都知道，任何像样的技术都需要一个认证项目——幸运的是，确实存在这样一个项目。它由持续交付和DevOps领域的一位顶级专家开发，以管理速度快、结果见解深刻而闻名。虽然它已经相当成熟，但它的知名度还不够高，因此作为该技术的粉丝，我认为有必要与我的读者分享这个认证项目。你准备好获得持续集成认证了吗？你将如何面对测试揭示的惊人真相？

到目前为止，我的老读者们可能想知道他们是否看到了一篇恶搞文章 [1]，是的，我在开头的这段文字里开了一个小玩笑。但就像任何好笑话一样，其中也蕴含着重要的真相。确实存在一个由 Jez Humble 创建的非常棒的持续集成测试——他无疑是 持续交付 领域的领军专家。这也是一个快速测试，他经常在演讲中对听众进行测试。唯一的问题是，我从未听他把它称为认证测试——这恰恰显示出他在赚钱计划上的缺乏远见。

他通常会在认证过程开始时，让听众举手示意他们是否在做持续集成。通常情况下，大多数听众都会举手。

然后，他会要求那些团队中每个人都至少每天提交并推送到共享主线（通常是Git中的共享主分支）的人继续举手。

超过一半的人放下了手。

然后，他会要求那些每次提交都会触发自动构建和测试的人继续举手。剩下的举手者中又有一半放下了手。

最后，他会问，当构建失败时，是否通常能在十分钟内恢复到绿色状态。 [2]

问完最后一个问题后，只有少数人还举着手。这些人就是通过他认证测试的人。

这只是一组简单的问题，但却触及了持续集成的核心。持续集成的核心思想是，没有人会在一个与其他人代码库有很大偏差的代码库上工作。持续集成意味着团队知道代码的真实当前状态，我们避免了高风险的大规模合并，人们可以根据需要进行尽可能多的重构。

之所以有那么多人在一开始就举手，是因为人们普遍认为持续集成就是在他们的功能分支上运行一些“持续集成服务器”。但持续集成——正如Kent Beck最初在 极限编程 中描述和命名的那样——与工具无关。一开始，它是一个人工工作流程，Jim Shore 曾提出一个很好的论点，认为它就应该是这样。在源代码仓库上运行守护进程的想法是后来才出现的，虽然它很有帮助，但只有在每天都提交到共享主线的情况下，它才算是持续集成。否则，在每个 功能分支 上运行这样的进程，就是 CI 形式主义，它贬低了这个名称的含义 [3]，导致工作流程无法给你带来好处，而这些好处才是这一切努力的意义所在。