本文根据2018云栖大会深圳峰会·EMAS专场—移动互联的进化论，阿里巴巴产品专家叔大《移动APP持续交付之路》的演讲整理而成，文中就EMAS持续交付解决方案以及如何高效、高质量地支撑阿里巴巴数百款APP的交付工作进行了分享。
还不知道EMAS是什么？点击视频，快速了解如何「30天再造一个手机淘宝」
在进入今天的主题之前，我想先跟大家分享一个数字，去年双11阿里巴巴的移动业务占比，不知道在座有没有哪个同学是知道的？这个数字去年双11的时候，我们的移动业务成交占比达到了91%。也就是说阿里巴巴在移动互联网中已经进入到了深水区，相比较而言，我们很多企业当前的移动互联网化才进入一半，很多企业在50%和60%左右。
针对我们的移动研发团队，我们接下来在更深入的移动互联网的转型过程中会碰到哪些问题呢？我们的移动研发团队如何做到高质量、高效的交付，这就是我今天想跟大家分享的主题，移动APP的持续交付之路。
我们今天分享的内容包括5个部分，第一个是持续交付平台的介绍，前面提到了EMAS的移动中台的概念，持续交付平台在EMAS中处于什么样的地位。第二块我会介绍一下我们对持续交付流程是怎样定义的。后面三个部分我会从协同的视角、效率的视角和质量的视角展示持续交付的平台。
持续交付介绍
这张图刚才大家都看过，EMAS分为三层，第一层是基础架构层，第二层是研发支撑层，研发支撑层所对应的EMAS DevOps就是我们的持续交付的平台。持续交付平台提供了APP的全生命周期的管理，我们覆盖了从开发到构建、测试、发布、运营、运维这样一个全生命周期的管控，同时我们也形成了对基础框架层组件化框架、跨平台框架深度的集成，我们在交付流程里面也深度融合了阿里巴巴在移动领域的工程理念，我们在移动交付过程中深度体现了Android和iOS的开发规范、APP运维规范、APP性能基线。
具体的DevOps这一块，我们的持续交付平台方面提供了哪些能力呢？透过上面这张图可以看到，我们整个持续交付平台的底层基础平台提供了应用管理、消息管理、权限管理、用户管理、整个EMAS移动中台中间件的统一接入、统一的设备标识等能力。在日常的研发过程中，开发所需要依赖的基础环境，比如说代码托管服务、类库托管的nexus管理，iOS开发需要的证书管理等等，都提供了统一的服务。除此以外，我们的研发活动都承载在我们的项目里，而在项目的管理中提供了变更管理、版本管理、依赖管理和集成管理能力。为了提升研发效率，也提供了静态代码扫描的能力，我们提供了数据大盘、任务配置、规则配置、缺陷管理等等。在整体的移动APP构建过程中，我们提供了Android/iOS机器环境管理、机器集群管理、调度管理、构建配置管理和持续继承管理。而在发布过程中，我们根据不同的发布场景提供了不同的发布能力，比如说灰度发布的能力、全量发布的能力、渠道发布、Patch发布，我们会根据实际的发布场景制定有针对性的发布策略，使我们的发布更精准。
交付pipeline
我们是如何定义持续交付的流程呢？持续交付这个概念差不多在两年前开始流行，传统意义上大家更多的是讲如何做持续集成，集成指的是什么？集成实际上是指开发者由部分向一个整体的交付，而持续交付更多的强调的是由开发者向最终用户的交付，也就是说我们持续集成更多关注的是一个中间态的产物，我们的持续交付更强调的是一个最终态的产物，基于这样的定义，我们对持续交付的定义是这样的，我们将整个持续交付流程分成六步。
第一步是代码变更，我们以项目的粒度进行需求的迭代和开发，当我们的开发和测试在自己的项目里完成了当前需求的开发和自测以后。第二阶段就会进入集成阶段，所谓的集成是我们把多个项目需求集成到同样一个发布区，我们对发布区进行整体的回归和测试。一旦我们当前的版本测试质量符合我们的预期，我们就会进入第四步，当前测试的这个包推送给用户。是不是说我们把这个APP版本推送给用户了，就说明我们当前的这样一个交付流程就结束了呢？其实也未必，我们得继续往下看，我们得实时监控线上核心的业务指标，比如说我们线上的用户UV数据、舆情数据、核心的业务数据是否有波动，如果说我们当前交付的这个版本质量不稳定，我们上线了以后，发现有重大的问题，这时候就需要通过热修复的手段来解决线上的问题。也就是说，我们只有交付了一个稳定、可靠的版本才是一个持续交付流程的终结。
这个是EMAS以项目的视角来组织当前的开发活动，我们在项目里做对应的变更，做我们的依赖管理、静态代码扫描、自动化测试和集成。
当我们测试好了以后，我们会以同一发布周期的视角统一建一个发布区，在发布区内提供当前某一个发布包的整体的构建，基于构建好的场景进行回归测试和上线的操作。APP推送给用户以后，我们实时要查看当前线上的业务数据，比如说当前的用户更新数，我们的UV数据等等，这些数据指标是不是符合我们的预期，如果不符合我们的预期，我们该怎么办，一方面我们要停止当前的发布，另外一方面要做的事情就是热修复，我们通过热修复的工具手段，来解决掉线上存在的不稳定问题。这就是我们整体的持续交付的流程。
交付协同
前面已经介绍了我们手机淘宝这么大的体量，协调了几十个BU、几百个开发，我们怎么在EMAS上做协同？
我们从三个视角来看，一方面就是我们以项目的维度来组织开发和测试，针对当前的迭代来进行对应的开发和自测，一旦我们开发自测完成了以后，达到了我们的集成标准，就会统一进入发布区，我们以发布区的视角来组织和协调整体的质量协同和发布的协同。
怎么理解？请看上面这张图。举一个实际的案例来说明一下，比如说我们的双11活动，这是一个很大的项目，具体到某一个业务，比如说我们的电器城要做一个活动，这个活动对需求进行拆分，拆分成一个个独立迭代的项目，变成这里的项目1、项目2、项目3等等，我们在每个项目里进行独立的迭代和独立的开发测试。第二步我们将开发和测试完成的项目集成到发布区。
怎么理解这个发布区？举一个比较形象的例子，可能很多人都坐过火车，都去过车站，我们进车站的第一步是要做安检的，这就相当于我们这个健康检查。第二步是进到侯车区，等待火车出发，所谓的侯车区就是我们当前这样一个发布区。进入到侯车区。对我们的项目而言，同一个发布周期的项目我们就会以发布区的视角来统一组织整体的兼容性测试、回归测试，使得当前整个发布区的版本达到可以发布的标准。一旦达到了这样一个发布的标准，我们就要做下一步的操作，就是对外进行灰度。灰度前我们也会检查checklist比如当前的质量是不是OK的，安全是不是OK的。假设我们发布了一个版本，版本一已经上线了，通过我们的数据大盘监控出来说，当前这个版本的质量是不稳定的，我们Carch指标高于正常的指标，发生这样的问题我们该怎么办？我们要做的事情，一方面是终止当前的版本发布，同时定位到当前的问题，把问题修复解决掉，接下来做的事情就是把修复的代码集成到发布区1，进行重新的构建、测试、发布，这时候就发出版本2，通过这样不断地迭代、不断地发布，使得我们上线的质量是可控的，用户体验是完善的。
交付效率
前面我们已经提到了整体的交付的协同，对我们的持续交付平台而言，效率其实是一个很重要的因素，我们如何来保证效率？
这里先看几个数据。这里有三个数据，第一个数据，68次。手机淘宝通过动态部署，通过其它的方式可以做到一天发1.7个版本，这里的68次指的是什么？是我们的手机淘宝Android全年的全量发布，所谓的全量发布就是所有的用户都会更新的发布，也就是说平均每5天我们的手机淘宝的全部就会接到一个业务的更新。
第二个数据，一个小时。我们线上发生了问题，定位这个问题+找到这个问题+修改这个缺陷，然后测试好、上线，整个过程不超过一个小时就可以完成。
第三个数据，96%。这是去年双11的时候，我们的手机淘宝上会展页面的秒开指标，去年双11的会展页面有超过16万个，秒开率达到96%以上，我们所有的页面基本上都能一秒就打开。
是什么支撑了这些的数据，让我们能达到这样的体验？我们从三个视角来看：
第一，开发视角。我们如何来做到开发效率的提升？
首先我们需要有一个合适的开发框架，能让我们当前由单一的工程，由强耦合的工程变成组件化的工程，变成可以并行开发的工程，实现由单线程向多线程的转化。
其次是通用组件，我们DevOps持续交付平台提供了大量的通用组件，比如图片库、网络库、设备库等。如果有一个新的APP，这些能力都可以复用，不需要重新再写一套。
再次是二进制交付，比如说我们有一个APP是中等规模，十几万行代码，当前可能有一个版本，这个版本修改了差不多1000多行，传统的源码交付的方式，是需要将这十几万行代码全部重新编译一次，才能产生这个APP，这个效率相对来讲是比较低下的，我们如果能做到二进制的交付化，也就是说我只需要交付增量的部分，这1000多行代码可能也就涉及到几个模块，这几个模块加在一起可能也就几千行代码，我们当前需要交付的就是这几千行代码的模块就可以了，也就是说我们是存在一个量级差异的，由十几万行代码变成几千行代码的交付。
最后是依赖管理，它本身是依赖前面我们说的二进制交付，我们将整个APP都变成了这样的模块，对交付而言只需要更新其中几个模块，这几个模块就可以通过依赖管理来管起来。
我们来看一下这张大图，我们将整个APP工程通过组件化的框架来实现这种模块化和组件化。这里有一系列的Bundle，手机淘宝Android有300多个bundle，这一次需求可能我改了10行代码，只涉及到10个bundle，我们将它独立编译，把它交付到我们的仓库，这样就完成了第一步操作，我们由源码向二进制的交付。第二轮要产出一个APP，这时候的产出不依赖源码，而是依赖我们的类库仓库，我们通过组装的方式，这里提到的是组装，而不是编译，为什么是组装？就是我们通过基线的方式就可以产出一个APP。什么叫基线？比如说淘宝，线上有一系列的版本，比如说5.0、5.1、5.2，每一个版本后面都有一份配置，这个配置就对应我们的二进制包的坐标，比如说我们的登陆模块坐标是1.0，支付模块坐标是1.0，我们当前只需要把这些模块取出来，再加上我们当前所需要向修改的模块，就可以得到一份完整的APP。传统意义上可能大家说我去工厂生产一个汽车，我是从零件开始生产的，最终才能产生一台汽车，通过这种方式，我是有一个老版本的汽车，我可能只是把方向盘或者把轮胎换了一下，我就可以产生这样的APP，这种效率的提升是显而易见的。
第二块是测试效率，常见的方法都是通过这种工具来解决的。平台提供了静态代码扫描、UI自动化、智能monkey等自动化工具来提升整体的效率。
举一个例子，这里面有两张图，实际上是我们的手机淘宝iOS版本静态代码扫描的数据大盘，左边这张图是我们的静态代码扫描的规则分布，右边这张图是我们当前的一个问题类型分布。静态代码扫描提供了Android超过200条规则，iOS有超过70条规则，weex超过40条规则。这些规则都是我们阿里的工程师在实践中踩过的坑所形成的规则，是我们移动APP开发的宝贵财富。
具体的效果又是如何呢？从这个图大家可以看出来，我们空指针导致的crash从高峰期超过30%的Crash占比到现在不超过10%，这就是今天代码扫描所带两的最直观的一个收益。
前面提到了开发的效率、测试的效率，我们如何来做发布的效率提升？发布效率的提升包括两块，一块是需要精准的发布，就是说我们当前这个版本，目标用户群体是哪些，我们能精准定位。另外一方面就是我们要保证整体的发布稳定性。
先看精准，如何做到精准的发布，想要精准，第一步就要确认当前这个包要发给谁，我们有一系列的发布因子可以用于选择，比如说我们可以按照版本来发，按照渠道来发，按照机型、网络、设备、IP等等。比如说我们在场的这么多同学，大家都装了手机淘宝，我们发现其中有一个同学的手机淘宝的版本是有问题的，包是有问题的，我们可以定向的给这个同学，通过白名单的形式，直接更新他的手机对应的手机淘宝的版本。
第二，发多少。我们可以通过多批次的方式控制发布节奏，同时每个批次可以控制我们的用户量，比如说第一批次发5000人，看一下效果，Crash指标是不是对的，如果当前指标都很正常，我们就再发一部人，逐渐地迭代，保证我们整体发布的可控。
第三，发多久，我们可以控制当前更新的时间段。
第四，怎么发，我们是提醒用户更新，还是静默给用户更新，还是强制更新都可以根据实际情况来配置。
通过这一系列的手段，我们就可以将我们想要发的APP精准地触达到用户。触达到到用户以后，接下来要做的就是保证整个触达的过程是稳定的。如何做？最核心的问题就是我们需要实时监控线上的数据指标。有哪些数据指标我们需要看？我们需要看当前的线上舆情数据、性能监控数据，以及线上实时crash数据，还有我们的核心业务指标数据，甚至是我们的UV数据。通过这些数据来判断当前交付的版本是不是符合我们的预期，是不是符合质量的标准。一旦发现我们当前交付的版本并不符合我们的预期，比如说它的Crash高了，我们要做的就是做风险控制，风险控制包括几种，一种是需要停止当前的版本发布，尽量减少用户的影响。如果我们当前线上的这个问题比较严重，接下来要做的一个事情，就是对当前线上的版本做一个回滚，或者说我们通过热修复的手段来解决掉，影响用户体验的核心问题所在。
举个例子，这是我们EMAS上的某个客户的真实案例，他通过自己的实际情况来选择他的灰度的策略，第一次他灰度了1万人，真正安装更新当前版本的有650人，而他收到了用户反馈有9条。这样我们就可以基于现在已经灰出去的数据，查看他的carsh指标是不是符合我们当前的预期，假如说它确实符合预期，第二个操作就是放量。假设质量不符合这样的预期，这个版本我们就不要了，我们看当前线上的影响大不大，如果影响大，我们把线上的问题修复掉，基于已经查找和定位的线上问题，我们重新修改，重新构建、测试、集成，重新走这样一个发布的流程，我们会发起一个新的版本，基于这个新的版本重新做灰度，通过这种不断灰度的方式，就能保证线上发布过程的可控和质量的可控，同时也可以让我们的发布周期比原来预期缩短很多。
交付质量
前面提到的是交付的效率，如何来提升我们的交付质量？手机淘宝的交付质量又如何呢？
这里有一组数据。第一个数据，千分之0.2。这是手机淘宝当前的Java crash的水平，们在保持高速迭代的同时，也能保证crash保持在比较低的水平。第二个数据是我们的故障监控发现率为50%，我们线上的故障有一半是可以通过监控体系发现。
这些数据是怎么达到的？这里有一张大图，这是当前EMAS的监控告警体系，我们通过我们的度量体系，通过我们的检测组件，通过统计的组件，就可以精确地知道线上发生了什么，是什么原因导致的，然后这个问题我们怎么解决。通过这一系列的手段我们就可以保证交付的效率和质量。
最后做一个总结，EMAS的持续交付平台对开发者而言，对企业而言，核心价值在哪里？第一，EMAS的持续交付平台是一个一站式的全生命周期的管控平台，它提供了从开发到构建、测试、发布、运维、运营的全生命周期的管控。第二，它集成了阿里巴巴移动领域的工程理念，继承了我们的开发规范、测试规范、线上的运维规范。第三，这个持续交付平台也是一个效率提升和质量提升的平台。
原文发布时间为：2018-04-24
本文作者：叔大
本文来自云栖社区合作伙伴“淘宝技术”，了解相关信息可以关注“x”。