工程&研发 - 3 - 毛远俊 - 得物前端monorepo技术架构与实践.pdf

《工程&研发 - 3 - 毛远俊 - 得物前端monorepo技术架构与实践.pdf》由会员分享，可在线阅读，更多相关《工程&研发 - 3 - 毛远俊 - 得物前端monorepo技术架构与实践.pdf（43页珍藏版）》请在三个皮匠报告上搜索。

1、得物前端monorepo技术架构与实践远俊得物客服前端负责远俊深耕前端余年，专注于业务，曾在唯品会、蘑菇街和阿巴巴作过21年加得物，前主要负责得物客服前端中后台体系的建设0102030405背景：散乱且低效的代码复基：统多端的分模型架构：仓研发流程的设计迁移：平滑式的迭代与迁移并存收益：仓带来的成效什么是monorepo?将多个项的源代码、依赖和构建配置等都放在个仓库中管理 仓库中的项可以相关，也可以完全独GitlabAPP1APP2APP3APP4APPAPP1APP2APP3APP4polyrepomonorepo背景：散乱且低效的代码复得物前端架构的现状业务发展快：团队规模从10+到10

2、0+，应数量从10+到150+代码复难：不同业务域中应重复功能模块代码重复多，难复基础能升级难：通的npm组件包依赖，升级进度很难把控构建问题定位难：不同应构建脚本不致，出现问题定位难快&难协作效率低下：不同团队代码格不致，轮岗上成本仓monorepo技术调研国外最佳实践 Google：Piper+Citc Meta：Mercurial+VSCode pnpm workspace/yarn workspace lerna/rush/changesets turborepo/nx workspace社区常的解决案依赖管理发包管理命令脚本管理pnpm workspace+changesets+tu

3、rborepo基：统多端的分模型 如何管理不同端及不同业务的代码件 如何实现仓代码的按需拉取如何管理不同端及不同业务的代码件.deps：不同端的依赖，B端、C端和Node服务 ah5/anode/apps：不同端的录，存放不同业务域应 packages：仓顶层通组件和功能依赖，包括组件、utils shell：不同端的构建脚本件 business：具体的业务域，如商家、客服 _share：当前业务域下通的基础能，包括组件、utils crm：具体应录如何实现仓代码的按需拉取git sparse checkout：稀疏检出，根据检出件配置下载所需要的件sparse-checkout配置件spar

4、se-checkout拉取代码步骤最终拉取的应录如何实现仓代码的按需拉取简化执步骤：命令具CLI+VSCode插件命令具CLIVSCode插件架构：仓研发流程的设计 权限管理 统的研发流程 单元测试 主研发流程权限管理-存在的问题仓下的代码是所有研发可的，研发可以改任何录下的代码 实习万不删除了核代码，提交了怎么办 不同业务研发改了不相关的代码，不提交了怎么办权限管理-解决案基本权限约束流程约束 权限 分保护 件Owner Git hook校验权限管理-基本权限约束Owner：代码仓库的所有者，般为TLMaintainer：代码仓库的维护者，般为TL/PMDeveloper：代码仓库的开发者，

5、般为研发员保护分研发本地没法直接提交release-*hotfix-*master权限管理-基本权限约束Gitlab专业版本提供了codeowners的功能，鉴于此功能的实现扩展了gitlab的功能：持录件Owner权限配置，在CR阶段会有件录权限卡点件owner权限卡点件owner配置权限管理-流程约束 pre-commit和pre-push两个钩函数会对件Owner权限做校验 pre-commit的校验必需的 pre-push的校验是必需的研发流程-存在的问题 每个迭代都有上百个开发分，如何让新建的分不冲突 每个业务域的迭代节奏不致，是仓维度还是应维度的部署发布 研发员技术能参差不，如何减

6、少上成本和保证研发体验 快速的迭代过程中，如何保证不同应的代码CR之间互不影响研发流程-解决案分命名规范统的构建脚本辅助的命令具CLI严谨的MR/CR流程研发流程-分命名规范 Dev分命名规范：feature-应标识-版本号-定义 测试分命名规范：test-应标识-版本号 发布分命名规范：release-应标识-版本号 热修复分命名规范：hotfix-应标识-版本号应标识是唯的研发流程-辅助的命令具安装应的依赖安装三的依赖installaddupdatestartbuildremove命令具dx简化流程、减少理解成本、提升研发效率dx install-s