持续集成与集体代码所有权实践指南
1. 持续集成服务器
开源持续集成服务器（CI 服务器）拥有活跃的社区，其中 CruiseControl 是先驱，由 ThoughtWorks 员工开创。CI 服务器会在代码提交后自动启动构建，若构建失败则通知团队。
不过，使用 CI 服务器存在一些常见误区：
- 有人试图用 CI 服务器替代之前讨论的持续集成脚本，但没有集成令牌时，团队成员可能会意外检出未经验证的代码。
- 还有人用 CI 服务器来促使团队成员改进构建实践，但这只有在大家真心愿意提交高质量代码时才有效，否则可能适得其反。
如果团队成员坐在一起且构建速度快，就无需 CI 服务器带来的额外复杂性，直接走到集成机器前启动构建即可，这比 CI 服务器检测到提交的时间还短，还能活动身体。若安装了 CI 服务器，也别让它分散注意力，应专注于掌握持续集成实践，而非工具本身。要频繁集成，绝不破坏构建，并保持发布基础设施的更新。
2. 引入持续集成
采用持续集成的关键在于让团队成员同意频繁集成（每几小时一次）且绝不破坏构建，因为无法强制人们不破坏构建。
-新项目：若在全新项目中采用极限编程（XP），持续集成很容易实现。在第一次迭代时安装版本控制系统，随着第一个故事引入 10 分钟构建，并与应用的其他部分一起完善发布基础设施。只要坚持这些好习惯，整个项目都能顺利进行持续集成。
-现有项目：若将 XP 引入现有项目，测试和构建可能还不足以支持持续集成。可先自动化构建（参考“10 分钟构建”），再添加测试，逐步完善发布基础设施，直到能随
