个人持续集成——最大化利用资源
实际问题
测试越来越多，运行时间越来越长。开发人员在本地执行单元测试的时候，开发人员就要看着屏幕等待吗？
解决方案
在PairStation上安装一个虚拟机，在其上建立自己的代码仓库。需要运行测试时，把PairStation物理机器的代码提交到这个虚拟机的代码仓库中，并让其运行测试。然后，继续在PairStation上写代码。如图所示：
利弊分析
益处显而易见，节省时间，提高开发效率。团队（至少个人）要使用分布式版本控制系统。另外，用于开发的物理机性能不能太差。其实，这也算不上大问题，因为在你开发软件时，思考的时间应该多于你写代码的时间。
小结
在敏捷团队中，我们所要做的只不过是：不断的回顾、找出问题与瓶颈、不断地重构。通过不断重构持续集成基础结构以及自动化构建脚本，使其达到我们对“反馈时间”和“判断质量准确性”的要求。
另外，我们已将“持续集成”扩展到整个软件开发周期，涵盖了持续部署及发布。在上面的配置文件中，细心的你会发现最后的两个Stage分别名为 “UAT”和“Production”，它们一个用于部署新版本到我们自己的持续集成服务器，另一个用于部署新版本到一个公用的持续集成服务器。部署 ‘UAT’的频率为两天到一周之间，‘Production’的频率为一周。这样，我们可以得到快速反馈，改进自己的产品，同时其它团队可以尽早地使用我们开发的新功能。
持续集成并不是一蹴而就的工作，需要根据团队的实际情况来实施（但这并不能成会“偷赖”的另一个说法）。仅管Cruise团队的持续集成尚属“简单”之列，但并不能说明复杂项目无法做持续集成。俗语道，“没有做不到，只有想不到”。只要不断反思与重构，一样可以硕果累累。
注：这些持续集成方式早有出处，例如2004年的《通过“产物依赖”实现企业级持续集成》，而Cruise团队仅是勇于实践者，并进行着不断的思考和优化。
相关阅读：
