根据「百度百科」的定义
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
重点
编辑 → 发布 → 自动化测试
常见的 CI 软件工具或平台主要覆盖这三个阶段
变化
如今敏捷开发的「兴起」，很大程度上对于持续集成这个模式提出了更高的要求，倘若仍旧停留在 编译、发布、自动化验证 这三个阶段，对于敏捷而言，只是做到了 局部 敏捷，而不是项目/产品敏捷。
因此，要达到真正的 项目/产品敏捷 ，至少要包含以下几阶段:
需求管理 → 编码 → 单元测试 → 代码扫描 → 编译 → 发布 → 自动化测试 → 质量评估
解决方案
有人期望用 JIRA/禅道 这样的工具来完成 需求、缺陷、测试用例 的集中式管理，只能说效果一般般，并且 TA 无法解决全阶段的覆盖。
有人期望用 Jenkins 这样的工具来完成 单元测试、代码扫描、编译、发布、自动化测试，但 TA 完成的只是持续集成中的很小的几个阶段，不用觉得包含了 5 个阶段，就获得了整个 CI，其实差得还很远。
技术层面能解决的，一定是金字塔的最底层。
金字塔中端和顶端的那些，很大程度上仅靠技术是无法解决的，更多的需要经验的传承。
把经验抽象成解决方案，是 持续集成 2.0 的突破点。
抛开工具看本质，当我们不再依赖工具，思考如何徒手解决这些阶段，可能会有不一样的收货。
很多 DevOps 平台对于业务而言，比 Jenkins 的流水线更友好，有些加入了组织权限流程的设计，使其不仅仅是个 CI 工具，但仍旧无法覆盖 持续集成 2.0 的所有阶段。即使现在已有的平台都覆盖全了，也未必实现真正的 持续集成 2.0，因为TA们只提供了技术的解决方案。
而真正的 持续集成 2.0 需要提供一个会思考、会判断的指导。
