2019独角兽企业重金招聘Python工程师标准>>> 
/**
* 献给我最尊敬的偶像Martin Fowler
* 原文出处：https://martinfowler.com/bliki/ContinuousIntegrationCertification.html
* @author dogstar.huang <chanzonghuang@gmail.com> 2017-03-22
*/
本翻译已征得Martin Fowler同意，并链接在博客原文下方。
持续集成是软件开发中一项流行的技术。很多开发人员在会议上讨论他们如何使用它，并且持续集成工具在大部分开发组织里很常见。但我们都知道任何正规的技术都需要认证流程 -- 而幸运的是确实存在那么一个。它由持续交付和devops最杰出的专家之一开发而来，以显著快速的管理而闻名，但对其结果非常有见解。尽管它很成熟，但它没有得到应有的流行，所以作为这项技术的粉丝之一，我觉得和读者分享这个认证流程对我来说是件重要的事情。准备好得到持续集成的认证了吗？你会如何处理测试过程中揭露的令人震惊的事实呢？
到现在，我以往的读者会在想他们是不是看到了一篇恶搞的博客 [1]，是的，我的开场戏是有一点搞笑。但是像其他好的笑话一样，在这背后有一个真理的重要核心。对于恰当的持续集成，其创始人是Jez Humble -- 当然他也是持续交付领域主要的专家，这有一个非常好的测试。它同时是一个快速的测试，他经常在演讲期间对观众进行管理。唯一的问题是，我从来没有听过他把这个测试作为认证测试而提起 -- 这表明了他缺少对赚钱模式的远见。
通常，他以询问他的观众如果有进行持续集成就举手来开始这个认证流程。一般大部分观众都会举手。
然后他叫他们如果团队的每个成员至少每天都提交并推送到某个共享的主线（通常共享git里的master分支）则继续举手。
这时，超过一半的手放下了。
接着他叫他们如果每次这样的提交都会触发自动化构建和测试的话则继续举手。剩下的手有一半又放下了。
最后，他再问，当构建失败时，是否通常能在10分钟内恢复到绿色。[2]
经过最后这个问题，只有少数的手还举着。这些观众就是通过了他认证流程的人。
这是一系列简单的问题，但它触及了持续集成的核心。整个概念就是没人会在明显脱离他人的代码库上工作。持续集成意味着团队知道代码当前的状态确切是怎样的，我们避免高风险的合并，并且可以根据需要尽可能地进行重构。
一开始之所以有那么多人举手了，是因为一般的观点是持续集成即意味着对他们的特征分支运行某些“持续集成服务”。但是持续集成 -- 正如作为极限编程的一部分Kent Beck最初描述和命名它那样 -- 与工具无关。在一开始它是一个工作流，并且Jim Shore做了一个它就应该那样的精彩论证。随后出现了为源代码仓库运行一个守护进程的想法，这虽然有用，但只有当它是运行在每日提交的共享的主线上时才算是持续集成。否则运行如此一个守护进程，例如在每个特征分支上，则是后台持续集成（Daemonic Continuous Integration），它偏离了持续集成这一名字 [3]，从而产生一个工作流，不会给你带来使得全部事情都值得付出努力的好处。
扩展阅读
关于持续集成的更多内容，请访问我的主要文章，虽然写于2006年，但对此技术的总结和定义依然适用。Jez explains解释了为什么持续集成是持续交付的基础。在这个页面上他在FAQ问了三个问题。Paul Duvall写了这本关于持续集成权威的书。还有2014年在GOTO芝加哥的Jez管理认证测试视频（遗憾的是没有拍到观众）。
致谢
认证测试的这三个问题归功于Jez，他的演讲我都很喜欢。和Paul Hammant的某次会谈触发我想到了后台持续集成这个术语，我希望它能抓住这个庞然大物中特别恼人的一块。
注解
1：一般来说，我不是软件认证模式的粉丝，因为他们通常不符合认证能力相关性。
2：对于这一步，“绿色”的数量即通过提交构建，传统编译和单元测试的次数。虽然通常我们希望针对发布到生产环境能运行一个完整的部署管道，但在提交构建是绿色后应该有一个能让开发人员良好工作的仓库。你应该让提交构建不超过10分钟，所以如果修复是容易的，快速修复和重新运行提交构建才能工作。如果你修复不了，不能在10分钟内恢复到绿色的提交构建，那么你应该回滚到最后一次绿色构建。
3：后台持续集成的问题导致了有些人使用了基于Trunk的开发这一名字，声称语义扩散已经使得术语“持续集成”变得没有意义。虽然我明白他们的观点，便我相信我们不应该向语义扩散让步，反而我们需要不停重复解释持续集成的应有之义，正如在这种语义扩散下我们应该对待其他术语一样（诸如“敏捷”和“重构”）。
------------------------
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 未本地化版本许可协议进行许可。- 本文翻译作者为：dogstar，发表于艾翻译(itran.cc)；欢迎转载，但请注明出处，谢谢！