每天万次触发的持续交付工具链实践

白凡

分享：王鹏-美团点评
编辑：白凡

大家好，我是来自美团点评的王鹏，目前负责工程研发团队的工具链。今天我给大家分享的是云在我们内部运转了大概一年多快两年了，持续交付工具链的实践。前面的定语有两个含义，第一是持续交付工具链的有效和高效性，第二是工具链的核心点是触发，为什么说触发是核心点？其中的一个点，我后面再给大家详细介绍。
这是我从我们后台监控系统截的图，由于公司信息安全的要求，我把一些数字隐掉了。这个大致可以反映我们研发团队的研发生产力，这是一个月里面的曲线，可以从上面看到每天、每周、每月大家的Push和PR情况，如果所有用了版本管理、代码管理用git的都知道大概是怎么回事。

今天我主要从这四个方面给大家讲一下，第一是持续交付，持续交付是什么、为什么、怎么做。第二是现在很流行的大部分公司已经做的微服务化。第三是再结合我们的实践，怎么能够从0到1打造一个高效的工具链。最后跟大家做一些深入思考和讨论。

1. 持续交付

在开始之前，我做一个小的调查，在座有多少是开发团队的？有多少是测试团队或者工程质量团队的？难道都是产品或者运维的同学吗？其实我想说什么呢？持续交付工具链跟我们的研发团队，我们平常说的研发团队是DPI等，我们统称为研发团队。持续交付工具链能够帮助我们整个研发团队高效协同，具体怎么协同很快大家就知道。

首先我们看一下持续交付到底是什么，我们经常会说持续交付、敏捷开发、持续集成、持续部署、DevOps，刚刚顾宇老师把DevOps的最新实践给大家做了介绍。通常怎么区分这些呢？大家可以看到这张图，大家处在哪个环节上？

我们今天说持续交付和持续部署的区别，这里有一个定义，上面的英文定义是我从往所搜索的大家都认可的定义。持续交付是一个软件工程的方法，能够帮助开发团队很快的生产软件，在一个很短的周期内，生产保证这个软件以更可靠的方式发布，任何时候都可以发布，而且有必要的情况下手动发布到生产环境。英文比较绕，英文怎么理解它呢？我认为是一个研发团队如何将想法/feature/服务，快速交付给最终用户的方法，这些方法会落实到最终工具链上。

为什么我们要做持续交付？我觉得这个可能性不需要太多给大家强调，因为所有参加DevOps会议的人都有一个目标，希望能够提高研发生产力、提高公司或者团队或者个人的交付效率，这个交付效率怎么去衡量？我们怎么样去看从一个想法变成产品、变成最终交付给用户的服务的周期能够变短，交付质量怎么样在这个过程中能够提升起来，怎么样做到快速的反馈、质量的闭环，还有RD、QA、SRE怎么做到无缝协同，这些答案通过持续交付工具链都可以完成。另外是通过后台技术架构微服务化的做法，我们怎么样做到高效的工程效率和工程质量。

刚才说了一些是什么、为什么，我们再看看要达到这些面临哪些障碍。这是一个调查，跟我们的内部实践也非常接近，最大的是一个公司或者一个团队的组织文化，或者我们通常说的工程师文化主导的公司或者团队更有优势一些。另外是在开发、运维、甚至包括测试团队的合作上，平常可能没有什么事情的时候还好，但是通常情况下一出了事故开发和运维之间就开始互相扯皮、互相甩锅，所以这个合作上也是有很大的问题。另外是技术障碍，技术障碍有两种，一种是研发内部的基础设施，另外一种是持续交付工具大规模基础架构，还有缺乏理解。

两年前我们从底层做起实施的时候也面临这些问题，具体怎么做？很重要的是公司有没有效率为先、质量为先的工程师文化氛围，第二是结合公司的业务、技术架构、公司团队能力是什么样的，通过任何一点强制引入持续交付工具链，不对公司业务、技术、团队进行深入分析和基于现状做升级，其实都会背道而驰。

很重要的一点是能不能作好持续交付工具链，公司的现有研发基础设施很重要，我一会儿讲到实践环节的时候，你会发现很多时候我们不是被选择某一个工具本身挡住了，可能是公司测试环境不具备、自动化测试不具备、各种各样条件不具备挡住了，你要一个一个点解决问题，你会非常痛苦，你搞了好几年都搞不出来，可能抱怨这个、抱怨那个，但是这些最终还是要去解决的。另外一个是要选择合适的CI/CD工具，还有自动化测试，自动化测试在这里是一个很重要的环节。

