一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
的工具，包括FIT、Selenium、Sahi、Watir、FITnesse，还有很多其他工具，我在这里不打算都列出来。
当然，你不能指望测试能发现一切错误。正如人们常说的那样:测试并不能证明没有缺陷。虽然你从自动化测试的构建中得到的反馈并不一定是完美的，经常运行的不完美的测试也比根本不写的完美测试要好得多。
每人每天都向主干提交代码
集成主要是关于沟通的。集成允许开发人员将他们所做的更改告知其他开发人员。频繁的交流能让人们在变化发生时迅速了解情况。
开发人员遵守主干的一个先决条件是，他们可以正确地构建自己的代码。当然，这包括通过构建测试。与任何提交周期一样，开发人员首先更新其工作分支以匹配主干，解决与主干的任何冲突，然后在其本地上构建。如果构建通过，那么他们可以自由地提交到主干上。
通过经常这样做，开发人员可以快速发现两个开发人员之间是否存在冲突。快速修复问题的关键是快速找到它们。由于开发人员每隔几小时就提交一次冲突，所以在冲突生后的几小时内就可以检测到，此刻没有发生太多代码修改，所以容易解决。持续数周不被发现的冲突，可能很难解决。
在更新工作分支时进行构建，这一事实意味着可以同时检测到编译冲突和文本冲突。由于构建是自测试的，所以你还可以检测代码运行中的冲突，如果后一种Bug在代码中存在了很长时间而没有被发现，那么它们是特别难以发现的错误。由于两次提交之间只有几个小时的更改，所以问题隐藏的地方也就只有那么多了。此外，由于没有太大的变化，你可以使用差异调试来帮助你找到错误。
我的一般经验法则是，每个开发人员每天都应该提交到代码库。在实践中，如果开发人员更频繁地提交，通常是有用的。提交的频率越高，寻找冲突错误的地方就越少，解决冲突的速度也就越快。
频繁的提交会鼓励开发人员将他们的工作分解成几个小时的小块。这有助于跟踪进度，并提供一种进度感。通常人们一开始觉得他们不能在几个小时内做一些有意义的事情，但是我们发现指导和练习可以帮助他们学习。
每次提交都应该在集成机器上构建主线
通过使用每日构建，团队可以得到频繁的测试构建。这应该意味着主干保持在健康的状态。然而，在实践中，依然有出错的情况。一个原因是纪律，人们没有在提交之前进行更新和构建。另一个原因是开发人员使用的机器之间的环境差异。
因此，你应该确保常规构建发生在集成机器上，并且只有在此集成构建成功时，才应该认为提交已经完成。由于开发人员对提交的代码负责，所以该开发人员需要监视主干构建，以便在它崩溃时进行修复。这样做的一个推论是，你如果在当天晚些时候提交了一些改动，那么在主干构建通过之前你不能回家。
我见过两种主要的方法来确保这一点：使用手动构建或持续集成服务器。
手工构建方法是描述起来最简单的方法。本质上，它类似于开发人员在提交到存储库前进行的本地构建。开发人员走到集成计算机，签出主线的头部(现在存放他的最后提交)，并开始集成构建。他会密切关注构建的进展，如果构建成功，他就完成了提交。(参见Jim Shore的描述。)
持续集成服务器充当存储库的监视器。每次完成对代码库的提交时，服务器都会自动将源签出到集成机器上，启动构建并将构建的结果通知提交者。直到提交者收到通知
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
