集成软件的过程不是新问题。在一个人开发的项目中，依赖外部系统又比较少的话，软件集成不会成为太大的问题，但是随着项目复杂度的增加（即使只增加一个人），就会对集成和确保软件组件能够一起工作提出更多的要求——要早集成，常集成。等到项目快结束时才来集成会导致各种各样的软件品质问题，解决这些问题代价很大，常常会导致项目延期。
一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次——这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快的检测出集成错误。许多团队发现，这个过程会大大减少集成问题，让团队能够更快地开发出一致的软件。
根据我的经验，这意味着：
(1)所有开发者都先在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。
(2)开发者每天至少向版本控制库提交一次代码。
(3)集成构建每天在一台独立的计算机上进行多次。
(4)每次构建都必须100%通过测试。
(5)生成可以进行功能测试的产品（如WAR、可执行程序等）。
(6)修复失败的构建是优先级最高的事情。
(7)某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。
以上是我对于项目持续集成的一点看法，希望能够起到抛砖引玉的作用，欢迎大家一起来讨论。
作者：薛云霞
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30047842/viewspace-1429494/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/30047842/viewspace-1429494/
833
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
