一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
发机器上。我通过使用源代码管理系统，从主干签出一个工作副本来实现这一点。
上面那段话对于使用源代码控制系统的人来说是有意义的，但是对于不使用源代码控制系统的人来说是胡言乱语。所以让我快速地为后者解释一下。源代码控制系统将项目的所有源代码保存在存储库中。系统的当前状态通常称为“主干”。开发人员可以随时在自己的机器上生成主干的受控副本，这称为“签出”。开发人员机器上的副本称为“工作副本”。（大多数情况下，你实际上是把你的工作副本更新到主干上——实际上和签出也是一样的。）
现在我拿着我的工作副本，做任何我需要做的事情来完成我的任务。这将包括修改产品代码，以及添加或更改自动化测试。持续集成假定软件中有高度自动化的测试：我称之为自测试代码的工具。它们通常使用流行的XUnit测试框架的一个版本。
当我完成之后（通常在我工作的不同阶段），我就在我的开发机器上执行一个自动化的构建。这将获取工作副本中的源代码，将其编译并链接到可执行文件中，然后运行自动测试。只有在所有的构建和测试都没有错误的情况下，整个构建才被认为是正确的。
有了正确的构建，我就可以考虑将更改提交到存储库中。当然，问题是，在我有机会提交我的更改之前，其他人可能，而且通常已经对主干进行了更改。因此，首先我用他们的更改来更新我的工作副本，并重新构建。如果他们的更改与我的更改冲突，在编译或测试中将显示为失败。在这种情况下，我的责任是修复这个问题，并重复构建，直到我可以建立一个与主干正确同步的工作副本。
一旦我自己构建了一个正确同步的工作副本，最终我就可以将我的更改提交到主干中，之后会更新存储库。
然而，我的提交并没有完成我的工作。此时，我们再次构建，但这次是在基于主干代码的集成服务器上。只有当这个构建成功时，我们才能说我的更改已经完成。因为总有万一，我可能会遗漏了我的机器上的东西，存储库没有得到适当的更新。只有当我提交的更改在集成服务器上成功构建时，我的工作才能完成。这个集成构建可以由我手动执行，也可以由Cruise自动完成。
如果两个开发人员之间发生冲突，通常会在第二个提交的开发人员构建其更新的工作副本时捕获冲突。否则，集成构建将失败。无论哪种方式，错误都会被快速检测到。此时，最重要的任务是修复它，并使构建重新正常工作。在持续集成环境中，不应该让失败的集成构建保持在失败状态太久。一个好的团队一天应该有很多正确的构建。不好的构建时有发生，但应该迅速被修复。
这样做的结果是，有一个稳定的软件，工作正常，包含很少的错误。每个人都是从这个共享的稳定的基础上开发的，从来没有离开这个基础太远，以至于需要很长时间才能集成回来。寻找错误会花更少的时间，因为错误很快就会显现出来。
持续集成的实践
上面的故事是关于CI的概述，以及它在日常生活中是如何工作的。显然，让所有这些工作顺利进行并不仅仅是这些。我现在将重点介绍构成有效CI的关键实践。
维护单一的源代码存储库
软件项目涉及许多需要组合在一起才能构建产品的文件。跟踪所有这些文件，是一项重要的工作，特别是当有多人参与时。因此，我们毫不意外的看到，多年来，软件开发团队已经构建了管理所有这
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