右边的图是现在很容易看到的，不管是特斯拉、还是丰田等汽车厂商，其实现在已经在汽车的生产上，当你把零部件做好之后，全自动化的生产整车很快就完成了，不管是从汽车安装、喷漆全套出来基本上就接近可以动了。但是我们号称互联网要去改造传统行业、改造什么的时候，我们会发现还是要手工环节，还是要各个不同系统之间手工构建、手工打包、手工部署大环境、手工发布，这个还是一个很常见的现象。去年我在北京的一个分享上跟大家了解到的情况是，大部分团队其实还是处于这种现状。

这个是DevOps或者持续交付所用到的所有工具的一个集合体，目前不管从构建的环节、运维的、部署等环节都有大量工具去用，实际上我们在每个环节上都不缺乏称手的或者可用的工具，或者我们公司特殊用不了这个、用不了那个。CI/CD工具，从全球最大的某交友网站上看，这两个占比比较高很正常。大部分公司我了解到的应该是包括腾讯和阿里在内，背后实际上大部分用的还是Jenkins，63%基本上都选择Jenkins作为CI/CD工具，当然还有一些其它的。

实际Jenkins这几年的发展也非常快，我这里不是给Jenkins做广告，因为刚好我们团队也是基于Jenkins打造CI/CD工具本身，另外在去年年初的时候Jenkins的作者刚好来我团做了一次深入分享，我们有了一次分享。目前大部分团队还是停留在Jenkins1.x年代，但是从2014、2015年开始，Jenkins已经迈入2.0时代，就是Pipeline as Code，这个非常重要，因为现在多仓库、多模块、多任务、多stage是一个很普遍的现象，对于我们的测试环境也是被广泛运用的。

再看看业务技术和团队，第一是为什么要看业务呢？因为不同的业务对集成是不一样的。比如说像微软公司office和window交付周期都很长，一年、两年、三年。包括我的前公司我之前做CT产品，CT的整个软件控制大概5个G的代码，每个项目即使有之前的积累最短最短也要一年以上，这样的交付周期是非常长的。交付质量要求也是不一样的，每家公司像医疗器械厂商有一个是FDA或者审查，非常严格的审查，另外它是任命关天的事情，如果你做任何一个手术的时候down机了，医生可能直接挂在手术台上了。如果是一个互联网公司不涉及到交易，可能对质量方面要求稍微没有那么严格，交付周期也是不一样的。

另外一个，你所在的公司的业务技术栈是什么，环境、框架、监控、反馈，还有团队规模、开发模式，只有一两个人的时候只要简单的环境搭在那里就可以了，当你有上百人或者上千人团队的时候，这样做肯定是不行的，你需要一套持续交付工具链的可扩展架构，最终持续交付可以帮助研发团队实现更快的向用户交互。

接下来的分享，给大家介绍一下我们怎么样从0到1打造高效持续交付工具链。第一是一定要基于公司现有的研发基础设施现状，第二是使用开源的CI/CD工具，不要指望着说我买一套什么或者直接在阿里云上DevOps，可能一些刚起步的公司适合这种情况，但是上了上千人大规模的公司有一套工具链是非常必要的。第三是零成本打造持续交付工具链，我们都是基于开源的框架和基础设施。

2. 微服务

我在2008年刚刚开始工作的时候组去了一家外企通用电气医疗集团，我们当时做的是改造单体系统。单体系统是什么样的呢？每一年的项目做完可能会有两张光盘，每个光盘是4个G的代码，后面构建差不多要花一天时间。当时我们也做了一些改进，就是把时间降到几个小时，把它分模块、分布式构建，用各种各样的IPM包打在一起。后来加入美团点评之后，美团旅行的业务大概是这样的，一个是有面向用户的美团和点评两个超级APP，另外一个是面向生态端的有酒店、旅游B端的APP。另外在主要APP上面境外度假、境内度假等，有这些频道。

这些APP和频道背后基本上是成千上万的微服务，我们在Monolithic的网站上，他最早提出微服务的概念，从单体架构到微服务架构什么样的一个区分，这些我刚好从2008年到现在基本上都经历了一遍。而且在单体架构上，我们怎么样做持续交付、持续集成，在微服务上怎么样做，刚好我这边都经历了一下。这个我不细给大家念了，基本上是微服务的一些特点。

