为什么携程要做好持续交付？

随着云计算、容器等新兴技术的发展，“持续交付”这个老生常谈的问题，忽如一夜春风来，仿佛找到了从理想通向现实的大门。各类相关工具、产品、服务，也是纷纷出现：如 Jenkins 2.0，Jenkins X，阿里云效，Netflix Spinnaker，Jfrog Artifactory 等等。

到底是什么魔力使得各大公司和厂商对“持续交付”如此趋之若鹜？我在携程工作多年，负责系统研发的工作，在持续集成、持续交付方面积累了很多实战经验。关于携程为什么要做好持续交付，持续交付的价值在哪里？我谈谈自己的看法。

你了解持续交付吗？

持续交付，到底是什么意思，它的定义是什么？《持续交付：发布可靠软件的系统方法》一书中把“持续交付”定义为：

持续交付是软件研发人员，如何将一个好点子，以最快的速度交付给用户的方法。

即使熟知了定义和方法论，其实也还是如海市蜃楼一般，无法落地，因为大家所贡献的最佳实践才是持续交付理论的核心。只有真正在工作中贯彻和使用这些实践工具，才能体会持续交付的真正含义和作用。

持续交付的显性价值

持续交付也通常以“发布流水线”的方式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。如下图：

虽然持续交付着重打造的是发布流水线的部分，但它所要达到的目标是在“最终用户”和“研发团队”之间建立紧密的反馈环：通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。

这里说的“软件价值”，说白了就是收入、日活、GMV 等 KPI 指标了。

在互联网应用盛行、速度为王的今天，持续交付的价值更是被突显出来。持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。

持续交付的隐性价值

除了上面这些你一眼就能看出来的价值外，如果作为不同的角色、站在不同的角度去看持续交付之后的变化，你还会发现其他一些隐性价值，而其中有一些影响甚至远远超过你的预期。

如果你是 CTO 或者是一个较大规模研发团队的管理者

• 你是不是时常困扰于技术选型的问题？

• 你是不是经常头痛于已制定的标准难以落地？

• 你是不是时常考虑如何提高跨部门协作的效率？

• 你是不是担心“黑天鹅”的降临？

如果你是 Team Leader

• 你一定希望团队的知识能够传承。

• 你一定希望团队专注于业务而非工程。

• 你一定希望以一个较平稳的节奏持续工作。

如果你是产品经理

• 你应该是产品真正的第一个用户。

• 你应该完全知悉当前的进度和质量。

• 你的产品应该随时能发布。

如果你是一个程序员

• 你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。

• 你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。

• 你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。

如何评估持续交付的价值

那到底应该怎么评估持续交付的价值呢？这里和你分享一下我在携程是怎么解决这个问题的。

我除了会评估一些常规的 KPI 外，更多地会换一种思考方式。既然很难量化持续交付的价值，那么我们就具象化，来看看整个工程生命周期中有多少被开发人员诟病，或者阻碍开发人员自助处理的问题点，即“不可持续点”：

• 开发不能按需产生隔离的测试环境；

• 生产代码回滚后，要手工处理代码分支；

• 预发布（Staging）流量要能自动分离，以便预发布测试。

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

虽然，有些“不可持续点”已经超越了一般传统持续交付的概念，甚至有些已经超越了纯技术改进的范畴，但是持续交付仍会一直关注于消灭这些“不可持续点”。So what，我们就是要持续交付我们的价值！

持续交付最终的使命

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

持续交付最终的使命是打破一切影响研发的“阻碍墙”，为软件研发工作本身赋能。无论你是持续交付的老朋友还是新朋友，无论你在公司担任管理工作还是普通的研发人员，持续交付都会对你的工作产生积极的作用。

以上内容取自极客时间的《持续交付 36 讲》专栏，希望通过这个专栏的学习，你和你的团队可以在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的：http://t.cn/EUCEALP