关于网站建设与维护的心得体会,镇江特色,天津网站建设哪里好,绵阳的网站建设公司0. 前言 美团外卖自2013年创建以来#xff0c;业务一直在高速发展#xff0c;目前日订单量已突破3000万单#xff0c;已成为美团点评最重要的业务之一。美团外卖所承载的业务#xff0c;从早期单一的美食业务发展成为了外卖平台业务。目前除餐饮业务外#xff0c;闪购、跑… 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组开发当前的版本业务频道组同步上个版本的业务到当前的美团平台版本。整个版本周期耗时六周半左右遇到节假日会顺延全年能发版1112个版本交付周期如下图所示 交付模型中关键点 需求评审分为主打需求、非主打需求和统计需求。 主打需求客户端开发10d之前进行评审评审8d后UI提供初稿评审14d后UI定稿。非主打需求两个三方评审窗口窗口1为窗口2的前5d窗口2为上一版本二轮测试地一天UI定稿需要在客户端开发第一周内完成。统计需求需求收集截止到立项评审前一天三方评审为非主打需求评审后第二天。 服务器在需求评审后客户端开发第一周前提供接口文档。客户端开发周期为两周客户端开发第5个自然日API提测客户端开发第5天发迭代提测包第二周结束发提测包。QA验收提测包一轮3d、二轮3d、三轮1d。灰度3d需避开节假日前发灰度。全量发布电子市场。单月发版优缺点 优点 每个版本可根据当版的情况控制版本的周期可同时支持多个大需求的并行开发。版本较为固定各角色的分工明确开发人员在开发期较为专注开发效率高。测试周期长App能够得到充分的测试。缺点 版本迭代周期较长从需求评审开始到需求灰度需要6.5周无法满足日益增长的业务诉求对于一些尝试性项目无法满足PM急迫上线验证效果的需求。发版频率低每年只有11~12个版本对标其他互联网公司业务产出相对较低。每个角色的利用率不高如RD在开发期的时候QA处在待测试状态。3.2 双周迭代的交付模型实践 为了满足日益增长的业务诉求我们提出了双周发版的交付模式从而实现业务的快速迭代。贯彻的总体原则为评审、开发、测试完全并行以两周为固定周期以需求维度持续交付。 3.2.1 双周迭代模型 在切换双周迭代模式之前需要落地一些准备工作例如统一版本排期的时间表、确定项目中各个角色的交付时间让PM、UI、客户端RD、服务端RD和QA各角色都能够清晰的知道自己接入的时间点并在规定的时间点交付内容。由于各角色的任务和分工得到了明确减少了协作中的沟通成本各角色也可以如齿轮一样持续产出交付给下游团队整个交付周期效率得到了有效的提升一个版本的周期缩短为5.5周发版次数上升到22~24版本。 版本各个角色分工详情示意图如下所示 双周模型中关键点 W1需求评审周三PM组织三方评审业务需求埋点需求UI需求。W2排期周三API RD出排期周四客户端RD出排期UI产出视觉初稿。客户端RD排期需细化至需求可提测时间点便于QA、PM和UI提前协调测试、验收时间。W3接口评审服务端先行开发接口文档UI资源周四前到位。W4客户端开发周四API提测最晚。W5客户端开发冒烟测试RD开发完后直接冒烟测试以需求维度交付给QA不需要等到最后一天集中冒烟测试需求交付后PM与UI可介入验收环节。W6客户端测试周二服务端上线客户端一轮测试结束前PM与UI应完成需求验收。W7灰度周二全量理想状态一个版本的周期为五周半。W3时PM会继续组织三方评审W4时API继续开发下版本W5时客户端RD会继续下一个版本的开发。3.2.2 分组交付 双周迭代模式的变化也推动我们在人力分配方面的改进人力安排演变经历了三个过程 在双周迭代的过程中客户端的交付是连贯的理想状态是每个RD可以隔版进行需求开发。但是大家都知道写完需求是不可能没有Bug的需求的估时也不可能都是5的倍数这样就会造成很多RD既要开发当前版本又要解决上个版本的Bug。这间接引入了2个问题 个人成长方面单个RD可能会在同一个时间段内出现又要评审需求、又要开发需求、又要改Bug时间长了会堆积疲惫感。另外需求的估时不是5的倍数每个版本单个RD是否能满人力工作是不确定的不利于资源的分配。人力分配合理性版本的需求是存在不确定性的而App的需求熟悉度是存在和RD一一对应的当熟悉度最高的RD在上个版本的时候当前版本的版本主R就会很头疼是“能者多劳”还是“合理分配”给人力分配的合理性又带来了新的挑战。 后来我们经过内部研究提出了AB分组的方案保证AB组是隔版本进行开发当组内需求拆分有冲突时需要在内部协调消化避免RD出现每个版本都会参与开发的情况发生。 AB分组施行以后每个RD都是各版本开发的不会出现同一个时间段内要处理上个版本的Bug和当版需求的情况。但业务的熟悉度和RD的强对应关系还是没有得到解决所以我们就进一步的思考提出采用业务维度AB组。如下图所示我们先将同学进行业务划分在以业务组进行AB的划分。当然这个业务组人员的数量需要考虑业务的规划情况当某一个业务需求量增长上来的时候业务组的大小也需要同步进行增长。 3.2.3 双周迭代的优缺点 双周迭代的优点 提高了业务迭代效率从而提升了业务的产出以一月能够完成二个版本的交付速度持续地交付版本达到一年交付20-24个版本的交付目标。在人力整合利用上更加合理化各角色都能够持续的产出版本的交付周期变为5.5周。双周迭代的不足 相比之前的当月发版虽然双周迭代带来一定收益但还是存在一些客观的问题 从评审到交付发布周期还是太长产品快速上线的诉求依然不能得到很好的满足。敏捷性受到一定影响对于特定需求和小需求不是很友好。3.3 双周结合周交付的模型实践 外卖在历经了双周迭代后一定程度的缩短了版本交付周期提高了业务迭代效率优化了人力安排但是仍然存在一些问题。对于一些简单的需求来说像外卖中“我的页面”模块的点击热区扩大“我的页面”已经是RN页面实际上开发只需要2天却仍然要跟随版本迭代的节奏5.5周后才能上线需求交付周期仍需进一步缩短。另外外卖自研动态化框架Mach在大量业务的应用落地多种开发流程及交付需要使得双周交付越来越难满足外卖业务版本迭代及交付的节奏。 3.3.1 动态化能力的建设 为了满足业务需求的快速上线及外卖面临的包体积的压力外卖引入了动态化来解决此类痛点问题。外卖动态化能力建设的思路主要是核心流程页面区域动态化区域动态化方案采用外卖自研的Mach动态化框架核心流程采用区域动态化保证页面的稳定性及用户体验非核心流程页面MRN化Meituan React Native通过MRN来替换所有的低PV页面下线Native页面。具体技术细节可参考《React Native在美团外卖客户端的实践》一文。 目前外卖低PV的MRN页面数量已达56/67已经覆盖了外卖所有的低PV页面除核心流量页面均为MRN页面从页面数量维度MRN页面占比已达83.58%。 Mach区域动态化覆盖了首页核心流量区、二级金刚页、订单页、点菜页及搜索页目前上线的模板数已达43个。 3.3.2 双周迭代周迭代 在完成了外卖动态化能力的建设后外卖业务逐渐演进出了两类需求 主版本需求主版本需求主要是Native方式实现结合少部分动态化需求。敏捷开发需求主要通过动态化和敏捷模型的加入实现高效的版本迭代动态化主要指上节所介绍的动态化能力的建设敏捷模型采用前文所说的敏捷模型。面对上述两类需求现有双周迭代及分组交付流程对于部分特定需求及小需求不太友好无法做到需求最快速上线如上述“我的页面”点击热区扩大。 因此我们在双周迭代的基础上演进出了现在的双周迭代结合周迭代的交付模型交付模型图如下 双周迭代结合周迭代的交付模型是在原有双周迭代的基础上保持主版本需求双周迭代不变增加每周的动态上线窗口以每周二为动态上线窗口时间周五为提测DeadLine根据动态化需求的开发及提测时间来动态搭车上线。 目前外卖的周迭代需求分为两类 纯动态化需求根据需求开发及测试排期选择上线窗口搭最近一次的上线窗口。动态化结合Native需求跟随主版本交付流程在提测周发版上线主要面向敏捷迭代内容。纯动态化需求由于不依赖Native发版无需依赖Native的全回归开发完成可随时提测提测后功能测试完成即可上线可以做到需求的最快速上线。敏捷迭代内容不依赖主版本的评审采用自主评审自主决策跟版的策略。 而多种动态化方案的开发模式需要统一的动态化发版及上线能力的支撑。外卖周迭代发版及上线具体可以分为两步 发版。将动态化模板进行打包得到Bundle并上传通过Talos平台美团内部自研进行打包Talos是基于前后端分离思想设计的一套前端DevOps解决方案。上线。将通过Talos打包得到的Bundle上线发布发布通过EVA客户端动态分发平台进行线上发布。具体流程如下图所示 截止目前外卖周迭代发版经过了15个上线窗口共计发版50次。 双周迭代结合周迭代的交付方式进一步缩短了版本的交付周期从需求收集评审到需求上线对于敏捷需求可以缩短到3.5周。对于纯动态化需求可缩短到1周最终做到了需求评审做到了需求的快速上线、快速验证、快速修复敏捷迭代。 3.4 自动化版本管理系统 在施行了双周迭代结合周迭代后大大缩短了需求的上线周期但是同时也提升了版本流程管理的复杂度。怎么样保证版本流程的正常运作呢外卖C端涉及开发人员分为A、B组及敏捷开发人力同时涉及美团频道及外卖App双平台需要考虑双平台的版本迭代周期涉及阶段多各阶段都需要人工操作执行事件多双端执行事件总计40涉及双版本并行开发仓库代码管理复杂。 原有版本迭代流程版本各阶段的所有事件都由相应负责人执行。 分支创建、版本降级检查、每日QA包号周知仓库集成及基础库同步、打包提测邮件等都由迭代工程小组人员负责执行。仓库拉出Release分支提审灰度后分支合并、集成、发版由外卖各仓库负责人负责执行。周迭代、迭代、一轮、二轮、三轮提测阶段冒烟周知则通过排班的形式在冒烟提测当天由人工提醒并监督。在版本迭代流程上会耗费了大量的人力。如何解放这部分人力让整个版本迭代流程自动化做到无人值守减少人工操作的失误是此前外卖前端技术团队面临的非常头疼的问题。 在我们规范了双周迭代周迭代的流程后版本各阶段的时间能够基本固定。为了能够做到自动化我们把版本各阶段需要人工操作的事件整理归类把事件确定到当前版本的固定一天固定时间点以一个版本为例我们整理归类如下 确定好所有事件的执行时间后我们便尝试把所有需要人工操作的事件自动化。并通过在确定的时间去触发来做到整个版本流程的自动化。 早期的版本管理我们依托于Gulf美团内部日期管理系统、QA-Assistant系统美团内部事件通知系统、CI及大象美团内部通讯工具消息通过在Gulf系统提前配置好各版本各事件的时间并通过QA-Assistant配置人员名单及消息在固定时间节点Gulf去触发QA-Assistant通过上述方式做到了各类提醒的自动化并且在CI上部署上自动化Job由人工触发。 但是通过这种方式存在一些弊端 版本各节点事件都需人工单独一个个配置且Gulf和QA-Assistant系统的触发一直需要关注。仍然需要大量人工操作只能做到流程的半自动化人力还是无法做到解放。版本流程无法做到可视化。为了解决上述问题我们和Tide版本管理系统美团内部组件共建实现了现在的外卖C端自动化流程管理。以Gulfstream的版本排期为基准通过Tide版本管理系统进行事件触发通过脚本将CI、Stash仓库管理系统、HyperloopX发版打包系统、大象整合做到代码/分支管理自动化、打包集成自动化、周知提醒自动化、版本流程可视化。 在版本开始前配置好当前版本后续则会在版本的每个关键节点自动执行需要执行的事件。 Tide版本管理可视化界面如下按照版本各阶段及时间线顺序排列 各类事件提醒及执行通知如下 各类提醒确认结果即时展示 3.5 CI建设 在CI建设方面我们工作主要集中在以下5个阶段准备阶段、PR检测、开发阶段、提测阶段和发版阶段。 下面介绍三个CI工作中外卖场景下的特定检查 Aimeituan工程独立编译自动配置同事反馈配置团App源码依赖的配置项较繁琐切换开发分支时需要反复进行配置为了提供RD的开发体验通过脚本自动修改WM提测分支的源码依赖配置项只需修改Aimeituan的gradle.properties一个属性实现源码依赖切换实现一键切换的功能提高版本开发效率优化项包括 业务方依赖只保留团首页和外卖业务。只保留开发调试必要的插件ServiceLoader和WmRouter提高编译速度。只保留调试Flavor提高编译速度。业务库检测是否有PR未合入版本快速迭代对代码管理也带来了挑战发生了几次因为RD未及时合入代码影响QA提测进度的问题因此在打提测包之前增加了一个检测环节如果检测到有PR未合入提测分支将在大象群统一周知发起人提高版本的交付质量。定时检测壳工程是否有更新自动触发打包保证QA第二天能回归前一天所有的修改避免测试返工的问题提高版本测试有效性。总结 Aimeituan独立编译配置从510分钟同事反馈从修改配置到同步完成的耗时降低到45s左右优化了80%90%。 在经过了几个版本的实践证明自动化检测PR合入是有必要的而且能够有效降低开发人为失误导致漏提交代码发生的概率。 每天早上同步Aimeituan的Release分支及时周知负责人同步结果减少人工Check的重复工作。 3.6 部署发布 部署和发布对于移动App来说已经到了最后的环节。我们认为的部署行为主要指将一个还处在测试的版本提交到测试环境然后让QA进行测试发布行为主要指将测试完成的稳定版本提交到线上环境交付给用户。当然对于部署和发布每个团队都可以思考自己的定义。例如我们进一步的细化部署和发布的行为可以划分为部署测试环境、部署线上环境、部署回滚、发布灰度、发布灰度监控、发布全量、发布回滚、发布监控等等。下面主要介绍外卖业务在部署发布中建设的业务事务流和无人灰度监控。 3.6.1 发布事务流 发布在整个交付过程中是最重要的一环而这个环节涉及的角色主要是RD和QA。我们需要明确的定义这个环节RD和QA的事务避免角色间沟通不畅跨角色的任务不清的问题。外卖通过持续的优化流程明确流程的操作行为来监督流程的正常运行形成当前的事务流如下图所示 这里需要重点讲解图中的关键点 事务流中RD负责交付代码到测试环境QA同学负责测试环境的和线上环境的验证。RD和QA角色按照时间顺序各自前面工作和后面工作事项归属清晰明确。流程中设置TL Approve和QA Approve同时RD作为代码的完成者只具备测试环境的部署权限最终线上的权限由QA掌控做到了上线的双角色Check避免了RD即是“裁判员”又是“运动员”的情况。当完成测试时候部署线上环境和线上环境发布都做到自动执行通过自动化的手段节约重复的工作。3.6.2 无人值守灰度 一个功能上线往往要经历灰度到全量的过程。由于灰度已经是到了交付到用户手上的最终环境灰度前的检查和放量都非常重要需要做到万无一失。灰度的次数往往是全量次数的2~3倍这使得灰度的成本在整个交付流程中也变得非常高。理想情况下我们希望发布前的流程都做到自动化灰度的过程也无需人工参与自动的放量、停灰、全量出现异常自动执行灰度SOP、监控项也在灰度的时候自动开启出现异常自动同步信息给相关方。但在实际过程中由于平台的差异部分环节还是很难做到例如iOS的发布。下图是外卖业务无人值守灰度的流程 其中几个关键点 起始点来源于我们录入的GulfStream日期由于双周迭代后版本的迭代周期是可预期的所以能够以季度维度录入GulfStream中由此处触发整个链条的启动。我们利用Tide版本管理系统将版本的日期自动读入在需要发布的节点前自动检查做好自动化检查部分无法自动化的由Tide系统提醒RD和QA去做检查。定义好灰度放量策略在发布时按照设定策略自动发布放量。外卖业务非常复杂监控的内容也很复杂对这个环节不是很熟悉的同学是很难胜任监控运维工作的自动化更是无法执行因此外卖的策略是将监控报警标准化制定SLA分级别定义监控、报警、预案、执行人当版本发布后触发监控Job以分钟级去CAT已经开源、Sniffer、Crash等等平台去拉取当前灰度版本的数据和定义的指标比较。如果在合理定义范围内继续监控。如果出现异常大象定向通知相关处理人。这样使得灰度的自动化监控工作的执行过程是可操作的。4.外卖持续交付的总结 美团外卖业务应该建立怎么样的模型、配套什么的技术手段才可以在更短的周期内高质量地交付业务满足各团队的发展呢我们从早期的单月交付到双周交付再到双周交付结合周交付我们在不断地尝试和演进外卖的持续交付模型。随着不断的深入了解我们发现这是一个很大的话题。到目前为止美团外卖团队在这条路上只能算得上是刚刚起步。不过在实践的过程中我们也逐渐地摸索到一些经验在此分享一下我们的思考。 4.1 遵循原则 首先我们认为持续交付需要遵循以下的原则 持续自动化 在我们整个交付的过程中有大量的工作是会重复进行的如果我们不能将这些重复的操作逐渐变成自动化我们就需要频繁、反复地去做一些看不到收益但是又不得不去进行的事情。随着交付的内容变得越来越多交付的速度要越来越快团队的疲劳感会越来越重最终疲于奔命。在实际的工作中由于发布的形态流程的不标准、生成环境和数据的不一致我们无法一次性做到所有环节自动化但这不影响我们先站在全局去思考去持续地拆解子问题将子问题逐渐地变成自动化。随着整个交付过程的自动化程度不断提升整个流程会变得简单容易这样开发人员可以更加聚焦在完成功能本身的工作上。 前置解决 大部分人心理上对于比较麻烦、比较痛苦的事项都倾向不做或者拖到最后去做。由于存在这样的心理如果在交付流程中遇到问题我们的方案很容易掉到一个陷阱中倾向保持现状或延后再处理。但是对于一个多人协作交付的业务来说这是非常不可取的越往后处理对整个交付的影响越大处理效率越低下。举个例子来说一个PR可能导致一个历史功能不可用如果我们在这个同学提这个PR的时候就拦截到那么只会影响这个同学也不需要回溯问题如果延到代码集成环节那么就需要想办法去找到是谁然后因为什么原因提这段代码本次集成就可能直接导致失败影响其他正在集成的代码。如果拖到测试环境那么就会涉及至少RD和QA等两个角色去追寻这个问题。所以在持续交付的过程中我们尽可能尽早地将问题在刚出现时就解决掉保障整个交付流水线的通畅。 版本化 在我们持续交付的过程中要将每个环节尽可能的版本化。不仅仅从代码方面版本化针对数据、配置、环境都可以进一步的版本化。版本化的好处是不言而喻的首先在实现版本化的过程中尽可能地将各个环节解耦开让环节和环节之间没有强依赖。当某一个环节出现异常的时候我们可以很快地降级到无问题的版本从而保障整个流水线的持续运转。版本化的另一个好处就是可回溯当出现异常的时候我们可以很快地对比历史版本和当前版本的差异缩小范围快速的定位问题。 持续反馈 在整个交付的过程中每个环节都可能出错。当出错的时候需要快速地反馈到相关的负责人。该负责人也需要尽快地将反馈的问题处理给予一个稳定的版本。如果没有反馈这个环节导致了整个交付流水线被阻塞的人可能完全不知道自己造成了阻塞。另外在一个功能的交付过程中可能会有多次提交代码、多次集成、多次测试如果每次是什么样的结果都无法得到反馈那么整个交付的风险会逐渐累积。只有将问题更早地反馈、更早地处理才能有效地降低整个功能交付的风险。 持续分解改进 不管我们当前将整个交付的过程做到了多么高效未来随着业务的发展新成员的加入和离开交付的过程都在逐渐发生衍变。正如《谈谈持续集成持续交付持续部署之间的区别》一文提到的“持续部署是理想的工作流”一样想一劳永逸解决所有问题是一种理想的工作状态。随着时间的推移交付的过程会出现新的问题交付的效率又会开始逐渐下降。如果要长久地保持交付效率能够有持续的改善我们需要不断地对抽象的交付过程进行分析层层剥离将整个交付过程转变成一系列小而可以解决的问题然后持续地解决这些小问题。 4.2 关键步骤 针对上述原则我们可以进一步地来指导外卖持续交付中的关键过程。通过前文所讲我们认为持续交付就是从产品同学收集到需求提交到研发团队最终形成稳定的产品交给用户手上的过程针对这个过程主要细化包括 提需求 持续交付启动的第一环对应的就是PM提需求。俗话说“万事开头难”“提需求”看似是一件容易的事情其实背后是一个非常复杂的问题涉及到策略选择、动态规划、排队论等一系列的理论。往往在大部分的团队中“提需求”被认为是最简单的事情这使得整个交付流程后续的工作无法高效开展。 我们细分析下需求根据大小可以分成大需求、小需求根据优先级可以分成高、中、低需求根据开发的人员不同又可以分成前端需求、后端需求、策略需求等等。需求提出来后怎么快速地判断出如何划分这个需求需求的优先级是什么需求的上线时间怎么样谁来做这个需求这个需求会涉及到谁。在涉及到这个需求和其他需求的比较时才能回答刚才提到的问题这又涉及到需求的定义需求产出比的基线问题。 在外卖的交付模型中对于“提需求”主要遵循的是组织管理原则即以组织结构为单位当前组织下的PM给予当前组织下的RD提出需求需求的优先级也以当前组织下的事项进行综合考虑。这样的好处不言而喻比较敏捷。劣势是当遇到跨组织需求工作成本会急剧增加。同时我们通过交付模型将提需求的时间点可预见在每次提需求的环节严格要求每一组织下的需求给予明确的优先级。每次提出的需求数量、需求评审时长标准化。并且配套标准的需求模板让PM在提出需求时自我完成需求边界检查需求涉及方的前置沟通。通过这样的组织管理手段、模板管理手段、流程标准化手段来尽可能地保证提需求的质量。 提代码 当单个RD同学认为已经基本完成了功能开发后就会进入到提代码的环节也可以叫做代码集成环节。这个环节是个人行为和整体交付产生对接的环节。在这个环节我们要确保个人的行为不影响整体的流水线的进行。 如何保障我们采用的手段主要是本地检查CI检查集成测试。当代码检查通过后代码的集成是自动完成无需个人干预。不过这里也存在一个矛盾点如果本地检查CI检查项集成测试项越来越多检查的时间将会非常长这将会使得每次提交代码变得异常痛苦。而如何解决这个问题最好的手段我们认为是通过持续优化代码的架构来让每次RD的代码修改尽可能范围小。这样对于有特定范围的修改本次CI检查就存在可简化的可能性。 部署测试 当完成代码集成后就需要进入到测试环节了。那首先我们需要将代码部署到测试环境因为外卖主要提供App供测试包所以我们的部署主要就是打出App包来周知QA测试。目前外卖的测试分位一轮新功能测试、二轮全回归测试、三轮主流程回归测试。新功能因为新引入可能存在前置条件而在本次测试的过程中存在需要编写自动化用例和人工测试的用例。但对于老功能我们希望未来能够尽可能地采用自动化为主的方式。 而在实践的过程中我们发现自动化测试的一个很重要的前置条件是数据和环境的可配置性、稳定性。试想下数据不稳定一会返回是空一会返回不为空是没办法自动化测试校验的。对于这个问题目前我们的思路是通过建立各环节下根据标准协议定义的Mock数据将复杂的全链条拆分成不同节点在通过配置去控制数据的环境。通过保障每个环节下的质量来确保整体的质量。 线上监控 保障外卖业务正常线上运行会需要监控多项的指标。对于如何做好线上监控我们的思路是设立好各项基线的标准基线通过脚本获取线上的版本当检测到新版本就会自动的创建当前版本的监控。当监控发现线上指标的值和设定的指标基线出现降低时发生报警行为。而自动化监控最需要考虑的是误报率的问题。版本的发布正常通常又会分为2个阶段灰度阶段和全量阶段。全量阶段量大比较稳定误报率较低而灰度阶段量小不稳定容易出现误报。而解决这个问题最好的办法是本次灰度对比上一次灰度的指标而非对比上一次全量的指标维度一样可以有效地减少误报率。 5. 展望 当前美团外卖业务仍然处于快速增长阶段建立怎么样的流程、配套什么的技术手段才能满足在更短的周期内高质量地交付业务进而满足各个业务的发展呢毫无疑问持续交付是解决这个问题的重要一环。但针对持续交付这个主题美团外卖也算是刚刚起步。 未来我们的建设主要集中在2个方向精细化运营持续集成和建设自动化测试。如上文所述随着业务越来越复杂涉及的角色越来越多代码集成的管控需更加严格而严格的代码集成管控将增加团队成员每次提代码的痛苦。如何做到差异化的检查和准入将是未来持续集成的建设方向。 我们可以针对不同类型的PR不同时间节点下的PR实施不同的差异化定制规则检查在合入质量和检查周期上寻找到一个合适的平衡点。另外对于测试环节目前美团外卖还是主要集中在人工保障环节大量的测试Case。我们希望未来能够尽可能地采用自动化为主的方式进行测试而让QA可以集中精力测试新功能或非常边界异常的场景验证。 6. 参考文献 如何理解持续集成、持续交付、持续部署谈谈持续集成、持续交付、持续部署的区别持续交付2.0业务引领的DevOps精要作者简介 晓飞2015年加入美团美团外卖团队技术专家。王鹏2017年加入美团美团外卖团队高级工程师。江伟2018年加入美团美团外卖团队高级工程师。
