（一）持续交付的定义与价值

原文链接：https://time.geekbang.org/column/104

持续交付的定义

持续交付是软件研发人员，如何将一个好点子以最快速度交付给用户的方法。————《持续交付：发布可靠软件的系统方法》
一套软件工程方法和许许多多的最佳实践的集合————马丁 · 福勒

#### 熟知了定义和方法论，其实也还是无法落地，因为大家所贡献的最佳实践才是持续交付理论的核心。只有真正在工作中贯彻和使用这些实践工具，才能体会持续交付真正的含义和作用。 持续交付能提高研发效率。
### 推行持续交付的三个难点 1、难以推进。需要团队从上至下的支持，可能会引起大量的技术和组织的变革，影响整个研发周期，涉及流程、团队、工具等多个方面。需要将一些黑箱操作公开，以便大家监督。 2、人才难寻。要求实施者与参与者了解开发、流程、测试、运维、甚至需要一定的架构、管理知识。 3、效果难以度量。持续交付是一个持续迭代的过程，需要多次循环才能体现效果。在实施初期，因为开发习惯和流程变化，团队在适应的过程中效率会有暂时下降。
### 持续交付实施过程中要注意的问题 1、切勿过度强调自动化，并非只有自动化才算“持续”。 2、切勿过度强调流程化，持续交付不需要强流程来管控。 3、切勿过低强调特殊化，如经常听到，我们的工程师能力特别强，我们的团队有特殊的工作方式，我们的系统有不同的设计，这些往往成了拒绝“持续交付”的借口 4、“持续交付”必须以平台化的思想去看待，单点突破是无力的 5、“持续交付”的实施，要顺应技术的变迁，善于利用技术红利 6、“持续交付”与系统架构、运维体系息息相关
### “持续交付”的主要组件 1、配置管理： 2、环境管理： 3、构建集成： 4、测试管理：
### 持续集成、持续交付和持续部署的关系 通常会把软件研发工作拆解，拆分成不同模块或不同团队进行编码，编码完成后，进行集成构建和测试。这个从编码到构建再到测试的反复持续过程，就叫做持续集成。 持续集成一旦完成，则代表产品处在一个可交付状态，但不代表这是最优状态，还需根据外部使用者的反馈逐步优化。这里的使用者可能是测试、产品、用户、领导等。

这个在持续集成之后，获取外部对软件的反馈再通过持续集成进行优化的过程就叫做持续交付，它是持续集成的自然延续。

传统安装型软件，要现场调试。要用户购买等等，其难度可想而知。即使是可达度最高的互联网应用，由于生产环境的多样性（各种软件安装，配置等）、架构的复杂性（分布式，微服务）、影响的广泛性（需要灰度发布）等等，就算产品已是待交付的状态，要真正达到用户可用的标准，还有大量的问题需要解决。

而持续部署就是将可交付产品，快速且安全地交付用户使用的一套方法和系统，它是持续交付的最后一公里。可见，“持续交付”是一个承上启下的过程，它使“持续集成”有了实际业务价值，形成了闭环，而又为将来达到“持续部署”的高级目标做好了铺垫。
虽然从概念上可以这样理解，但从实践和经验上来说，往往是从持续部署(自动化部署)开始推进持续交付，这才是一条优选的路径。

### 持续交付的显性价值 持续交付也称为发布流水线。即研发团队从开发，到测试，再到部署，最终将茶品交付给最终用户使用的过程。  虽然持续交付着重打造的是发布流水线的部分，但它所要达到的目标是在“最终用户”和"研发团队"间建立紧密的反馈环：通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响，“软件价值”，说白了就是收入、日活、GMV等KPI指标。
### 持续交付的隐形价值   
### 如何评估持续交付的价值 1、产品的交付速度是否变快 2、各个自动化过程的速度是否变快，如编译速度、发布速度、回滚速度、自动化测试速度等 3、具象化不可持续点，即整个工程生命周期中有多少被开发人员诟病，或者阻碍开发人员自助处理的问题点，如： a、开发不能按需产生隔离的测试环境 b、生产代码回滚后，要手工处理代码分支 c、预发布（Staging）流量要能自动分离，以便预发布测试

	将所有不可持续点进行记录和分解，通过OKR的考评方式，将消灭这些点作为目标，拆解出来的可行动点，作为关键结果，以这样的方式来完成绩效考评。

#### 持续交付的价值不仅仅局限于简单的提高产品交付效率，它还通过统一标准、规范流程、工具化、自动化等方式影响着整个研发周期。