本文主要澄清了敏捷开发、持续集成、持续交付 1.0、持续交付 2.0 、持续部署、DevOps、研发效能七个概念，以便我们在后续相关工作和实践中能清楚地辨别。

一张图区分

上图涉及各个概念的范围和主要区别，更细致的区别请见下面拆解。从上图中我们可以得到研发效能主要关注点还是在产品研发这个环节，不涉及市场。当然对于如果作为一个 ToB 业务，那么市场环节就很重要。国内还是有几个做得不错的研发效能相关产品。

写作初衷

软件开发领域从不缺新概念。各种概念层出不穷，不只行业之外的人看到之后会懵逼，业内人士自己也很烦，本来很简单的事变复杂了，也许这也是保持行业活跃度的一种方式。

本着「少些概念解决问题，脚踏实地躬身入局」的原则，之前写了一些关于研发效能领域实践的文章，写完之后我一般用的标签是「研发效能」「持续集成」「持续交付」「DevOps」，这样就让本来很简单的一件事复杂了很多。文章为啥关联这么多标签？到底是关于哪方面的文章？最后觉得还是要解释下相关概念，梳理下概念之间的关系，这样才有助于我们建立整个知识体系，这就是写此篇的目的。

敏捷开发

定义

• 凡是符合敏捷开发十二原则的方法均都是敏捷开发方法。它是一系列软件开发方法的集合，而不是某一种特殊的软件开发方法。

目标

• 1）更早地交付价值

• 2）有效学习和灵活响应变化

细品

• 敏捷开发强调了团队成员的积极主动性和一些原则框架，提倡了一些好的机制，但是在具体执行落地上看是比较粗的。所以你可以认为敏捷开发是一个十二个小筐组成的大筐，能装到十二小筐里的都是敏捷开发。

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

持续集成

定义

• 持续集成是在团队协作中将所有开发人员的代码频繁地(一天内多次)合并入同一条主干不断集成，让团队感知到最新修改内容的工程实践。

目标

• 快速发现集成问题快速修复，同时让团队成员对代码变更有感知。

细品

• 持续集成这个实践还是非常具体可实操的。提高了工作节奏、工作进度可感知、协作更紧密

Continuous integration is a software development practice where members of a team use a version control system and frequently integrate their work to the main branch. Each change is built and verified to detect integration errors as quickly as possible.

Continuous integration is focused on automatically building and testing code to check that the application is not broken whenever new commits are integrated into the main branch.

持续部署

定义

• 持续部署是代码提交通过评审，经过自动化构建、测试后立刻自动部署到生产环境中的工程实践。

目标

• 代码在任何时候都是可以部署到生产环境的。自动化构建、自动化测试、自动化验证是保证其能持续部署代码到生产环境的基本条件和前提。

细品

• 首先「持续部署」这个缩写容易引起歧义，这里的「持续部署」确切的含义指的是「持续部署到生产环境」。

• 部署到生产环境可能受到诸多因素影响，比如额外的文档准备、数据库变更、配置变更、上线窗口等，所以强调质量保证通过不需要人工审批直接部署到生产环境意义不大。如果涉及到合规，是否需要人工审批这点也值得商榷。

• 持续部署到生产环境中意义不大，但是持续部署到生产环境并发布意义非常大，因为即便部署到了生产环境也并不意味着产品的发布、价值的交付。功能开关、流量管控都是一些控制用户访问的技术手段。如果功能都部署到生产环境却长时间又不对外发布，会给生产环境带来了很大的风险和不稳定性，这是我们不提倡的。

DevOps

定义

DevOps 是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps 运动的主要特点是倡导对构建软件的从集成、测试、发布、部署、基础架构管理等所有环节的全面自动化和监控。

目标

DevOps 的目标是缩短开发周期，提高部署频率和更可靠的发布，与业务目标保持一致。

细品

• DevOps 也很广，一旦涉及文化，很多都说不清。

