持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
一些原则：
1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向版本控制库中提交一次代码。
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5. 每次构建都要100%通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
持续集成周期包括以下几个步骤：
1.持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新。
2.如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。
3.等代码完全更新以后，调用自动化编译脚本，进行代码编译。
4.运行所有的自动化测试。
5.进行代码分析。
6.产生可执行的软件，能够提供给测试人员进行测试。
如果其中任何一个步骤失败，就表示该Build失败，持续集成服务器会给予相应的反馈。一般来说，持续集成服务器会有相应的管理界面，可以看到Build的状态以及相应的信息，如果Build失败，可以查看原因，是编译失败还是测试失败。或者在每次Build后，持续集成服务器发邮件通知，从邮件中可以看到最新Build的状态。当然，也可以自定义反馈方法，比如在ThoughtWorks中国，有个团队的持续集成反馈就是火山灯，黄色表示正在进行Build，绿色表示Build成功，而红色则表示Build失败，一旦发现灯变红了，所有人都不能提交代码，而应该尽快修复该Build。还有一个团队更有创意，用语音来进行反馈。如果Build成功，就会有语言提示说“Build XXXX成功”，如果失败，就会有提示“Build XXXX失败，是由XXX提交的”，被念到名字的成员就得停下来修复这个Build。
持续集成实践的目的不是减少Build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。如果想尝试持续集成，首先需要的是持续集成服务器，比如CruiseControl或者VSTS；然后需要把现有的Build自动化，比如写Ant脚本；最后就是在持续集成服务器上进行配置，比如配置版本控制，集成间隔时间，如何部署，如何反馈等。