30+ 业务团队，携程无线发布如何做到稳定高效

作者简介

王雪松，携程技术管理中心PMO高级项目经理，主要从事携程技术中心跨BU项目集的管理工作。自2016年起负责携程主板app的项目协调、流程梳理、集成发布，并兼任无线技术委员会助理，负责无线端相关技改项目的推进及对BU支持等协调工作。

携程自2010年10月发布无线战略，到现在app已有8年左右的发展历史。早期的无线事业部，统一管理app从业务需求到研发到发布的整个过程。

2013年公司推出“拇指+水泥”战略，大力发展无线。2015年对原统一的无线管理架构进行了调整，将团队拆分到各业务线，此举可称之为携程无线的破和立。

无线团队拆分到各业务线后，加上后续新增业务线，目前涉及到的业务团队大概有30条左右，团队人员也很多，对app的集成发布形成了不小的挑战。

目前携程的无线发布实践是怎样的呢，本文将重点分享携程主板app发布实践。

 

一、组织架构

2017年起，携程组建了各垂直领域的技术委员会。无线委员会主要由无线平台和各业务线无线同学组成。作为虚拟组织对垂直技术领域做统一管理，响应技术领域的技术战略、发展方向，新技术论证落地，鼓励技术创新，制定技术规范制订，开展技术培训等。

平台研发中心的无线平台团队更多承担着无线框架、技术创新及对业务线支持的任务，内部也称之为“无线公共团队”。

技术管理中心PMO更多承担携程技术中心跨业务线的项目管理、SQA、流程等支持。

市场主要负责App在市场商务方面的工作，类似app上架计划、预装包、渠道包等等。

二、发布流程介绍

流程要点说明：

1、发版计划：发版计划分为大版本和小版本，大版本一般提前半年制订发版计划并通知到业务线，大版本会综合考虑业务线迭代周期及节假日等情况，小版本按需（用途：bug fix等）穿插在大版本间发布。发版计划主要由市场部和技术管理中心PMO负责。大版本迭代图如下：

2、需求部分：框架公共类需求比如大首页宫格分布及入口地址调整等，由无线平台产品团队负责管理，业务线提申请。业务线需求主由各业务线自行管理，跨业务线需求各自协商，公共类的技改有专门的项目立项来推动。

3、迭代发布：目前各业务线迭代周期在2~3周左右，各业务线包括平台公共无线框架，业务需求发布和框架类更新发布，都会要求在规定时间内完成测试和发布，进入最后的全业务集成测试。

4、业务线测试：指业务线开发或测试同学内部功能测试，测试通过后可以release，即可进入全团队集成阶段。集成工具MCD支持业务线按需编译和打包。

5、全业务集成测试：全员使用集成包测试（集成包是指集成了所有业务线release的功能）。要求各业务在此之前完成内部验证测试，并release bundle，未release的最新功能将不会进入集成包。

6、Code freeze封板：为保证发布效率，避免开发后期的改动风险，会在集成发布最后阶段做code freeze，我们内部也称之为“封板”，封板后出最终包，给到全业务线做最后的测试确认。

7、定版：就封板后的app集成包，如全团队测试通过后（需各团队测试负责人在MCD确认），我们定版launch，并在MCD标识进入后续渠道包制作等流程。

8、上架：定版后，公共平台团队会处理相应的渠道包和提交审核等工作，市场同学负责各应用市场的上架弹窗等。

9、质量：各业务线QA负责，集成期间监控issue收敛情况【Jira平台】。

10、运维阶段，主要指bug fix、hotfix等发布相关，均需按相应的流程申请及发布。比如小版本发布，小版本主要以修复大版本bug为主。目前采取“搭车需求”模式，即发动小版本车次，业务线提交需求申请，申请通过的开放代码权限。后续开发、发布流程同大版本。

 

三、工具方面

从工具方面来看，目前无线方面使用到的工具比较多，主要在编译发布、持续集成、日志监控、性能优化、AB分流、自动化测试等方面。本文重点介绍下集成发布相关工具。

2015年开始，无线平台团队自研了MCD（Mobile Continuous Delivery）平台，经过不断实践调整优化，到目前提供了持续集成、编译打包、扫码安装、冒烟测试、白屏检测、size分析、crash收集分析、灰度、hotfix等丰富功能，可以说是目前携程无线的一大利器，极大帮助提升了无线集成发布的效率。

