04　去哪儿App持续交付之路

作者介绍

陈靖贤　去哪儿网工程效率工程师，负责DevOps的落地实施、持续交付流程的改进及工程效率平台的建设。2013年加入去哪儿网，曾经在索尼移动通信、摩托罗拉做配置管理工作。从业十余年，一直深耕于配置管理和工程效率等相关领域，拥有丰富的持续集成、持续交付经验。

案例综述

目前，移动端已经成为各企业业务流量的主要入口，对各企业的业务发展起着至关重要的作用。因此，各企业都普遍关注一个问题，那就是如何更快地响应市场的多样化需求，不断提高企业的市场占有率。要解决这个问题，就要求企业加速迭代，不断提高持续交付能力。本文将为大家介绍去哪儿网移动端持续交付过程中的一些实践。

案例背景

我们通过去哪儿App背后的一些数据来简单了解一下去哪儿网当前的持续交付能力。去哪儿App的研发涉及10条业务线，200多位开发人员，包括90多个Native组件和180多个动态组件，构建次数平均每月8000多次，每5～7天发布一次，每次发布160多个渠道。每条业务线的交付产物为二进制组件，我们需要对这些二进制组件进行集成，最终生成可交付使用的App。因此，我们既需要解决业务线内部多需求持续集成的问题，也需要解决业务线之间的协同工作以及多组件持续集成的问题。

去哪儿网达到目前的持续交付能力并不是一蹴而就的，中间也遇到了各种各样的问题，经历了多个不同的阶段。从第一阶段的源码集成方式，到第二阶段的二进制组件集成方式和大量散点工具的出现，再到今天第三阶段的持续交付流程化、系统化和平台化的转变，我们一直在为移动端的持续交付而努力。

以前，去哪儿网的发版周期是以月为单位的。曾经去哪儿网移动端研发生命周期各个阶段涉及的工具系统是分散的，数据是隔离的，这带来的问题是：用户在研发过程中，需要频繁地切换系统工具，并不断翻译和搬运过程中产生的数据，造成极大的浪费，同时使用成本和学习成本也比较高。为了解决这个问题，我们首先对移动端研发流程进行梳理，使整个流程可视化，制定了列车式发布规范、开发规范及质量基准，对生命周期各个阶段的工具、系统进行整合与重构，采用统一术语、统一权限管理为各个系统的打通提供基础。各系统间借助消息中心，通过消息消费的方式来完成数据的共享，为用户提供了一个支撑移动研发从计划、需求、开发、测试、发布、运维运营全生命周期、全平台、全类型的一站式开放平台——MPortal。目前，我们的平台可以支持Android、iOS Native客户端、动态组件及小程序的持续交付，并且提供了可插拔、易扩展的框架，可以通过不断接入外部系统，持续提升平台支撑能力。

案例实施

1.采用统一术语、统一权限管理

首先，为平台上每个交付对象统一分配全局唯一的标识，我们称之为AppCode。这个AppCode就像我们的身份证一样，一经注册不可改变，无论何时何地，各个系统间的消息通信和数据共享都基于这个唯一标识。每个AppCode拥有不同的属性，包括基础属性、打包配置、发布策略、服务列表等。

其次，为了更好地对平台上各系统的权限进行管理，我们采用了IAM权限管理系统。在IAM系统中按照业务线对用户分组，针对用户组进行授权，提高授权效率；定义角色及各个角色可以进行的操作，用户可直接针对角色进行权限申请，提高了权限申请效率。对其他扩展接入系统的操作可以直接在对应角色的操作列表中追加，已有用户无须额外申请即可自动获取对应的权限，而不用像以前一样需要针对不同的操作在各个系统中多次申请。

2.业务线内部组件的持续交付

过去，去哪儿只有“分支开发，主干发布”一种分支策略，即业务线基于主干分支创建开发分支，在开发分支上进行开发测试，验证没有问题后直接线上发布，同时开发分支的变更自动合并到主干。这种业务线可以实现对Web App开发交付的自主控制，针对业务需求随时上线，因此这种分支策略是高效的。但是，移动App的发布具有周期性，一个组件在一个发布周期内有多个需求需要进行跟版发布，需要对多个需求进行集成测试，因此，原有的分支策略并不能很好地满足我们的需求。所以，我们基于原来的开发分支与主干分支，引入了集成分支。

