根据「百度百科」的定义

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

重点

编辑 → 发布 → 自动化测试
常见的 CI 软件工具或平台主要覆盖这三个阶段

变化

如今敏捷开发的「兴起」，很大程度上对于持续集成这个模式提出了更高的要求，倘若仍旧停留在 编译、发布、自动化验证 这三个阶段，对于敏捷而言，只是做到了 局部 敏捷，而不是项目/产品敏捷。

因此，要达到真正的 项目/产品敏捷 ，至少要包含以下几阶段:

需求管理 → 编码 → 单元测试 → 代码扫描 → 编译 → 发布 → 自动化测试 → 质量评估

解决方案

有人期望用 JIRA/禅道 这样的工具来完成 需求、缺陷、测试用例 的集中式管理，只能说效果一般般，并且 TA 无法解决全阶段的覆盖。

有人期望用 Jenkins 这样的工具来完成 单元测试、代码扫描、编译、发布、自动化测试，但 TA 完成的只是持续集成中的很小的几个阶段，不用觉得包含了 5 个阶段，就获得了整个 CI，其实差得还很远。

技术层面能解决的，一定是金字塔的最底层。

金字塔中端和顶端的那些，很大程度上仅靠技术是无法解决的，更多的需要经验的传承。

把经验抽象成解决方案，是 持续集成 2.0 的突破点。

抛开工具看本质，当我们不再依赖工具，思考如何徒手解决这些阶段，可能会有不一样的收货。

很多 DevOps 平台对于业务而言，比 Jenkins 的流水线更友好，有些加入了组织权限流程的设计，使其不仅仅是个 CI 工具，但仍旧无法覆盖 持续集成 2.0 的所有阶段。即使现在已有的平台都覆盖全了，也未必实现真正的 持续集成 2.0，因为 TA 们只提供了技术的解决方案。

而真正的 持续集成 2.0 需要提供一个会思考、会判断的指导。