• 我认为它所倡导的产品研发各环节全面自动化和监控是非常有先进性的，某种程度上说促进了各个公司产研基础设施的建设和升级。解决产研问题的思路从靠规范、流程约束升级到了靠工具、靠平台来自动化完成，促进了产研基础设施的建设。DevOps 把产研基础设施从拿几款开源程序搭建解决单点问题的时代提升到了整合工具解决领域问题，这是很大的进步。

持续交付 1.0

定义

• 持续交付是可持续、安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用的工程实践。

目标

• 持续部署代码变更到生产环境并交付的工程实践

细品

• 持续交付 1.0 是持续集成实践的一个延伸，把代码变动后自动部署到测试/生产环境的流程进行了标准化、自动化。

• 我个人觉得持续交付 1.0 明确提出的「可持续方式、安全快速地把代码变更部署到生产环境、让用户使用」是之前很多概念所没有的。之前的很多最佳实践更多关注代码编写、构建和测试的环节，而持续交付 1.0 把这个环节延展到了生产环境。

• 只有部署到生产环境交付给用户使用的功能才真正地有价值。写了很多需求文档、编写了很多代码、测试用例，但是只要没有真正的部署到生产环境，让用户用到，其实可以认为「零价值」，考虑到成本甚至是「负价值」。我们把这种代码长时间停留在研发和测试环境不上线的行为称之为「等着下小崽」。要是真可以下小崽也不错，实际上代码长时间停留在研发和测试环境维护成本非常高，每次回归不但要验证下新部署的功能，还要判断/验证下新部署的功能是否破坏了长时间停留在环境中的功能是否也正常，如果部署顺序有依赖，代码上、配置上有冲突的问题会更复杂。

• 持续交付 1.0 和持续部署的区别是，持续部署强调了代码经过评审和自动化测试「立刻」「不需要审批自动」地部署到生产环境；而持续交付 1.0 强调了持续把代码部署到生产环境的能力，至于是「是否立刻」「是否需要审批」则未必。另外持续交付包含了发布产品，也就是交付产品价值这个阶段，这是持续部署所没有的。很多文章都说持续部署是持续交付更进一步的做法，把部署生产环境也自动执行了，实质上欠妥。

Continuous delivery is a software development methodology where the release process is automated. Every software change is automatically built, tested, and deployed to production.

Before the final push to production, a person, an automated test, or a business rule decides when the final push should occur. Although every successful software change can be immediately released to production with continuous delivery, not all changes need to be released right away.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

持续交付 2.0

定义

• 持续交付 2.0 是一种产品研发管理思维框架，将精益创业与持续交付 1.0 相结合，强调业务与 IT 间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式、高质量、低成本、无风险地快速交付客户价值。

细品

• 持续交付 2.0 把精益创业部分纳入了进来，升级成了一种产品研发管理思维框架。这是很大的进步，让我们可以站在更高的维度审视我们做的事情。

研发效能

定义

• 研发效能是一个组织高效交付产品的能力，以及围绕提高这一能力所建立起来的由规范、流程、标准、工具、度量体系、实践等组成的系统工程体系。

目标

• 夯实产品研发基础设施，赋能组织持续高质高效地交付产品价值。

细品

• 研发效能包括规范制定、流程优化、工具建设、研发度量和实践这五个方面。后面的文章我会针对这五个方面一一阐述。

总结

研发效能是组织高效交付产品的能力及支撑其能力所建立的系统工程体系。持续集成和持续交付 1.0 都是比较好的工程实践，持续部署对于规模比较小的产品还是很有积极作用，但是对于规模较大功能复杂的产品使用度较低。至于敏捷软件开发里面的很多原则还是很不错的，我觉得要实行这些原则对人对团队的要求还是很高的，可以秉着脚踏实地、支持业务发展的大方向谨慎试行。

感兴趣的朋友可以加我微信，后续会加到「研发效能群」大家一起交流。关注 scmroad 公众号，了解最新研发效能发展动向。