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

\u003cp\u003e随着云计算、容器等新兴技术的发展，“持续交付”这个老生常谈的问题，忽如一夜春风来，仿佛找到了从理想通向现实的大门。各类相关工具、产品、服务，也是纷纷出现：如Jenkins 2.0，Jenkins X，阿里云效，Netflix Spinnaker，Jfrog Artifactory等等。\u003c/p\u003e\n\u003cp\u003e到底是什么魔力使得各大公司和厂商对“持续交付”如此趋之若鹜？我在携程工作多年，负责系统研发的工作，在持续集成、持续交付方面积累了很多实战经验。\u003cstrong\u003e关于携程为什么要做好持续交付，持续交付的价值在哪里？我谈谈自己的看法。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2\u003e你了解持续交付吗？\u003c/h2\u003e\n\u003cp\u003e持续交付，到底是什么意思，它的定义是什么？《持续交付：发布可靠软件的系统方法》一书中把“持续交付”定义为：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e持续交付是软件研发人员，如何将一个好点子，以最快的速度交付给用户的方法。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e即使熟知了定义和方法论，其实也还是如海市蜃楼一般，无法落地，因为大家所贡献的最佳实践才是持续交付理论的核心。\u003cstrong\u003e只有真正在工作中贯彻和使用这些实践工具，才能体会持续交付的真正含义和作用。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2\u003e持续交付的显性价值\u003c/h2\u003e\n\u003cp\u003e持续交付也通常以“发布流水线”的方式来解释，即\u003cstrong\u003e研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。\u003c/strong\u003e如下图：\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://static001.infoq.cn/resource/image/7c/95/7c120be81140aed2a37f05f15cf09395.jpg\" alt=\"\" /\u003e\u003c/p\u003e\n\u003cp\u003e虽然持续交付着重打造的是发布流水线的部分，但\u003cstrong\u003e它所要达到的目标是在“最终用户”和“研发团队”之间建立紧密的反馈环\u003c/strong\u003e：通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。\u003c/p\u003e\n\u003cp\u003e这里说的“软件价值”，说白了就是收入、日活、GMV等KPI指标了。\u003c/p\u003e\n\u003cp\u003e在互联网应用盛行、速度为王的今天，持续交付的价值更是被突显出来。\u003cstrong\u003e持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2\u003e持续交付的隐性价值\u003c/h2\u003e\n\u003cp\u003e除了上面这些你一眼就能看出来的价值外，如果作为不同的角色、站在不同的角度去看持续交付之后的变化，你还会发现其他一些隐性价值，而其中有一些影响甚至远远超过你的预期。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如果你是CTO或者是一个较大规模研发团队的管理者\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e你是不是时常困扰于技术选型的问题？\u003c/li\u003e\n\u003cli\u003e你是不是经常头痛于已制定的标准难以落地？\u003c/li\u003e\n\u003cli\u003e你是不是时常考虑如何提高跨部门协作的效率？\u003c/li\u003e\n\u003cli\u003e你是不是担心“黑天鹅”的降临？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e如果你是Team Leader\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e你一定希望团队的知识能够传承。\u003c/li\u003e\n\u003cli\u003e你一定希望团队专注于业务而非工程。\u003c/li\u003e\n\u003cli\u003e你一定希望以一个较平稳的节奏持续工作。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e如果你是产品经理\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e你应该是产品真正的第一个用户。\u003c/li\u003e\n\u003cli\u003e你应该完全知悉当前的进度和质量。\u003c/li\u003e\n\u003cli\u003e你的产品应该随时能发布。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e如果你是一个程序员\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。\u003c/li\u003e\n\u003cli\u003e你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。\u003c/li\u003e\n\u003cli\u003e你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e如何评估持续交付的价值\u003c/h2\u003e\n\u003cp\u003e那到底应该怎么评估持续交付的价值呢？这里和你分享一下我在携程是怎么解决这个问题的。\u003c/p\u003e\n\u003cp\u003e我除了会评估一些常规的KPI外，更多地会换一种思考方式。既然很难量化持续交付的价值，那么我们就具象化，\u003cstrong\u003e来看看整个工程生命周期中有多少被开发人员诟病，或者阻碍开发人员自助处理的问题点，即“不可持续点”：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e开发不能按需产生隔离的测试环境；\u003c/li\u003e\n\u003cli\u003e生产代码回滚后，要手工处理代码分支；\u003c/li\u003e\n\u003cli\u003e预发布（Staging）流量要能自动分离，以便预发布测试。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e在携程，我们会将所有的“不可持续点”进行记录和分解，通过OKR的考评方式，将消灭这些点作为目标，拆解出来的可行动点，作为关键结果，以这样的方式来完成绩效考评。\u003c/p\u003e\n\u003cp\u003e虽然，有些“不可持续点”已经超越了一般传统持续交付的概念，甚至有些已经超越了纯技术改进的范畴，但是\u003cstrong\u003e持续交付仍会一直关注于消灭这些“不可持续点”\u003c/strong\u003e。So what，我们就是要持续交付我们的价值！\u003c/p\u003e\n\u003ch2\u003e持续交付最终的使命\u003c/h2\u003e\n\u003cp\u003e持续交付的价值不仅仅局限于简单地提高产品交付的效率，它\u003cstrong\u003e还通过统一标准、规范流程、工具化、自动化等等方式，影响着整个研发生命周期。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e持续交付最终的使命是打破一切影响研发的“阻碍墙”，为软件研发工作本身赋能。\u003c/strong\u003e无论你是持续交付的老朋友还是新朋友，无论你在公司担任管理工作还是普通的研发人员，持续交付都会对你的工作产生积极的作用。\u003c/p\u003e\n\u003cp\u003e以上内容取自极客时间的《持续交付36讲》专栏，希望通过这个专栏的学习，你和你的团队可以在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的：\u003ca href=\"http://t.cn/EUCEALP\"\u003ehttp://t.cn/EUCEALP\u003c/a\u003e\u003c/p\u003e\n