0. 前言

美团外卖自2013年创建以来，业务一直在高速发展，目前日订单量已突破3000万单，已成为美团点评最重要的业务之一。美团外卖所承载的业务，从早期单一的美食业务发展成为了外卖平台业务。目前除餐饮业务外，闪购、跑腿、闪付、营销、广告等产品形态的业务也陆续在外卖平台上线。参与到美团外卖平台的业务团队，也从早期的单一的外卖团队发展成为多业务团队。每个业务团队虽然都有不同的业务形态，但是几乎都有相同的诉求：需求能不能尽快地上线？

然而，Native应用的发布依赖于应用市场的更新，周期非常长，非常不利于产品的快速迭代、快速试错。同时，作为平台方，我们需要考虑到各个业务团队的诉求，统筹考虑如何建立怎么样的模型、配套什么样的技术手段，才能实现最佳的状态，满足各业务更短周期、高质量的交付业务的诉求。本文会首先回顾美团外卖从早期的月交付，逐渐演变成双周交付，再从双周交付演变成双周版本交付配合周动态交付的过程。然后从外卖的历史实践中，浅谈一个好的持续交付需要综合考虑哪些关键因素，希望对大家有所帮助或启发。

1. 交付模型

一个需求从产生到交付再到用户的手上，要经历需求调研、需求分析、程序设计、代码开发、测试、部署上线等多个环节。在整个过程中，由于涉及到不同角色的人员，而不同角色人员的认知存在差异，不同的程序语言存在差异，不同的开发方式也存在差异。在整个交付需求的过程中，还面临着需求可能会被变更、交付周期可能会被变更等各种情况。这些情况使得需求的交付变得非常复杂、不可预期。而软件开发的首要任务就是持续、尽早地交付有价值的软件。怎么解决这一问题，是软件工程一直在研究的话题。早在20世纪50年代，软件领域就在积极地探索设计什么样的模型可以解决这些问题。常见的包括瀑布流模型、迭代模型、螺旋模型、敏捷模型等等。由于篇幅原因，本文不再做详细的介绍。

2. 什么是持续交付

关注持续交付，不同的企业、不同的团队站在不同的角度存在不同的定义。《 持续交付2.0：业务引领的DevOps精要 》一书认为，站在企业的角度，将持续交付定位为一个产品价值的开发框架，是一个工具集，其中包含了一系列的原则和众多实践，帮助提升企业的内部运转速度和交付效率。

从知乎话题“ 如何理解持续集成、持续交付、持续部署 ”，我们可以看到大部分研发团队，会从软件研发的角度进行定义，他们将软件的开发步骤拆解为持续集成、持续交付、持续部署，其中持续集成指开发人员从编码到构建的过程；持续交付指将已经集成构建完成的代码，交付给测试团队进行测试的过程；持续部署指将测试通过的软件交付给用户的过程。而产品团队会站在产品的角度来看，他们认为持续交付，是从需求的PRD文档提出来，到用户能够感受到这个需求的周期。

从美团外卖业务的角度，我们可以将持续交付定位为“外卖用户”和“外卖团队”之间的紧密反馈流。而外卖团队涉及到PM、UI/UE、RD和QA角色。如下图所示，产品同学从市场或用户的需求和反馈中收集到需求，转换为需求PRD文档，交由设计交互同学设计成期望用户所见的界面和行为，然后交给研发团队进行调研实现。研发团队实现后，再交给测试团队进行测试。等测试团队完成测试后，提交到应用市场，最终交付到用户手上，这个过程是本文所考虑的交付。“持续”指的是，外卖团队将外卖的业务拆分成不同维度的子业务，每个子业务持续通过这个迭代流程不断地优化各个子业务达到最优，从而使整个外卖业务达到最优。

3. 外卖持续交付模型的变迁史

3.1 外卖的早期交付模型

早期外卖的交付模式为“串行交付”，一个版本完成后，开启下一个版本。整个交付过程包括需求评审、需求开发、迭代提测、一轮提测、二轮提测、三轮提测、灰度提测和全量发布8个环节：

由于美团的外卖业务是一个双平台业务，需要同时开发外卖App和美团App，在人力安排上，我们会分成两个组，App组和频道组并行开发。App组开发当前的版本业务，频道组同步上个版本的业务到当前的美团平台版本。整个版本周期耗时六周半左右，遇到节假日会顺延，全年能发版11～12个，版本交付周期如下图所示：

交付模型中关键点

  1. 需求评审分为主打需求、非主打需求和统计需求。
    • 主打需求：客户端开发10d之前进行评审，评审8d后UI提供初稿，评审14d后UI定稿。
    • 非主打需求：两个三方评审窗口，窗口1为窗口2的前5d，窗口2为上一版本二轮测试地一天，UI定稿需要在客户端开发第一周内完成。
  2. 统计需求：需求收集截止到立项评审前一天，三方评审为非主打需求评审后第二天。