存在的问题
这次改造解决了之前多业务并行开发的问题，最终打包的时候也不会直接依赖各个bundle的代码库，完成了部分的解耦。但是还是存在很多的问题：
在同一个版本中所有的研发人员还是用的同一套依赖配置，任何模块的改动还是会影响其它模块，尤其是核心业务和框架层SDK的提交有问题的话会影响整个团队的进度。
仓库的版本管理混乱，开发和集成共用同一套仓库，开发可以随意部署，造成集成包无法控制。
由于各个bundle是将源码部署到仓库的，所以构建还是以源码为基础的，在代码越来越多的情况下，造成了整包编译速度缓慢。尤其是在等待很长时间以后编译失败，这种感觉是让人抓狂的。这个问题已经极大地影响到了研发的效率。
各个bundle的代码最终还是要编译到一个产物当中，各个bundle还是会相互影响，编译失败后定位问题成为了一大难题。
这里讲一下当时几个典型场景：
开发人员只是添加了一个方法，然后等待了10分钟进行编译，结果编译失败，然后排查一下午问题，结果是框架SDK更新导致的。
一大早几十个测试人员在等待回归验证发布包，结果发布包不是编译失败就是核心功能不可用最后到了凌晨2点钟，发布包终于出来了。
这样的场景太美，让人不敢去回忆。
研发流程
由于架构改造，提交集成的角色从开发人员变成了业务模块的研发团队，提交集成的方式从提交代码变成了deploy到仓库，但是由于工程架构的问题本质上没有完成各个bundle的解耦，所以整个团队还是在一条线上进行开发。不过这各阶段加入灰度发布的概念，灰度制度的建立使很多问题提前暴露，从而提高了正式发布版本的质量。
另外这个阶段建立起了代码审核、打包平台、发布平台、测试平台、舆情监控平台等，自动化了很多事情，在一定程度上提升了工作效率，大致使用流程如下：
存在的问题
集成的虽有雏形但依然不明显，提测和集成的界限依然模糊，很多bundle还是开发完以后直接deploy到主项目中然后打出集成包进行测试。
集成的标准虽然提出，但不能很好的运作，导致集成质量很差。
核心功能阻塞的问题越来越突出，长时间出不了可用的包成了一个大问题。
回滚操作依然困难。
项目的节奏依然混乱，导致项目延期和研发人员效率下降。
质量保证手段
这个时期的手淘测试团队建立了内存、性能、流量电量等专项测试机制，编写了一些半自动化的测试工具，建立了自动化适配平台，并组建了外包团队以提高测试覆盖率。这时候测试人员工作流程如下图：
存在的问题
测试人员在不断的更新测试包和等待出包上面浪费了大量的时间。
自动测试和专项测试只能在灰度阶段版本质量基本稳定的时候才能介入，这不但压缩了这些测试的时间，而且由于是在项目后期发现的问题所以会使问题修复成本增加。
非功能测试只有专项测试人员来做，此类测试的覆盖率还不理想。
测试经验的积累手段主要是自动化测试平台，但是这对于手淘研发团队来说还是远远不够的。
外包团队的组建解决了人力紧张的问题，但是外包人员的工作效果难以评估。
对于不同的环境需要打出多种不同配置的测试包（如：测试包、预发包、线上包等），测试人员需要安装多个包进行反复的回归测试。
当前阶段：多工程多构建产物、流程逐渐完善、多种质量保障手段建立
基于前两个阶段的经验和教训，手机淘宝研发团队在工程架构、研发流程、质量保障等多方面不断的进行完善，从而建立起来现在的体系。