本来我们觉得微服务之后可能世界会清晰很多，不像以前那么庞大。这是我们公司系统的微服务的大盘，最终其实微服务出来变成这样子了，完全没法想象，这个怎么做？世界怎么变成这样子呢？仔细分析之后，实际上单体和微服务架构各有各的优势、各有各的劣势或者面临一些挑战。一开始刚刚起步的公司，其实也不用追求微服务，用单体架构很简单基本上就完成了，很快搞定，不用追求微服务、追求潮流。对于大规模的公司面临每天上亿流量的情况下，可以横向扩展和部署，你需要你的多个上线团队之间很好的合作，各个服务之间能够独立，而且运营测试。

对于这些挑战，左边下面的挑战我都是亲身经历过的，因为我们当时一个单体架构的CT系统，不知道有没有人在医院里拍过CT，后台有一个系统部署了5个G的代码，控制CT的旋转、成像、给出生出片，中间会做到三维叠加成片，非常复杂的算法。当时我们面临一个跨国的团队，很多团队协同，这是非常痛苦的，很难想象。我不知道我那时候是怎么走过来的，每天不同的时区，大家的接口定义调用怎么做，维护的成本、打包、构件不同的协同，用复杂性理解，基本上到最后只有架构师才能做到，做了7、8年、10年才能理解下来，扩展起来非常困难。最后大概5万美金一台惠普的机器支撑整套系统的运转，配上大概1000刀一块的特斯拉显卡，当时是非常厉害的，一块显卡大概5000刀。你只能单方面提升你的硬件能力，对于微服务架构来讲就好办很多了，基本上是横向的各种扩张、各种部署，就可以把你的性能跟上了。

刚才说到在微服务和单体架构面临的一些挑战，接下来说一说我们在接下来两年时间里面怎么从0到1做好持续交付工具链。第一个是路径规划，前面我说了，要做到这些第一是从你的业务出发，搞清楚你的研发基础设施、搞清楚公司内部的环境，相应的配置中心是什么样的，接入，触发场景，自动化测试建设怎么样，整体自动化测试是一个很低的覆盖，虽然说我们不强调100%覆盖或者怎么样，但是覆盖是符合自动化测试建设水平的。整个质量准入是怎么做到的，反馈机制怎么样快速反馈给相应用户，还有一个落地运营。

最终的总结，我们认为要有一个Pipeline引擎，还有一套测试环境，我们公司叫做Cargo，实际上是类似于K8S的弹性伸缩的容器环境。还有一个配置中心，这个我们团队开发的叫CodeQuality。另外还需要一套触发机制，这个触发我们称之为Hook Service，你需要在git配置Hook，但是一个是不够的，不可能手工去仓库配，需要一套统一的Hook机制，在关键时刻能够做服务扩展。

3. 我们的实践

再回到我们刚才说的业务是怎样的，当时我们面临的一个情况，这是美团点评现有的一个研发基础设施，在构建环节内部有后台的、安卓的、测试系统、部署系统、测试环境、代码管理等，实际上大部分都在开源工具基础上构建的。还有监控的，系统监控，还有CAT目前开源到3.0，天网是我们内部级业务监控系统。上面的绿巨人是我们基础的弹性伸缩容器平台，插构在上面，构建了一套测试环境管理体系。PLUS是我们的一个发布系统。

这是一个更详细的，我们要搞清楚一家公司从代码管理、发布系统、测试环境、容器平台、CI工具、在微服务架构上的服务治理、项目管理、开发框架、测试框架、构建工具、通信工具、监控工具，监控可以帮助你很快的反馈你的服务部署完的实时状况或者构建过程中的状况或者服务运转的一些情况。

看起来很清楚，但是实际上帮你把这个搭起来的时候，你会发现挑战非常多。一个是测试环境是一个很大的问题，你的测试环境搭建常规情况下用几个物理机或者虚拟机很快就搭建出一套测试环境来，但是当你面临上千个团队或者成千上万个仓库服务的时候，你的测试环境怎么样快速的伸缩、扩展，因为很多情况下是先部署再测试的。架构跑起来你会发现出现各种问题，什么问题呢？整个CI工具不工作了，高峰期的时候16个D不够用了。

