一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
易找到并消除bug。从这个角度看它很像自测代码。如果你引入了一个bug后能很快检测到它，那么就能很容易改正它。因为你只是对系统做了一个很小的改变，你不用往回追溯太远。因为系统的那一部分正是你刚刚工作过的那一部分，它还很清楚的存在于你的记忆里—这使得查找bug很容易。你还可以使用diff debugging，来对系统的当前版本和没有bug的更早的版本作比较。
Bug也是累积的。你的bug越多，消除每一个bug也就越不容易。一定程度上是因为bug互相影响，表现出来的失败可能是很多错误共同叠加的结果—这就导致很难找到每一个错误。这也是心理上的，当有很多bug的时候，人们自然就缺少激情去找到并解决这些bug—这是一种在《Pragmatic Programmer》一书中被称为“破窗效应”的现象。
因此，使用了持续集成的项目，无论是在生产环境里，还是在开发过程中，其bug的数量将会极大的减少。但是需要强调的是，受益的程度直接取决于你的测试套件的好坏。你应该可以看到，构建一个带来显著差异的测试套件并不是那么困难。当然，通常一个团队真正达到他们可能达成的较低水平的bug程度，需要一定的时间。要达到这个水平意味着需要持续的改善你的工作。
如果你使用了持续集成，它会消除掉频繁部署的一个最大障碍。对于能够为新特性更快的获得反馈来说，频繁部署是有价值的，因为它可以使你的用户很快用上这些新的特性，而且频繁部署可以使他们（开发团队和用户）在开发周期中更加协作。这将有利于打破客户和开发之间的障碍—我认为该障碍是成功的软件开发中最大的障碍。
引入持续集成
所以如果你想要尝试下持续集成的话，从哪儿开始呢？上面我提到的所有的实践可以带给你全部的收益，但是你并不需要一开始就把它们都用上。
这儿其实并没有固定的套路，而是很大程度上依赖于你的配置和团队的现状。但是我们也学到下面的一些经验可以帮助我们把接下来要做的事情搞清楚。
（1）第一步就是把构建自动化。把你所有需要用到的东西都放到源码控制系统中，从而你可以用一条指令来构建整个系统。对于很多项目来说，这并不是一件小事——但是它是其他所有的事情的基础。一开始的时候你可能只是偶尔按需构建，或者只是做自动的每夜构建。当还不是持续集成的时候，自动的每夜构建也是一个很好的开始。
（2）在你的构建中引入一些自动化测试。尝试着识别出问题最多的部分，并且加入自动化测试以暴露这些问题。需要特别指出，在一个现存的项目上非常快的实现一个真正好的测试套件是很困难的—因为需要时间来构建测试。你必须从某个地方开始—毕竟罗马不是一天建成的。
（3）尽量加速提交的构建。构建需要几个小时的持续集成也比没有持续集成要强，但是如果能将这个时间降到10分钟那就太好了。这通常需要对你的代码基础做一些相当大的手术，因为你需要打破对于系统中较慢部分的依赖。
（4）如果你开始一个新的项目，那么从一开始就用持续集成。一直关注构建时间，一旦构建速度变慢，超过10分钟的时候，马上采取行动。通过很快的采取行动，你可以在代码变得太大以至于成为主要的痛点之前进行必要的重构。
最后的思考
在Matt和我写完这个网站上最初的论文后的几年中，持续集成变成了软件开发的一个主流技术。ThoughtWorks的项目中
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
