手机淘宝高质量持交付探索之路.docVIP

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