一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
——通常是一封电子邮件——它才算完成。
在ThoughtWorks，我们是持续集成服务器的忠实粉丝——事实上，我们领导了CruiseControl和CruiseControl.NET的起初的开发，他们是被广泛使用的开源CI服务器。从那时起，我们还建立了商业版的Cruise CI服务器。我们几乎在每个项目上都使用CI服务器，并且对结果非常满意。
并不是所有人都喜欢使用CI服务器。吉姆·肖尔(Jim Shore)对他为什么更喜欢手工方法给出了一个颇有争议的描述。我同意他的观点，CI不仅仅是安装一些软件。这里的所有实践都需要有效地进行持续集成。但是，同样有许多优秀的CI团队发现CI服务器是一个有用的工具。
许多组织按照定时计划进行定期构建，比如每天晚上。这与持续构建不同，对于持续集成来说还不够。持续集成的全部意义在于尽快发现问题。夜间构建意味着bug在被发现之前一整天都没有被发现。一旦它们在系统中存在了那么长时间，就需要花费很长时间才能找到并修复它们。
立即修复失败的构建
做持续构建非常关键的一点就是一旦主线构建失败就要立即修改它。使用CI的意义就在于，你总是能在已知稳定基础上进行开发。主线构建失败是常有的事，且也并不是什么坏事，但这却能够表明人们在提交代码之前对本地的更新和构建不够小心。然而，当主线构建确实中断时，快速修复它就变得极为重要。
我记得Kent Beck说过一句话：“没有人拥有比修复失败的构建更高的优先级任务”。但也不必团队中的每个人都必须停止他们手头的工作来修改失败的构建，通常只需要几个人就可以成功修复。我们要有意识的将修复构建作为一个紧急的、高优先级的任务进行优先排序。
通常，修复构建的最快方法是从主线还原到最新一次已知的、良好的构建提交状态。当然，团队不应该在构建失败的主线上进行任何调试。除非失败的原因很明显，否则只需恢复主线然后在开发工作站上调试问题。
为了避免破坏主线，你可以考虑使用pending head。
当团队引入CI时，这通常是最难解决的问题之一。在早期，团队很难养成处理主线构建的常规习惯，特别是在处理现有代码库时。耐心和坚持不懈的努力看起来确实经常起作用，，所以不要气馁。
保持快速构建
持续集成的关键是提供快速的反馈。没有什么比一个需要很长时间的构建更能危害CI的活动了。在这里我必须承认有一些古怪的老员工把长时间的构建当成娱乐。我的大多数同事认为一个需要一个小时的构建是完全不合理的。我记得一些团队梦想着他们能以如此之快的速度完成任务——但是有时候我们仍然会遇到这样的情况：很难以这样的速度完成任务。
然而，对于大多数项目来说，十分钟构建的XP指导方针是完全合理的。现在我们的大多数项目都实现了这一点。这值得我们集中精力来实现它，因为每减少一分钟的构建时间，那么对于每个开发人员的每次提交都会节省一分钟的时间。由于CI需要频繁提交，这就会增加很多的时间。
如果你一开始就需要一个小时的构建时间，那么获得更快的构建可能会让人畏惧。甚至在一个新的项目上工作，并思考如何让事情保持快速也会让人畏惧。至少对于企业应用程序，我们发现通常的瓶颈是测试——特别是涉及外部服务（如数据库）的测试。
最关键的一步是开始建立部署流水线。部署流水线（也称为构建流水线或分
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