大家可以从刚才图的上可以看到，每周一、周二、周三是代码的高峰期，其实每天下午2点到6点间基本上是所有的互联网公司都是一样的产出代码最高的高峰期，在这个高峰期你的测试环境也不够用，然后就卡住了，你所谓的持续交付就停在这儿了。现有的也存在很多问题，虽然插件架构设计得非常好，但是实际上很多插件没有更新。我们还做了两个，比如说你会面临多个仓库怎么样同时获取Cargo覆盖率，有的直接互相之间覆盖了，你能取到有一个，有的时候你所依赖的基础服务都挂掉了，你有紧急上线怎么解决，各种各样的问题，我就不一一细细说了。

详细说一下测试环境，公司基础架构提供了一套泳道的机制，它的基本机制是因为微服务有时候链路会非常长，我见过一个业务线差不多所有的服务加起来4、500个，其实也就可能是某一个频道的。你每一次都把4、500个服务一下子都布、一下子都弄，消耗非常大，只是其中一两个服务或者最多十几个服务。这种泳道的架构可以为大家提供什么帮助呢？你可以先部署好一个骨干链路，这是常规不变的服务，其实也代表了当前你的现实跟当前现象部署的服务都是一模一样的。

另外你可以提供这种泳道，像我们游泳池里面人为划分出来的泳道一样，这里有一个基础约定，当泳道存在这个服务的时候是不会被打到主干上去的，当这个服务不在的时候就会自动到主干。这解决了一个什么问题呢？当你部署或者是监控的时候，你可以只用布AB两个服务，剩下的C在泳道里面找不到就自动到主干上寻找，这样可以帮大家搭建一个最小化的很快构建出弹性的测试环境，而且各个项目之间是完全隔离的，完全可以做开发，互相不干扰，而且可以共享。我们可以解决稳定性监控，目前能够保证到链路的稳定性。

接下来是配置中心，实际上大家知道通常我们的一个仓库或者一个服务跟我们的自动化测试、项目干系人和各种构件方式、部署方式、综合测试、其它等等一些信息基本上是完全分开的，你没有办法串起来，也没有办法做到当你想通知谁的时候去通知人所以对于配置中心我们内部叫做CQ，这是仓库中心和结果展示中心，可以方便的把这些关联起来，剩下是一些自动获取。

再接下来说接入部分，为什么说接入重要呢？因为从我们内部的实践来看很少有开发团队，因为开发团队的同学还不愿意自己的代码被测试、被打回、再做，他们很想一次过就完了。但是测试团队需要一个前置的质量准入，他又没有途径，只能平常通过在群里面说、跟开发负责人强调、大家形成一些流程规范的方式，很难有效的运转起来。在公司内部基本上有成千上万个仓库、服务，你需要一个个去配也是很痛苦的事情。

我们实现了自动接入，当你一个仓库被创建出来的时候，它就自动的被配置到相应的持续交付Pipeline工具链，默认Master分支作为主分支，默认做一些质量检查，其它是可以自定义调节的，你可以变更你的配置，在前面我说的CQ里面。一条仓库也是可以组织多条自动交付Pipeline的。下面是我们每次都会推送的，哪些已经自动接入了，提示相应开发同学和QA同学做配置。除了排除不打算上线的仓库之外，目前只是作为一些调研的，基本上99.9%的仓库已经全部接入。

再一个是触发，前面我说到触发是里面的一个核心条件，为什么呢？这中间有4个核心点，第一个是自动触发，为什么呢？你不要每一个都让大家跑到某个UI里面点一下，你应该做到用户是无感知的，当他Push代码的时候做了自动的质量检查，当他做PR的时候，不管是Master PR还是其它PR的时候，这是代码准入，你可以做相应的检查。

还有一个是提测，基本上我所知道的大部分公司都会存在这样的多多少少的测试系统，在持续交付工具链里面提测触发可以帮助大家做到自动提测，当你的代码开发完以后你只需要填几个必要条件，Push相应提测就会被触发出来，验证提测结果发给QA同学，通过就会到QA同学那里流转，如果没有通过就要做进一步修改代码，要重新去做。还有一个是集成，再另外一个是上线，这是大致的一个示意图。

另外一方面是自动化测试，实际上要让持续交付工具链很好的运转起来，最后达到持续部署，自动化测试的建设是中间很重要的一步。因为功能测试、集成测试的质量把控，最终要靠自动化测试来完成，代替人工的测试去完成。通常所说的一个测试金字塔，越往底下成本越低，越往上维护的稳定性没有那么高，维护成本很高。

