XP的一个最佳实践(看看gigix翻的Martin Fowler的文章)
关键:完全的自动化,读取源代码、编译、连接、测试，整个过程都应该自动完成。
与每日构建的区别 (每日构建（daily build）是你的朋友)
-
持续集成强调集成频率。目前的最佳时间是每小时就集成一次，每日构建顾名思义；
-
持续集成强调及时反馈。每日构建目的是为了等到稳定的发布版本，而持续集成主要目的是为了集成失败后及时向开发人员反馈，当然，集成成功之后便是稳定的发布版本；
-
持续集成鼓励开发人员尽快提交(check in)代码并反馈，每日构建不含次内容；
思考:可以说持续集成是每日创建的升级版，但是对大部分团队(至少我们是这样)每日集成一次已经足够。当然，能以每小时为集成单位的团队战斗力是相当惊人的。
传统方式将项目分成若干个模块，开发完成之后进行集成。导致了项目早期存在的BUG在集成测试之后才被发现，由于集成阶段的复杂程度相对较大，排查和解决这些问题需要耗费大量人力，甚至出现无法解决的硬伤。于是，频繁的臭虫会议(bug meetings)成为相互推诿、扯蛋的无聊会议。持续集成通过频繁构建来尽量的发现集成测试之前的BUG，并反馈。
思考:持续集成以测试技术为基础，能否检测出BUG取决于是否有足够的单元测试用例。如果没有良好的测试技术，持续集成和每日构建无异。另，我认为持续集成还能发现单元测试的不充分之处，发现关联模块引用的测试不充分。这样就能一定程度上解决修复了一个BUG之后带来了一个新的BUG。即在集成阶段还保持对单元的有效测试。
问题：界面的单元测试？最终还是需要集成、回归测试来实现。持续集成对于集成阶段的好处？
目前我们的做法仅仅是有个配置管理员来进行构建，频率也不高，仅在每次版本发布前进行。
大家是如何做持续集成的，过程中有没有碰到什么难点。有什么好的经验吗？