平台涵盖了app集成、测试、发布、运营四大阶段。17年起支持插件化，实现业务解耦，缩短编译时间、减少编译依赖堵塞等问题。所有BU业务模块bundle化，并辅以bundle颗粒度RC发布模式，全面支持从项目创建、各业务开发、测试、bundle发布、集成发布、测试确认的app全生命周期管理。

测试阶段，提供白屏检测、远程设备租用、代码质量（结合sonar）、二维码扫码安装等功能。发布阶段，MCD还支持Hybrid、ReactNative等测试、发布、灰度、下发监控、下发回滚等。运营阶段，支持app size分析、崩溃采集、发布记录查询、发布包查询、下发配置、版本占比等运营数据统计。

MCD目前已全面支持其他独立app、小程序等发布流程。

 

四、小结

目前携程无线发布，经过流程梳理、实战打磨、工具利器、集团作战，已形成一套“快而稳”的体制，发布效率高效透明。以下是之2016年以来的发布launch趋势图。

整体发布流程已经在上面说明，个人认为对发布比较重要的几个点：

1、组织保证：一个高凝聚力的委员会，强大的无线公共服务团队及业务线无线骨干，他们好比是汽车的发动机，给无线技术框架的优化输出源源不断的动力，保证我们无线技术的先进性和实用性。此外，我们也会定期组织技术分享、沙龙等，以一种交流和学习的态度保持与业界的沟通。

2、工具利器：一个高效、信息透明的发布平台对集成发布效率的提升具有非常重要的作用。需要支持CI\CD、多技术栈发布、高速编译出包、流程扼要、信息透明等特点。

3、全流程把控，集团作战：目前各业务开发发布流程透明可见，同时高度统一管控发版计划和最后的集成发布阶段。个人认为可以称之为“集团作战”，PMO作为总指挥所或总枢纽，发出战斗打响号角（集成开始），发布战情（出包啊，家有问题啊），各业务线作战单位自行战斗并及时向指挥所反馈情况（反馈集成情况、确认测试结果），最后指挥所汇总战情，宣布战斗结束（launch）。

4、集成测试周期：从经验来看，集成测试周期长短可能会一定程度影响发布效率，建议是结合企业实际情况，逐步调整改进。携程这边几年来有过几次调整，目前周期也是长期运行调整目前可能比较符合的一个周期。

5、封板：在最后的集成测试阶段，往往因为业务需求的调整而出现开发临近发布还在commit的情况，大家都能理解往往最后阶段的代码调整可能带来是质量隐患甚至是巨坑，这也是往往发布delay的原因之一。所以我们在16年引入了“封板”，做code freeze。刚开始业务线不太习惯封板，也出现很多次封板延迟的情况，慢慢地也习惯了，需求端开发端都熟知了这个规则也就顺了。

6、沟通：无论从发版计划的调研制定、到最后的定版发布，各环节都离不开沟通。最后集成阶段，PMO会每天早上邮件发出当天早上编译的集成包（当然业务线也可去MCD上随需拿包），并同时会在内部沟通IM平台（cchat）广播，全业务线测试同学发现的问题、需要协调找人、问题修复等都可以在群里沟通或广播。

7、坚守原则：因为app发布涉及到30个左右业务团队，为了确保“集团作战”的效应，在整个发布过程中，对于重要原则必须“严守”。因为一旦某些关键节点“放松”，可能会导致整个发布流程效率降低。这也是PMO作为“第三方监管”的职责所在。

原则大家都遵守后，再加上各业务线的敏捷开发、需求封板、代码封板等机制，整体app发版流程清晰透明，大家节奏一致，整体发布效率自然也就趋于稳定和高效。

 

以上是携程无线发布的一些分享，希望对各位小伙伴有所帮助。

【推荐阅读】

• 浅谈React数据流管理

• 携程万台规模容器云平台运维管理实践
  

• OCR技术在携程业务中的应用

• 基于tendermint实现Hyperledger Fabric的拜占庭容错排序

• 携程混合云之kubernetes@AWS揭秘

  
  

---

携程技术沙龙——大前端工程实践

3月30日上海

少量名额，抓紧上车~

↓↓↓