Martin Fowler 和 Kent Beck 首次提出 Continuous Integration （简称CI）：
持续集成是一种软件开发实践：许多团队频繁地集成他们的工作，每位成员通常进行日常集成，进而每天会有多种集成。每个集成会由自动的构建（包括测试）来尽可能快地检测错误。许多团队发现这种方法可以显著的减少集成问题并且可以使团队开发更加快捷。
持续集成，让很多开发团队又「 爱 」又「 恨 」。爱，在于整个流程对项目的交付价值大有裨益，尽最大可能地减少不必要的加班；恨，在于成本过大，部署的困难、工程文化的隔阂。
尽早暴露问题，把握开发节奏
在团队开发中，问题暴露的越早，修复代码的成本越低，成功部署的胜算就越大。持续集成高频率地编译、测试、审查、部署项目代码，这其中代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律的集成，以此来确保当前代码库的质量，把握开发的进程和节奏。
当然发现问题代码，也不要一味地坠入快速的简单修复之中，要投入时间和精力保持代码的整洁、敞亮。
很明显的一点，使用持续集成后，程序员们提交代码也会变得更加小心谨慎。想想应该没人乐意让其他同事不停地见到自己的分支上 CI 失败的通知邮件吧
避免重复操作，让流程自动化
工具环境的滞后，加上工作的重复枯燥，让开发者对写程序失去新鲜感。
在持续集成过程，一步一步的编译、测试、审查、部署，牵扯大量重复的工作。搭建持续集成环境，可以让开发人员不再需要手动地 checkout 代码，节省大量的时间和避免不必要的压力，把精力放在更多有价值的事情上，这样也可以形成良性的循环。
保持随时部署，简化发布流程
无论什么样的工程师，都会对存在大量 bug 的代码产生恐惧心理，这就是心理学上的的 Broken Windows 综合症（Broken Windows syndrome）。CI 可以有效防止破窗综合症，让开发团队一点点积累起对产品的信心，对使用技术的保持成就感。
与此同时，持续集成让每个人都能看到良好的界面和视图来了解项目的成熟度，让所有人都知道正在发生什么。也许更容易增强开发信心，培养团队良好的工程文化，齐心协力向目标前进。