大师Martin Fowler对持续集成（CI）是这样定义的：
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，
通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。
每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。
许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成的宗旨是避免集成问题，如同在极限编程（XP）方法学中描述的集成地狱。
持续集成并非普遍接受是用来改善集成频率的方法，因此重要的是区分两者所带来的效益。
在极限编程方法学，持续集成需要达到最佳成果，必须依靠着自动化集成单元测试并通过测试驱动开发。
首先必须设想在上线运作之前，已在开发环境完成并通过所有的单元测试。
这将帮助避免一个开发者的作业流程，导致其他开发者作业的中断。
如果有需要，可以在完整上线运作之前禁用部分已完成的功能，例如使用功能切换。
接着进行CI服务器建置概念的阐述、自动化运行单元测试的周期与每次测试需要提交给开发者的报告。
建置CI服务器的用途（不一定要运行单元测试）已经开始在极限编程社群之外的团队练习。
如今，许多企业组织已经开始采用持续性集成，而非采用完整的极限编程。
除了自动化单元测试，
组织在运用持续性集成一般会建置CI服务器来维护持续性套用质量控制的程序一小部分的影响，
并且经常性使用。
除了运行单元与集成测试之外，还有额外的静态与动态测试，量测与描述性能，
从程序来源码摘录与文件格式与促成手动质量保证（QA）程序。
持续性质量控制应用程序用意在提升软件质量以及减少交付的时间，
在完成所有开发后，取代传统软件上线质量控制机制。
此非常相似进行频繁集成的最初概念让集成得以在QA程序上更容易地达成。
同样的道理，持续性交付的最佳实践进一步扩展了持续性集成，
以确保软件检核在主要程序上并且能够布署到用户以确保实际的布署流程可以非常快速。