持续集成案例分析系列(1) -- 小规模产品团队的持续集成

农历年前,李剑(InfoQ中文站的敏捷社区主编,就是小刀)提议写一些在实际的敏捷软件开发项目中的使用的实践及范例,于是决定将个人的实际项目和咨询经历总结一下。既然现在一直在做“持续集成与发布管理”这一领域的事情,就不再花时间去想题目啦,仅以持续集成为题,将自己在咨询过程中遇到的项目及情况加以总结。

 

信手拈来的当然就是自己所在的项目“Cruise”了。于是《“持续集成”也需要重构——持续集成实践在Cruise开发过程中的演进》在二月底成文,并在同事Derek、李黓及朋友李剑的帮助下,三月底定稿,并在InfoQ中文站发布。

 

文中通过对Cruise产品团队自身的持续集成过程与环境的描述,讨论了持续集成的原始动机,以及随时间变化而产生的几种持续集成模式和各自的优缺点。这些模式包括:(1)简单式;(2)阶段式;(3)过程式;(4)管道式。

 

管道式持续集成形式上与过程化持续集成相类似,但却在概念上有显著不同。在管道式持续集成中,所有的过程单元都运行在同一管道的上下文中,即各单元所使用的原材料都是完成相同的,即代码基线相同。当持续集成服务器发现有新的代码时,会创建新的一个管道,所有的过程单元都在这一个管道中运行。而每个单元产生的产物也在该管道中有效

 

由于Cruise目前还仅属于代码不算太多且无太多依赖关系的独立产品,且团队规模也不算大,其采用的持续集成环境也不算复杂。可以算是小规模产品团队的持续集成方案。仅管如此,但相信对于国内大多数团队来说,可能仍旧达不到这一点。但如果不从“万里长城第一步”开始,可能就永远无法想像持续集成的成果与魅力。

 

你可能感兴趣的:(敏捷,服务器,咨询,产品)