Martin Fowler 和 Kent Beck 首次提出 （简称CI）：

持续集成是一种软件开发实践：许多团队频繁地集成他们的工作，每位成员通常进行日常集成，进而每天会有多种集成。每个集成会由自动的构建（包括测试）来尽可能快地检测错误。许多团队发现这种方法可以显著的减少集成问题并且可以使团队开发更加快捷。

持续集成，让很多开发团队又「 爱 」又「 恨 」。爱，在于整个流程对项目的交付价值大有裨益，尽最大可能地减少不必要的加班；恨，在于成本过大，部署的困难、工程文化的隔阂。

无论你是坚定的持续集成拥护者，中立派，甚至是 CI 反对者，作为一个高效的开发工具，持续集成是一个非常重要特殊的存在。通过这篇文章，我们来看看持续集成的好处有哪些。

尽早暴露问题，把握开发节奏

在团队开发中，问题暴露的越早，修复代码的成本越低，成功部署的胜算就越大。持续集成高频率地编译、测试、审查、部署项目代码，这其中代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律的集成，以此来确保当前代码库的质量，把握开发的进程和节奏。

当然发现问题代码，也不要一味地坠入快速的简单修复之中，要投入时间和精力保持代码的整洁、敞亮。

很明显的一点，使用持续集成后，程序员们提交代码也会变得更加小心谨慎。想想应该没人乐意让其他同事不停地见到自己的分支上 CI 失败的通知邮件吧:)

避免重复操作，让流程自动化

工具环境的滞后，加上工作的重复枯燥，让开发者对写程序失去新鲜感。

在持续集成过程，一步一步的编译、测试、审查、部署，牵扯大量重复的工作。搭建持续集成环境，可以让开发人员不再需要手动地 checkout 代码，节省大量的时间和避免不必要的压力，把精力放在更多有价值的事情上，这样也可以形成良性的循环。

是融入了 workflow 机制的持续集成（CI）服务，也可以理解为自动化流程平台，除了集成代码、编译、测试之外，还可以集成常用的工具、灵活自定义流程。工程师只需要专注写代码，其他的 build, test, deploy 都可以交给 flow.ci 来完成。一切运转起来只需要1分钟!

保持随时部署，简化发布流程

每日高频率的集成保证了项目随时处于可部署运行的状态，如果没有持续集成，项目发布之前将不得不手动地集成，然后花费大量精力修复集成问题，弄的团队成员疲惫不堪。

使用持续集成，帮助我们跨越频繁部署的障碍。大家都知道，只有保持频繁部署，让用户看到产品的新特性， 才能不断地磨合优化构建和发布流程，让反馈周期更短更有效。

包含各种代码质量检测分析和报告的插件，可以轻松地查看项目的测试结果。

增强团队信心，建立工程师文化

无论什么样的工程师，都会对存在大量 bug 的代码产生恐惧心理，这就是心理学上的的 Broken Windows 综合症（Broken Windows syndrome）。CI 可以有效防止，让开发团队一点点积累起对产品的信心，对使用技术的保持成就感。

与此同时，持续集成让每个人都能看到良好的界面和视图来了解项目的成熟度，让所有人都知道正在发生什么。也许更容易增强开发信心，培养团队良好的工程文化，齐心协力向目标前进。

除了上面我们所总结的 CI 的好处， 在文章中有一张图说非常全面，分享给大家：

作为编码规范的度量尺、代码质量的把关者、项目健康的测量仪，CI 可以做的事情还有很多。

欢迎分享你的观点。