我们在美团内部主要是两种接口：HTTP、Thrift，两种接口会面临不同的框架，当把这些东西集成在一起的时候，面临一个很严重的情况是各种框架的统一，调动起来非常麻烦，产生的结果和各种各样的构建运转都会出现各种各样的问题，统一测试框架是非常必要的，可以降低开发成本，框架一致、维护方式一致的情况下，不管是哪个同学维护结构都是一样，只需要配相应的数据。

我们希望能够做到几个设计原则，第一是代码组织标准化，你看这些结构都是一致的，只要熟悉开发的同学都能够很快的上手，接管不同业务线的自动化测试case。另外一个是技术栈标准化，不管是底层做校验的、还有HTTP，我们都用统一的框架做封装。另外怎么做到数据驱动，用更少的代码，我们会自动生成框架性代码，更加标准化，但是也不剥夺大家做开发的权利，不是说完全变成一个在上面点点点的UI式综合性测试开发，更多的是校验。

质量准入，这个点也非常重要。我们从4个环节：自测、提测、集成测试、上线前测试，4个不同的研发阶段给不同的质量准入。自测主要是反馈快，基本上是几十秒内就可以反馈相应结果，告诉你提交的代码质量如何，主要是做静态和代码的分析。针对提测会更多，冒烟测试、自动部署、代码冲突检查、分支规范检查等。蓝色部分是在每个阶段比较特有的部分，红色的基本上是一些公用的环节。

反馈机制，这是我从内部系统上把一些仓库名称等过滤掉，基本结构是这样的。我们内部的大象，IM每次Push代码、PR代码等都会有大象冬至，告诉你被打回了，未通过以下部分，还是PR、Push检查通过，你的结果是怎样的，蓝色字体方面是相应链接，可以点击进去查看更详细的进一步的信息。当你提一个PR的时候，因为公司目前所有的代码管理都在上面，一个PR提出来是什么样的状况，它会参考集成要素的结果，然后再进一步做。如果没有就打回，你再修改。

这是持续交付工具链的大致架构图，最基础层是内部的研发基础设施，就是你的CI工具，现在用的是2.46版本。测试环境是Pipeline相当抓包管理系统，提测基本上是通过提测Pipeline走的。在服务层自动接入、触发服务，忽略一些没有那么严重的问题，快速上线。综合测试框架，需要配置中心和结构展示中心，还有相应消息中心接管通知到不同的各方。

发布是Moka测试工具，因为链路非常长，不可能把所有服务都搭一遍，或者你需要短链路测试的时候，这个是最佳的选择，而且更加稳定。因为有时候涉及到第三方依赖的或者外部依赖的，你没法控制对方的服务稳定性的时候，你把它Moka掉是非常好的选择。在应用层我们提供自测Pipeline、提测Pipeline、集成Pipeline、发布Pipeline，监控也是分了多级监控、业务系统监控、服务监控、缓存机制。

持续交付工具链也是分层的微服务的，另外一个衍生过来，它本身也存在一个问题，你会存在Slaves不够用，可靠性是不够的。我们内部做了多Master、多slaves的架构，我们每天slaves活跃通常是维持在360左右，每个大概6个执行器，在高峰期会自动扩容。Master我们内部是两个组的，在这种情况下才能支撑每天大概上万次、一个月大概十几万次的持续交付Pipeline。

我不知道有没有同学关注过最新的在今年4月份Jenkins官方推出JenkinsX的项目，应该属于Jenkins的子项目。实际上这个X的架构跟我们去年的设计是不谋而合的，也是在K8S上直接部署Jenkins，支持slaves的扩展，我们也是用JenkinsX替换老的设计，但是原理是一样的。

这是持续交付Pipeline的运行机制，当你在分支Push代码的时候会收到这样的同志，合并代码到非主分支会有这样反馈。当合并代码道主分支的时候链路会更长，检查会更充分。同时我们刚才说到还有一个提测Pipeline，未通过提测系统的需求和自行上线的需求都会有相应标志，我们会打上相应的标志，一些预算合并分支就删除掉了。

在紧急状况下，一个是你可以跳过申请检查，因为我们已经假定基础服务不是那么稳定的，我们时刻做到跳过检查，让它不上线，但是跳过要防止被滥用，我们后台做了相应记录，要有相应的同学去批准，而且每周有相应周报发出来，告诉大家哪些可能是被滥用的，都会发给相应的质量负责人。

