然而，Native应用的发布依赖于应用市场的更新，周期非常长，非常不利于产品的快速迭代、快速试错。同时，作为平台方，我们需要考虑到各个业务团队的诉求，统筹考虑如何建立怎么样的模型、配套什么样的技术手段，才能实现最佳的状态，满足各业务更短周期、高质量的交付业务的诉求。本文会首先回顾美团外卖从早期的月交付，逐渐演变成双周交付，再从双周交付演变成双周版本交付配合周动态交付的过程。然后从外卖的历史实践中，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发。
一个需求从产生到交付再到用户的手上，要经历需求调研、需求分析、程序设计、代码开发、测试、部署上线等多个环节。在整个过程中，由于涉及到不同角色的人员，而不同角色人员的认知存在差异，不同的程序语言存在差异，不同的开发方式也存在差异。在整个交付需求的过程中，还面临着需求可能会被变更、交付周期可能会被变更等各种情况。这些情况使得需求的交付变得非常复杂、不可预期。而软件开发的首要任务就是持续、尽早地交付有价值的软件。怎么解决这一问题，是软件工程一直在研究的话题。早在20世纪50年代，软件领域就在积极地探索设计什么样的模型可以解决这些问题。常见的包括瀑布流模型、迭代模型、螺旋模型、敏捷模型等等。由于篇幅原因，本文不再做详细的介绍。
从美团外卖业务的角度，我们可以将持续交付定位为“外卖用户”和“外卖团队”之间的紧密反馈流。而外卖团队涉及到PM、UI/UE、RD和QA角色。如下图所示，产品同学从市场或用户的需求和反馈中收集到需求，转换为需求PRD文档，交由设计交互同学设计成期望用户所见的界面和行为，然后交给研发团队进行调研实现。研发团队实现后，再交给测试团队进行测试。等测试团队完成测试后，提交到应用市场，最终交付到用户手上，这个过程是本文所考虑的交付。“持续”指的是，外卖团队将外卖的业务拆分成不同维度的子业务，每个子业务持续通过这个迭代流程不断地优化各个子业务达到最优，从而使整个外卖业务达到最优。
早期外卖的交付模式为“串行交付”，一个版本完成后，开启下一个版本。整个交付过程包括需求评审、需求开发、迭代提测、一轮提测、二轮提测、三轮提测、灰度提测和全量发布8个环节：
由于美团的外卖业务是一个双平台业务，需要同时开发外卖App和美团App，在人力安排上，我们会分成两个组，App组和频道组并行开发。App组开发当前的版本业务，频道组同步上个版本的业务到当前的美团平台版本。整个版本周期耗时六周半左右，遇到节假日会顺延，全年能发版11～12个，版本交付周期如下图所示：
交付模型中关键点
单月发版优缺点
优点：
缺点：
为了满足日益增长的业务诉求，我们提出了双周发版的交付模式，从而实现业务的快速迭代。贯彻的总体原则为：评审、开发、测试完全并行，以两周为固定周期，以需求维度持续交付。
版本各个角色分工详情示意图如下所示：
双周模型中关键点：
双周迭代模式的变化也推动我们在人力分配方面的改进，人力安排演变经历了三个过程：
在双周迭代的过程中，客户端的交付是连贯的，理想状态是每个RD可以隔版进行需求开发。但是大家都知道，写完需求是不可能没有Bug的，需求的估时也不可能都是5的倍数，这样就会造成很多RD既要开发当前版本，又要解决上个版本的Bug。这间接引入了2个问题：
后来我们经过内部研究，提出了AB分组的方案，保证AB组是隔版本进行开发，当组内需求拆分有冲突时，需要在内部协调消化，避免RD出现每个版本都会参与开发的情况发生。
双周迭代的优点
双周迭代的不足
相比之前的当月发版，虽然双周迭代带来一定收益，但还是存在一些客观的问题：
外卖在历经了双周迭代后，一定程度的缩短了版本交付周期，提高了业务迭代效率，优化了人力安排，但是仍然存在一些问题。对于一些简单的需求来说，像外卖中“我的页面”模块的点击热区扩大（“我的页面”已经是RN页面），实际上开发只需要2天，却仍然要跟随版本迭代的节奏，5.5周后才能上线，需求交付周期仍需进一步缩短。另外，外卖自研动态化框架Mach在大量业务的应用落地，多种开发流程及交付需要，使得双周交付越来越难满足外卖业务版本迭代及交付的节奏。
目前外卖低PV的MRN页面数量已达：56/67，已经覆盖了外卖所有的低PV页面，除核心流量页面均为MRN页面，从页面数量维度，MRN页面占比已达83.58%。
Mach区域动态化覆盖了首页核心流量区、二级金刚页、订单页、点菜页及搜索页，目前上线的模板数已达43个。
在完成了外卖动态化能力的建设后，外卖业务逐渐演进出了两类需求：
面对上述两类需求，现有双周迭代及分组交付流程，对于部分特定需求及小需求不太友好，无法做到需求最快速上线，如上述“我的页面”点击热区扩大。
因此，我们在双周迭代的基础上，演进出了现在的双周迭代结合周迭代的交付模型，交付模型图如下：
目前，外卖的周迭代需求分为两类：
纯动态化需求由于不依赖Native发版，无需依赖Native的全回归，开发完成可随时提测，提测后功能测试完成即可上线，可以做到需求的最快速上线。敏捷迭代内容，不依赖主版本的评审，采用自主评审，自主决策跟版的策略。
而多种动态化方案的开发模式，需要统一的动态化发版及上线能力的支撑。外卖周迭代发版及上线具体可以分为两步：
具体流程如下图所示：
截止目前，外卖周迭代发版经过了15个上线窗口，共计发版50+次。
双周迭代结合周迭代的交付方式进一步缩短了版本的交付周期，从需求收集评审到需求上线对于敏捷需求可以缩短到3.5周。对于纯动态化需求可缩短到1周，最终做到了需求评审做到了需求的快速上线、快速验证、快速修复，敏捷迭代。
在施行了双周迭代结合周迭代后，大大缩短了需求的上线周期，但是同时也提升了版本流程管理的复杂度。怎么样保证版本流程的正常运作呢？外卖C端涉及开发人员分为A、B组及敏捷开发人力；同时涉及美团频道及外卖App双平台，需要考虑双平台的版本迭代周期；涉及阶段多，各阶段都需要人工操作，执行事件多，双端执行事件总计40+；涉及双版本并行开发，仓库代码管理复杂。
原有版本迭代流程，版本各阶段的所有事件都由相应负责人执行。
在版本迭代流程上会耗费了大量的人力。如何解放这部分人力，让整个版本迭代流程自动化，做到无人值守，减少人工操作的失误，是此前外卖前端技术团队面临的非常头疼的问题。
但是通过这种方式，存在一些弊端：
为了解决上述问题，我们和Tide版本管理系统（美团内部组件）共建，实现了现在的外卖C端自动化流程管理。以Gulfstream的版本排期为基准，通过Tide版本管理系统进行事件触发，通过脚本将CI、Stash仓库管理系统、HyperloopX发版打包系统、大象整合，做到代码/分支管理自动化、打包集成自动化、周知提醒自动化、版本流程可视化。
在版本开始前配置好当前版本，后续则会在版本的每个关键节点自动执行需要执行的事件。
各类事件提醒及执行通知如下：
各类提醒确认结果即时展示：
在CI建设方面，我们工作主要集中在以下5个阶段：准备阶段、PR检测、开发阶段、提测阶段和发版阶段。
下面介绍三个CI工作中，外卖场景下的特定检查：
总结
部署和发布，对于移动App来说，已经到了最后的环节。我们认为的部署行为主要指将一个还处在测试的版本提交到测试环境，然后让QA进行测试，发布行为主要指将测试完成的稳定版本提交到线上环境交付给用户。当然对于部署和发布，每个团队都可以思考自己的定义。例如我们进一步的细化部署和发布的行为，可以划分为部署测试环境、部署线上环境、部署回滚、发布灰度、发布灰度监控、发布全量、发布回滚、发布监控等等。下面主要介绍外卖业务在部署发布中，建设的业务事务流和无人灰度监控。
发布在整个交付过程中是最重要的一环，而这个环节涉及的角色主要是RD和QA。我们需要明确的定义这个环节RD和QA的事务，避免角色间沟通不畅，跨角色的任务不清的问题。外卖通过持续的优化流程，明确流程的操作行为，来监督流程的正常运行，形成当前的事务流，如下图所示：
这里需要重点讲解图中的关键点：
其中几个关键点：
首先我们认为持续交付需要遵循以下的原则：
持续自动化
在我们整个交付的过程中，有大量的工作是会重复进行的，如果我们不能将这些重复的操作逐渐变成自动化，我们就需要频繁、反复地去做一些看不到收益，但是又不得不去进行的事情。随着交付的内容变得越来越多，交付的速度要越来越快，团队的疲劳感会越来越重，最终疲于奔命。在实际的工作中，由于发布的形态流程的不标准、生成环境和数据的不一致，我们无法一次性做到所有环节自动化，但这不影响我们先站在全局去思考，去持续地拆解子问题，将子问题逐渐地变成自动化。随着整个交付过程的自动化程度不断提升，整个流程会变得简单容易，这样开发人员可以更加聚焦在完成功能本身的工作上。
前置解决
大部分人心理上对于比较麻烦、比较痛苦的事项，都倾向不做或者拖到最后去做。由于存在这样的心理，如果在交付流程中遇到问题，我们的方案很容易掉到一个陷阱中，倾向保持现状或延后再处理。但是，对于一个多人协作交付的业务来说，这是非常不可取的，越往后处理，对整个交付的影响越大，处理效率越低下。举个例子来说，一个PR可能导致一个历史功能不可用，如果我们在这个同学提这个PR的时候就拦截到，那么只会影响这个同学，也不需要回溯问题；如果延到代码集成环节，那么就需要想办法去找到是谁，然后因为什么原因提这段代码，本次集成就可能直接导致失败，影响其他正在集成的代码。如果拖到测试环境，那么就会涉及至少RD和QA等两个角色去追寻这个问题。所以在持续交付的过程中，我们尽可能尽早地将问题在刚出现时就解决掉，保障整个交付流水线的通畅。
版本化
在我们持续交付的过程中，要将每个环节尽可能的版本化。不仅仅从代码方面版本化，针对数据、配置、环境都可以进一步的版本化。版本化的好处是不言而喻的，首先在实现版本化的过程中，尽可能地将各个环节解耦开，让环节和环节之间没有强依赖。当某一个环节出现异常的时候，我们可以很快地降级到无问题的版本，从而保障整个流水线的持续运转。版本化的另一个好处，就是可回溯，当出现异常的时候，我们可以很快地对比历史版本和当前版本的差异，缩小范围，快速的定位问题。
持续反馈
持续分解改进
针对上述原则，我们可以进一步地来指导外卖持续交付中的关键过程。通过前文所讲，我们认为持续交付就是从产品同学收集到需求，提交到研发团队，最终形成稳定的产品交给用户手上的过程，针对这个过程主要细化包括：
提需求
持续交付启动的第一环对应的就是PM提需求。俗话说“万事开头难”，“提需求”看似是一件容易的事情，其实背后是一个非常复杂的问题，涉及到策略选择、动态规划、排队论等一系列的理论。往往在大部分的团队中，“提需求”被认为是最简单的事情，这使得整个交付流程后续的工作，无法高效开展。
提代码
当单个RD同学认为已经基本完成了功能开发后，就会进入到提代码的环节，也可以叫做代码集成环节。这个环节是个人行为和整体交付产生对接的环节。在这个环节我们要确保个人的行为不影响整体的流水线的进行。
部署测试
当完成代码集成后，就需要进入到测试环节了。那首先我们需要将代码部署到测试环境，因为外卖主要提供App供测试包，所以我们的部署，主要就是打出App包来，周知QA测试。目前外卖的测试，分位一轮新功能测试、二轮全回归测试、三轮主流程回归测试。新功能因为新引入，可能存在前置条件，而在本次测试的过程中，存在需要编写自动化用例和人工测试的用例。但对于老功能，我们希望未来能够尽可能地采用自动化为主的方式。
而在实践的过程中，我们发现自动化测试的一个很重要的前置条件是，数据和环境的可配置性、稳定性。试想下，数据不稳定，一会返回是空，一会返回不为空，是没办法自动化测试校验的。对于这个问题，目前我们的思路是通过建立各环节下根据标准协议定义的Mock数据，将复杂的全链条，拆分成不同节点，在通过配置去控制数据的环境。通过保障每个环节下的质量，来确保整体的质量。
线上监控
保障外卖业务正常线上运行，会需要监控多项的指标。对于如何做好线上监控，我们的思路是设立好各项基线的标准基线，通过脚本获取线上的版本，当检测到新版本，就会自动的创建当前版本的监控。当监控发现线上指标的值和设定的指标基线出现降低时，发生报警行为。而自动化监控最需要考虑的是误报率的问题。版本的发布正常通常又会分为2个阶段，灰度阶段和全量阶段。全量阶段量大，比较稳定，误报率较低；而灰度阶段，量小，不稳定，容易出现误报。而解决这个问题，最好的办法是，本次灰度对比上一次灰度的指标，而非对比上一次全量的指标，维度一样，可以有效地减少误报率。
当前，美团外卖业务仍然处于快速增长阶段，建立怎么样的流程、配套什么的技术手段，才能满足在更短的周期内，高质量地交付业务，进而满足各个业务的发展呢？毫无疑问，持续交付是解决这个问题的重要一环。但针对持续交付这个主题，美团外卖也算是刚刚起步。
未来我们的建设主要集中在2个方向，精细化运营持续集成和建设自动化测试。如上文所述，随着业务越来越复杂，涉及的角色越来越多，代码集成的管控需更加严格，而严格的代码集成管控将增加团队成员每次提代码的痛苦。如何做到差异化的检查和准入，将是未来持续集成的建设方向。