前言
随着移动互联网的迅速普及，手机淘宝业务在迅速的成长，目前已经发展成为拥有40多个bundle（业务模块）的超大APP产品，在这后面有着数百名的研发人员的努力工作。业务的成长和人员的倍增给技术架构、团队合作、产品的交付都带来了巨大的挑战。本文将会讲述手机淘宝研发团队在两年的时间为了达到高质量持续交付的目标而做出的种种努力。希望借此机会向大家分享手淘的经验与教训，与大家共同探讨高质量持续交付之道。
第一阶段：单工程单构建产物、初级流程、初级质量保障
回到两年多以前，手淘还是一个年轻的产品，业务不多、研发人数不多、代码数量也不多、测试的手段也很单一。这个时期的特点就是所有代码都在一个工程里面，测试、发布都是围绕这一个工程的代码分支所编译出来的包来进行的。
工程架构
这个时候的手淘基本上就是一个大工程，依赖以源码依赖为主，所有的开发人员共享这一个工程，在同一个工程上开发。
存在的问题
代码混在一起，不便于管理。一个模块的代码有问题就会影响整个项目的开发人员。
不能支持业务的快速增长。
研发流程
工程的架构决定了研发交付的流程，所以当时的流程也比较简单，开发人员在本地开发完成以后直接提交代码，然后编译服务器进行打包，出包以后测试人员进行测试，如此反复，最根据代码库的最后一次提交进行发布。如下图所示：
相关
存在的问题
提测和集成阶段混在一起，提测代码质量较差，开发人员不断的提交修改bug从而导致不断的集成包。
任何一个编译不过的问题会造成整个团队在等待。
回滚只能做到代码级别的回滚。
发布前回归如发现问题只能等待开发人员修改bug，然后重新出包，再进行一轮回归，如此反复工作量很大。
如遇到阻塞问题，比如登录有问题，那么所有的人员都要等待登录的开发人员修改完bug才能继续工作，造成了大量的等待时间。
发布过程只有正式发布这一个步骤，很容易造成故障遗漏到线上。
质量保证手段
这个时期的手淘测试主要以手工测试为主，附加一些monkey测试和少量的自动化脚本。
存在的问题
纯手工的测试造成了测试人员大量的在做重复工作的现象。
测试经验没有积累。
非功能性的问题缺乏测试手段。
出集成包的节奏不可控，导致测试人员频繁换包测试，造成大量的重复工作。
对于不同的环境需要打出多种不同配置的测试包（如：测试包、预发包、线上包等），测试人员需要安装多个包进行反复的回归。
第二阶段：多工程单一构建产物、平台建立、初级持续集成、发布流程建立
随着移动互联网的迅猛发展，手机淘宝的业务随之倍增，研发人员也倍增。这个时候大小业务模块已经超过20个，研发人员超过了百人。这个时候原有的工程架构已经完全不能满足业务的需要了，质量保障也面临着很大的挑战，也就是在这个时期我们建立了一系列的平台：打包平台、发布平台、测试平台、验收平台从而使用自动化的方式提升了些效率。并且建立了灰度发布的流程，提升了最终发布的质量。不过这些努力也没有阻止质量和交付问题的大规模爆发……
工程架构
工程架构是整个研发的基础，所有的事情还是要从工程架构讲起。为了能够接入越来越多的业务，手机淘宝的架构从之前的单一工程的方式演进为模块化开发的方式，每一个模块被称作bundle。同时引入了仓库的概念，每个模块将源码打包之后deploy进入仓库，然后由builder工程进行依赖管理并编译打包。
