发布运维支撑
发布运维是一个成熟的软件项目中非常核心的部分，它保证了整个项目能够高效且稳定地运转。建立一个稳定可靠的发布运维体系是我们建设整个外卖MRN技术体系的重要目标。但发布运维的建设上下游牵扯了众多基建：拥有一个合理的工程结构对发布运维来说至关重要。如果工程结构臃肿且混乱，将会引起的一系列的权限问题、管理维护问题，这样会严重制约整个发布运维体系的效率。所以MRN的工程架构演进优化也是发布运维体系建设的重要组成部分。
MRN分库 & 工程结构演进
业务分库
任何一个大型、长期的前端技术项目，良好的工程结构都是研发发布支撑中非常核心的部分。从2018年10月份，外卖正式启动MRN项目以来，面临涉及近百个MRN和几十人参与的大规模MRN应用计划。从项目初期，我们就开始寻找一个非常适合开发维护的工程结构。
在*开始的时候，我们的目标是快速验证及落地，使用了一个Git库与一个Talos项目（美团自研发布系统）去承接所有页面的开发及发布工作，同时对权限进行了收缩，保证初期阶段的安全发布。然而随着页面的增多，每个版本的发布压力逐渐增大。发布SOP上的三大关键节点权限：Git库操作权限、Talos的发布权限、美团自研的线上降级系统Horn权限，互不相关，负责人也各异，导致发布时常因各个节点的权限审批问题，严重阻塞效率。
随着项目的大规模铺开，我们的页面数量、合并上线次数与初期已不可同日而语。为了解决逐渐臃肿的代码仓库问题及发布效率问题，我们将庞大而臃肿的RN库根据业务维度和维护团队拆分成了4个业务库，分别是订单业务、流量业务、商家业务、营销业务，并确认各库的主R，建立对应的Talos项目，而主R也是对应Talos项目的负责人。同时所有的主R都有MRN灰度脚本的管控权限。这样一来，MRN的工程结构和Native的工程结构完全对齐，每个责任人都非常明确自己的职责，不会来回地穿插在不同的业务之间，同时业务库任意页面的发布权限都进行了集中，RD只需要了解业务的负责人，即可找到对应的主R完成这个业务的所有相关工作。
工程结构
在项目初期，对于每个库的工程结构，美团内部比较流行的工程结构有两种：一个是适合小型业务开发的单工程多Bundle方案，另一个是相对更适合中大型业务开发的多工程多Bundle方案。
单工程单Bundle方案
顾名思义，单工程单Bundle方案的意思就是一个前端工程承载所有的业务代码，*终的产物也只有一个RN Bundle。通过入参决定具体加载哪个页面。
对于业务不多，参与人不多的团队，使用单工程单Bundle的方式即可快速完成开发、发布。因为通过一次发布就可以完成整个发布的工作，但是带来的弊端也是不可接受的：因为所有业务都耦合在一起，每次更新都会“牵一发而动全身”，增大了问题的隐患。如果多个业务需求同时提测的时候，在团队配合上也是一个极大的挑战，因为新版本号会覆盖旧版本号，导致两个需求提测时会出现相互覆盖的情况。所以我们在立项之初就排除了这种方案。