另外一点，我们会做自动的服务降级，也有手动的服务降级，当然底层的不管是代码管理、测试环境管理、Jenkins本身、弹性伸缩容器平台基础设施故障的时候，能够让它做自动的服务。

回到我最前面跟大家说的后台最终结果图，这是5周、一个月，可以明显看到周一开始爬坡，周二、周三、周四基本上到了一个顶峰，大家开发代码的Push和PR的情况。周四、周五的时候还是有几十个同学还在加班写代码，对代码有多么的热爱，周末还在加班去做。周五会慢慢降下来，你提交了也没有人测试，也没法上线，大家会把这样的工作慢慢降下来。从目前来讲，我们每天的触发基本上在12000、13000次，最高到15000次，当然这是内部的情况，还没有开发给所有团队。每周大概在十几万，每个月就更多了。还有一个数据比较关系，就是Push和PR的关系，基本上一次Push会有几次PR。

持续交付工具链可以反映出整个研发团队的研发生产力的情况、研发效率、研发质量，你在这个环节不管是代码分析、接口测试、集成测试、上线前全链路测试、场景测试、功能测试的情况，其实可以很清楚的反馈出每个团队或者每个个体的开发能力、开发质量、开发效率。所以这个的建设不仅提升了整个团队的研发效率，也能够提高研发质量，能够清晰的看到每个团队的能力状况。

4. 一些思考

最后给大家回顾一下，怎么样从0到1建设持续交付工具链的情况。第一是找准切入点非常重要，不是说一开始就要直接买一套什么工具或者搭一套什么工具就用起来，刚才说到从业务、研发基础设施、团队的基础情况搞清楚，找到切入点。最早的时候是从代码扫描入手，给大家提供最基础的服务，当你Push代码的时候自动帮你做代码分析扫描，慢慢扩展到整体的持续交付系统。因为你要建立自动化测试环境、自动化测试框架，让它的稳定性达到一定程度。

第二是不要从开头开始造轮子，这是不好的，我要自己写一套，陷入这种环节永远达不到效果。先解决最关键的问题，比如说代码问题先解决。
第三是在这条路上是没有捷径的，不是做完了持续集成就完了，下一步还要持续交付、持续部署，工具链本身要不断迭代和演化，走敏捷开发路径。
第四是我们认为最好的工具链是有效的，其次是高效的，反应非常快，第三是无感知的，无感知不是不知道，而是它在背后悄悄为你服务，不需要你配这个、点这个、点那个，你只需要Push代码、PR代码，其它都来了。你在这里要让它落地真正的运营发挥作用，自动接入、自动触发、质量准入、自动运营这4个点是非常重要的。

我们从思维模式到工具框架，平常做的时候一开始先有一个开放的思维模式和封闭的思维模式，另外要接受持续迭代改进，我们要认清楚持续交付的基本原则，找到在公司的实践模式，把它落实为一些流程规范。一开始只是纸面形式或者宣讲形式的要求，怎么样通过工具链把它落实到工具框架里，真正让它发挥作用。先在一个小团队或者是几个优秀的个人身上先做落地实践，保证先让个体接受，再提升整个团队的工程素养，让整个团队接受，最后把它发展成团队文化，是这样的一个倒三角。

做好这些之后，我刚才也说到，怎么样有一个代码质量方面的度量，我们内部会有一个度量。这些都是从工具链本身立马可以拿到的实际数据，在开发效率的提升上构建、打包、环境、联调都做到了，但是每个环节都有很大的空间可以挖掘，你的构建速度可能之前需要1分钟，你是不是可以直接把它压到几十秒或者10秒钟、几秒钟就完成了，你的环境自动伸缩能不能从分钟级的变成秒级的，你的联调效率能不能快速提升。测试的效率通常测试团队准备的时候、自动化测试准备、环境准备上都要花大量时间，持续交付工具链的体系下这些东西自动化可以帮你完成，你要做的事情是写好自动化测试，把这些以自动化测试通过持续交付工具链以质量服务的形式交付给开发的同学、交付给开发团队。

最终是怎么衡量交付效率，从代码到服务的Cycle time，通常有一个衡量标准是发一行代码放到网上需要花多长时间，我们现在是很快就能完成，包括测试。最终我认为持续交付是让整个研发团队高效协同的工具链，也能够做到质量服务化、测试服务化，最终通过持续交付工具链做到服务化，让大家高效的协同工作。