“You build it, you run it”
这是 Amazon 一年完成 5000 万次部署，平均每个工程师每天超过 50 次部署的核心秘籍。
而这一切，都离不开各种自动化测试工具及高效的持续交付管道。
目前大部分互联网公司，尤其是新兴的创业公司，已经从传统的瀑布流模式变革到敏捷开发模式。随之而来的 DevOps 以及持续交付等概念，也成为当下异常火热的话题。大家的探讨常常离不开以下七个问题：
持续交付本质上是什么？它是如何提升开发效率的？
持续交付在技术实现上有哪些关键点？
从2010年国外就有持续交付的书出炉，7年过去了，持续交付现在使用的普及率怎么样？
持续交付适用于什么样的公司和团队？创业团队？大公司？做什么业务类型的公司？
团队规模不同，大团队和小团队在持续交付的应用上痛点在哪里？
老团队在转型持续交付的时候会遇到哪些阻力？
持续交付的应用是不是在团队中常见？从个人角度来说，学习持续交付的意义是什么？会不会自己学习了，团队不用，学了也没啥用？
持续交付本质上是什么？它是如何提升开发效率的？
持续交付的概念已经交代了其本质，即高质量的快速交付。高质量和快速交付就是其本质。基于高质量和快速交付两个出发点，持续交付的最佳实践实际上是因团队而变的，并不是所有的最佳实践都适合于所有团队，因团队而异。然而其包含的几个基本持续交付管道则是必须的，这几个交付管道包括：代码提交，测试，部署和发布等基本管道。
几乎所有的最佳实践都能从一定程度上提高开发效率。举例说明，代码提交管道里有很多关于版本控制(Git)的使用最佳实践，比如提交前需要做pre-commit测试，提交后需要有静态代码检测，结合CI系统使用，保证了代码的质量。
同样的XP(包括TDD开发等)原则以及自动化测试管道的存在同样保证了代码的质量。
表面上看，似乎开发人员花在开发，尤其是测试上的时间增加了，效率是否提升存疑，然而事实并非如此。事实上，通过实践这些操作，开发人员之间可以更好的保证项目在 CI（持续集成）系统上面的健康状态。
尤其是在需要大量合作的项目中，往往一段时间以后，项目build就处于不稳定的状态甚至 fail 状态，在这种状态下开发，很可能导致各种冲突的产生甚至代码的回滚，对后面的集成阶段产生极差的体验。而从长远来看，这些管道，尤其是测试管道的实现，极大保障了项目始终如一的品质，最终来看，实现开发效率的极大提升。
持续交付在技术实现上有哪些关键点？
其实持续交付和DevOps一样，技术实现上是多样化的。而真正的落地关键点却不在技术上。对于DevOps来讲，关键点是DevOps团队文化的普及，其中就包括通过实践持续交付来推动DevOps文化。但最关键的点还是在于组织上从上而下的普及，即技术leader(CTO或者首席架构师)在技术团队来普及DevOps文化，包括团队内如何合作，跨部门如何合作，使用怎样的工具来实现持续交付以及怎样将DevOps文化推广到整个公司。
具体到持续交付，那么最关键的还是搭建持续交付管道。持续交付管道搭建完毕以后，针对每一个管道或者步骤，再寻求适合于自身团队和每个管道的工具和技术。
从2010年国外就有持续交付的书出炉，7年过去了，持续交付现在使用的普及率怎么样？
首先，目前来讲，大部分好的技术基本都是国外先有然后国内才开始流行的，国内互联网行业更偏重于业务或者商业模式，这在全球都可以说是领先的。然而技术上还是处于相对的落后状态。包括近几年非常火热或者逐渐火起来的持续交付，DevOps，Docker，区块链等等，都处于这种状态。
其次，国内大公司由于技术传统的问题，普及率并不高，但很多中小公司在实现持续交付上已经付出了很多努力。国外的很多大公司已经号称可以做到每天多次产品交付了，包括但不限于亚马逊，谷歌，facebook等等。国内随着容器技术和DevOps文化的普及，相信也会像国外一样，越来越多的公司开始实现持续交付。
持续交付适用于什么样的公司和团队？创业团队？大公司？做什么业务类型的公司？
持续交付适合于任何团队。之所以敢这样说，是因为持续交付有一个非常非常重要的原则。即要求，代码的上线和业务的上线分离。
简单讲，就是运维可以随时上线master(release)代码。即主干代码永远处于releasable的状态，而不关心业务代码是否已经开发完毕。目前可以实现这一点的技术叫做release train和feature toggle。而且他们带来的好处不单单是这一点，通过release train和feature toggle的实现，可以使产品经理拥有在线上做A/B testing的能力，可以实现灰度发布等等。所以说，在技术上完全可以做到持续交付而不管你是怎样的业务。
团队规模不同，大团队和小团队，在持续交付的应用上痛点在哪里？
持续交付能不能做好，实际上跟团队大小无关。但一般情况来讲，一个团队如果维持在5-8人之间，效率更高。
不分项目大小，在实际落地过程中持续交付的痛点很可能在于测试管道的实现。因为测试管道要求既要复杂到可以cover掉大部分的代码和业务场景，又要简单到可以支持分钟级甚至秒级的交付。那么自动化测试的实现方式和执行时间就是一个很关键的问题了。
老团队在转型持续交付的时候会遇到哪些阻力？
阻力分为内因和外因。内因即技术团队本身的原因，包括团队技术能力，技术团队之间的合作和团队leader态度等等。比如开发的目标是改变，运维的目标是稳定，测试的目标是控制风险，大家相对来讲拥有不同kpi，这些是技术团队本身需要解决的问题。
但一个拥有DevOps技术文化的公司，肯定不会在实现持续交付的时候遇到技术阻力。
阻力其实多半来自外因。比如技术资源都是有限的，这时候各部门对于技术资源的争夺很大程度上成为了持续交付普及的阻力。若一个大的团队拥有一个大的待转型的项目，这项工作往往要持续很久甚至数年才可以完全转型完毕。而在这个过程中，产品部门需要技术资源来改进提升产品体验，甚至研发新的产品，运营部门需要技术资源来搞各种活动来实现利润。架构部门与此同时还要推动持续交付的实现。
所以外因往往是转型中的痛点。这时候，其实也有解决方案，即Martin Fowler曾经提到过的Strangler方法。有兴趣的读者可以自行搜索研究一下。一个最简单的例子，新起的项目要尽量做到使用持续交付，不要再往老路上走。如果你已经意识到自己在坑里了，就不要再继续往下挖了。
新团队一上来就用持续交付也是可行的。
持续交付的应用是不是在团队中常见？从个人角度来说，学习持续交付的意义是什么？会不会自己学习了，团队不用，学了也没啥用？
这个肯定不会。
持续交付比DevOps更偏重实践一些，DevOps更偏文化一些。所以在学习持续交付的过程中，除了一些概念上的东西，会学到非常多最佳实践。
其中包括各种各样的工具，环境配置管理，代码版本控制，各种测试工具和技术，代码build工具，持续集成工具等等。
而且通过学习持续交付，可以更加了解自己目前的工作方式是不是真的适合所在的团队，继而才有可能帮助团队做出有效的改变。
尤其当你是团队leader的时候，这几乎可以改变一个团队的命运。
个人学习持续交付的意义就显而易见了
第一，编织自己的持续交付知识网络，开阔眼界，了解这种工作方式。
第二，学习到很多技术工具。
第三，作为leader，可以极大提升团队战斗力、交付能力以及交付质量。
即使你不是leader，作为一个有追求的程序员，未尝不可以去建议老大进行这样的改革，你也会成为改革的推动者。
后记：
程序员加班是常态，总有人会嘴上说“只要提高效率，就不用加班这么严重了“。但是，有时候你加班并不是个人效率低，而是涉及到组员间的协作，甚至跨部门协作时的整体效率低下，一个高效的个人面对一个低效的团队，浑身是劲也使不出来。
如果你也在被这样的问题困扰，那你可以考虑系统学习一下持续交付了。
