本文主要是介绍持续集成案例分析系列(1) -- 小规模产品团队的持续集成，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
农历年前，李剑（InfoQ中文站的敏捷社区主编，就是小刀）提议写一些在实际的敏捷软件开发项目中的使用的实践及范例，于是决定将个人的实际项目和咨询经历总结一下。既然现在一直在做“持续集成与发布管理”这一领域的事情，就不再花时间去想题目啦，仅以持续集成为题，将自己在咨询过程中遇到的项目及情况加以总结。
信手拈来的当然就是自己所在的项目“Cruise”了。于是《“持续集成”也需要重构——持续集成实践在Cruise开发过程中的演进》在二月底成文，并在同事Derek、李黓及朋友李剑的帮助下，三月底定稿，并在InfoQ中文站发布。
文中通过对Cruise产品团队自身的持续集成过程与环境的描述，讨论了持续集成的原始动机，以及随时间变化而产生的几种持续集成模式和各自的优缺点。这些模式包括：（1）简单式；（2）阶段式；（3）过程式；（4）管道式。
管道式持续集成形式上与过程化持续集成相类似，但却在概念上有显著不同。在管道式持续集成中，所有的过程单元都运行在同一管道的上下文中，即各单元所使用的原材料都是完成相同的，即代码基线相同。当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行。而每个单元产生的产物也在该管道中有效。
由于Cruise目前还仅属于代码不算太多且无太多依赖关系的独立产品，且团队规模也不算大，其采用的持续集成环境也不算复杂。可以算是小规模产品团队的持续集成方案。仅管如此，但相信对于国内大多数团队来说，可能仍旧达不到这一点。但如果不从“万里长城第一步”开始，可能就永远无法想像持续集成的成果与魅力。
这篇关于持续集成案例分析系列(1) -- 小规模产品团队的持续集成的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
