一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
目录
摘要
引言
使用持续集成构建功能
持续集成的实践
维护单一的源代码存储库
构建自动化
如何构建自动化测试
每人每天都向主干提交代码
每次提交都应该在集成机上构建主线
立即修复失败的构建
保持快速构建
在生产环境的克隆中测试
任何人都能轻松获得最新的可执行文件
每个人都可以看到正在发生什么
自动化部署
持续集成的好处
引入持续集成
最后的思考
延伸阅读
摘要
持续集成是一种软件开发实践，团队成员频繁地将他们的工作成果集成在一起，通常每人每天至少提交一次，这样每天就会有多次集成。每次集成都通过自动构建(包括测试)进行验证，以便尽可能快地检测集成错误。许多团队发现这种方法可以显著减少集成问题，并允许团队更快地开发内聚软件。本文简要介绍了持续集成技术及其应用现状。
引言
我清楚地记得我第一次看到一个大型软件项目。那时我在英国一家大型电子公司做暑期实习。我的经理，QA小组的一员，带我参观了一个地方，我们进入了一个令人沮丧的大仓库，里面堆满了立方体。我被告知这个项目已经开发了几年，目前正在集成，并且已经集成了几个月。他告诉我，没有人真正知道完成集成需要多长时间。从中我学到了软件项目的一个共同的故事：集成是一个漫长而不可预测的过程。
其实不需要这样。我在ThoughtWorks的同事和世界上许多其他人所做的大多数项目都不把集成当成一个很严重的事儿。任何单个开发人员的工作都离共享的项目状态只有几个小时，并且可以在几分钟内集成回去。任何集成错误都能被快速发现并得到迅速修正。
这种鲜明的对比并不是昂贵复杂工具的结果。它的本质在于一个简单的实践，也就是团队里的每个人都在频繁的集成，通常是每天对于一个受控的源代码存储库进行集成。
当我向人们描述这一做法时，我通常会发现两种反应：“这里不行”和“这样做不会有多大区别”。人们在尝试的过程中发现，这比听起来容易得多，而且对开发有着巨大的影响。因此，第三种常见的反应是“是的，我们这样做了——没有它你怎么活？”
术语“持续集成”起源于Kent Beck的极限编程开发过程，是最初的12个实践之一。当我开始在ThoughtWorks工作时，作为一名顾问，我鼓励在我工作的项目中使用这种技术。Matthew Foemmel把我模糊的建议变成了实际行动，我们看到了这个项目从罕见而复杂的集成，变为我描述的不是那么严重的事情。Matthew和我在这篇论文的原始版本中写下了我们的经验，这篇论文一直是我网站上最受欢迎的论文之一。
尽管持续集成是一种不需要特殊工具来部署的实践，但我们发现使用持续集成服务器是很有用的。最著名的此类服务器是CruiseControl，这是一个开源工具，最初由ThoughtWorks的几个人构建，现在由一个很大的社区维护。从那时起，出现了其他一些CI服务器，有开源的，也有商用的——包括ThoughtWorks工作室的Cruise。
使用持续集成构建功能
对于我来说，解释什么是CI以及它是如何工作的最简单的方法是展示一个快速的例子，说明它如何与一个小特性的开发一起工作。假设我必须对一个软件添加一点功能，任务是什么并不重要，因为现在我假设它很小，可以在几个小时内完成。（稍后我们将探讨更长的任务和其他问题。）
首先，我将当前集成源代码的副本复制到本地开
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