业务线基于集成分支创建开发分支，在开发分支上提交变更后，用开发分支进行组件的beta打包，组件打包完成后自动触发以该beta包与其他所有组件的最新rc（集成待发布版本）包为依赖的App beta集成验证包。当跟版开发分支经过质量检查后，通过merge request合并到集成分支，生成组件的rc包，进入所有组件的持续集成验证池中。当所有的跟版需求完成集成并通过质量验证后，基于验证通过的最新rc版本生成可以交付跟版的发布包，完成业务线内部组件的持续交付。

当需要对历史版本的问题进行修复时，需要借助hotfix分支。在hotfix分支上完成的修复可以不合并回主干分支。

3.移动App的列车式持续交付

去哪儿App采用的是二进制组件的集成方式，各个二进制组件分属于不同的业务线。为了各条业务线的高效协同，我们采用了列车式持续交付流程。

1）创建发版计划：每次发版前，由平台的发版负责方创建“列车时刻表”（发版计划）。如果发版负责方创建的发版计划不能满足业务线紧急需求的发布，业务线也可以根据自己的实际情况申请“专属车次”（临时版）。临时版审批通过后，会自动创建对应的临时版计划。

2）确认跟版组件版本：默认情况下，计划发版日的前一天，平台会自动生成发版表单，业务线可以在表单中指定对应组件的跟版版本。不做指定的，将采用组件AppCode中设置的默认跟版策略，即最新发布版本或当前线上版本。

3）发布集成验证包：发版日当天指定时间点，平台会自动锁定确认版本并自动生成待发布的集成验证包，然后将该验证包公布给所有业务线进行集成测试。

4）业务线验证及问题修复：业务线针对公布的集成验证包进行验证，针对发现问题的组件申请解锁并更新为修复版本，此处需注明解锁原因及影响范围，并周知所有业务线。

当所有组件修复完毕后，锁定组件，生成并公布新的集成验证包。

5）灰度验证与问题修复：灰度过程中，通过APM实时监控灰度测试情况。如有问题发生，相关人员将会收到告警；如发现严重问题，应立即停止灰度并进行修复。问题修复后，会根据情况决定是否进行多次灰度。

6）全量与渠道发布：对灰度问题进行修复验证后，将针对修复后的版本打正式发布包，经过各业务线确认后，进行站内全量发布，同时自动触发渠道，发布系统上渠道包。

7）线上监控及问题修复：通过APM对线上情况进行实时监控。对发生的问题，通过告警的方式通知相关业务线，业务线针对线上问题可以采用热修复或者紧急临时版的方式进行修复。

8）质量控制与总结优化：为了保证App发版集成的质量，鼓励业务线尽可能在业务线内组件持续交付过程中发现并修复问题，我们采用了积分管理的方式。对于发版集成过程中发现问题进行解锁修复的行为给予扣除积分的惩罚措施。我们会针对每个月的发版情况进行分析与总结，收集业务线的反馈，根据反馈对流程做出适当的调整和优化。

4.建立需求、代码变更与版本的关联

为了更好地掌握组件交付过程中需求的持续集成情况，避免需求遗漏情况的发生，为了更方便、快捷地定位问题、解决问题，我们经常需要知道需求与代码分支、需求与发布版本及代码与发布版本之间的关系。

去哪儿网针对每个需求的开发分支的命名是有规范要求的：每个开发分支需要以需求在JIRA中的ID为前缀或后缀，当开发分支推送到Gitlab服务器以后，会有push事件发送到IC消息中心。JIRA将消费这条消息，通过解析分支中的issue ID，将源码及分支与JIRA中的issue建立关联关系，并将源码及分支信息在对应的issue中进行展示，从而实现需求与代码变更的关联。

在持续交付平台上创建了发版计划后，计划的版本信息会被同步到JIRA中，业务线的PM会根据发版计划对跟版需求进行排期，在对应的issue中选择跟版的版本号，这样就实现了issue与发版版本的关联。

通过issue ID，发版版本与变更的分支也建立了关联关系。在对应AppCode的详情页中，用户可以看到各计划版本下的跟版分支及分支的集成状态，包括已集成、未集成、集成后有更新几种。这样业务线就能很好地了解哪些分支完成了集成，哪些分支尚未集成。所有开发分支到集成分支的集成都是通过merge request的方式来完成的，平台通过解析merge request事件中的来源分支，获取集成的需求issue ID来建立发版版本与集成需求的关联关系。

案例总结

通过这个案例，我们可以更清楚地了解在软件开发过程中，流程、平台与人之间的关系。流程为人的行为提供准则，平台承载流程为人提供自动化工具，输出各种能力，人在使用工具的过程中，不断地总结、学习，持续完善流程与平台，从而持续不断地提高研发效能。