集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
大师Martin Fowler对持续集成是这样定义的:
持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
一些原则：
1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向版本控制库中提交一次代码。
3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5. 每次构建都要100%通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
