在敏捷领域中，测试驱动和持续集成被称为敏捷编程的两大基石
对于一个微型程序来说，阶段式的集成或许是最佳方法
易于定位错误。也就是当你的持续集成失败了，说明你新加的代码或者修改的代码引起了错误，这样你很容易的就可以知道到底是谁犯了错误，可以找谁来讨论。
及早在项目里取得系统级的成果。因为代码已经被集成起来了，所以即使整个系统还不是那么可用，但至少你和你的团队都已经可以看到它已经在那了。改善对进度的控制。这点非常明显，如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。改善客户关系。理由同上。更加充分地测试系统中的各个单元。这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。能在更短的时间里建造整个系统。这点恐怕要你实施以后才能得出结论。就我们而言，持续集成并没有为每个项目都缩短时间，但却比没有实施时，项目更加可控，也更加有保证。便于开发流程的管理。比如说，要把一个开发的build提交给测试组作测试，测完满意了，再提交到发布组去发布。
保持随时部署，简化发布流程
有了这些以后，开发工作开始了，我们每天的代码在下班前都提交到subversion里去，第二天，Development Configuration就自动的编译完成了，并且发送通知给我们。我们通常会会开一个Morning Meeting，首先我们会到在QuickBuild的页面上，看到昨天有哪些个改动，测试的状况，比如说哪些测试修正了，哪些测试还没有被修正，哪些source code没有通过代码检查。然后我们会点到具体的报告中去分析，这些报告都可以很容易的打开source code，我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。
