一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
上的成员坐在一起，但是经常还会有一些其他人员关心项目的相关事宜。同时对于组织将多个项目的构建信息聚合在一起也是很有用的—可以为不同的项目提供一个简单并且自动的状态。
好的信息展示不仅仅是电脑屏幕上那些。我最喜欢的一个信息展示来自一个使用持续集成的项目上。它在一个很长的时间里不能稳定构建。我们把一整年的日历放到墙上，用一个方框表示一年中的一天。如果QA团队得到一个通过了提交测试的稳定的构建，他们会把一个绿色的贴纸放到这一天的方框里，反之则放一个红的贴纸。随着时间过去，日历揭示了构建过程持续改善的情况，直到绿色的方框越来越多的时候，日历就消失了—因为达到了它的目的。
自动化部署
为了做持续集成，你需要多个环境，一个用来运行提交测试，一个或者多个用来运行第二阶段测试。因为你每天都要在这些环境之间移动可执行文件很多次，所以你希望能自动的做这些事儿。很重要的是你要有一些脚本可以很容易的把应用部署到任意环境中去。
这么做很自然的结果就是你还应该有脚本，以使得你可以同样简单的部署到生产环境。你可能不会每天都部署到生产环境（虽然我曾经参与过这样的项目），但是自动化部署可以帮助你提高速度并且减少错误。这同样是一个便宜的选项，因为这只是使用了你用于部署到测试环境的相同资源。
如果你在生产环境自动部署，那么你需要考虑的一个额外的功能是自动回滚。糟糕的事情随时会发生，如果发臭的棕色物质撞到旋转的金属上（情况不妙），最好能够很快的回到最后一个已知的好的状态。能够自动回滚，可以大大减少部署产生的紧张感，鼓励人们更频繁的部署，因此我们可以更快的把新特性提供给用户。（Ruby on Rails社区开发了一款名为Capistrano的工具，是做此类事情的工具的一个好例子）
在集群环境中我看到滚动部署，新的软件会一次部署到一个节点，然后在几个小时内慢慢将整个应用替换掉。
对于面向大众的网站应用，我接触到的一个很有趣的部署方式是：将一个试用版本部署给部分用户。接着团队可以观察该试用版本是如何被使用的，然后决定是否将其部署给全量用户。这使得你可以在做出最终选择之前测试新特性和用户接口。自动化部署结合良好的持续集成原则，是此工作的重要基础。
持续集成的好处
总起来说我认为持续集成最显著也是最宽泛的好处在于减少了风险。我又想起了在本文第一段中提到的软件项目。团队已经处于一个漫长项目的末期（起码他们是这么认为的），但是还没法判断距离项目真正做完还有多久。
推迟集成的麻烦在于很难预测到底需要多久来做这件事儿，并且更糟糕的是甚至很难看到你在这个过程中的进展。结果就是，即使你是少数几个还没延迟的案例之一，你也会在项目最紧张的部分陷入完全的盲区。
持续集成完全可以解决这个问题。没有了长期的集成，你就可以完全的消除盲区。在所有的时间点上你都会知道你身处何处，什么可以工作，什么不能工作，你的系统里有什么最大的bug。
Bug—也就是那些讨厌的东西，会摧毁我们的信心，破坏我们的计划和声誉。如果已经发布的软件中有缺陷，用户就会对你很生气。而正在进行的工作中有bug，则会挡住你的道路，会使得接下来的工作变得更加困难。
持续集成不会避免bug，但是它可以让你非常容
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
