【IT168 现场报道】在4月18号举行的全球软件开发大会上，软件敏捷开发专家，Inedo合作伙伴和Daily WTF网站编辑Alex Papadimoulis发表了题为“软件研发，不仅仅是持续集成”的主题演讲。

软件敏捷开发专家▲

　　“持续集成”(CI)一词来源于极限编程(Extreme Programming)，作为它的12个实践之一出现。

　　通过在一个可持续的基础上(比如有代码签入或者计划等特点)，确保代码库是集成的(比如代码经过验证、编译和单元测试等)，持续集成已经变成一种提高软件质量的有效方法。在通往有质量的生产代码的道路上，这确实是伟大的一步，但是也仅限于此：第一步而已!

　　?在实现持续集成的方法中，其实还有一条布满沼泽和坎坷的路，从无休的配置文件，到数据库脚本灾难，到部署自动化等。当代码出现问题时，很多开发者极力推卸责任，说那不是他们的问题，其实真正的专业人士不仅仅会关注自己的代码如何用于生产环节，而且主张最终的产品应该能够反映他们工作的质量如何。

　　?在这个技术中立的分享中，Alex讲述了怎样为实施持续集成打好基础，讨论如何处理研发过程中的技术问题和人员问题(管理、运营等)，并展示一个开发者是如何在软件研发组织中产生巨大的影响的。

　　实际上，持续集成是一个以人为核心的过程。持续集成工具只是在这个过程中我们要用到的一个产品, 而且绝对不是唯一的一个.

　　持续集成的重点就是快速反馈。没有什么比缓慢的 Build 更能危害持续集成活动。对大多数项目来说，极限编程的10分钟 build 的指导方针非常合理。我们现在做的大多数项目都能达到这个要求。这值得花些力气去做，因为你在这里省下的每一分钟都能体现在每个开发者每次提交的时候。持续集成要求频繁提交，所以这积累下来能节省很多时间。

　　持续集成中最重要的是沟通。你需要保证每个人都能轻易看到系统的状态和最新的修改。沟通的最重要的途径之一是 Mainline Build。

　　总之，持续集成最显著也最广泛的益处是降低风险。Bug 让人恶心，它摧毁人的自信，搞乱时间表，还破坏团队形象。已部署软件里的 bug 招致用户的怒气。未完成软件里的 bug 让你接下来的开发工作受阻。持续集成不能防止 bug 的产生，但它能明显让寻找和修改 bug 的工作变简单。从这个方面看，它更像自测试代码。更多精彩，请查看专题http://www.it168.com/remen/qcon/