咱们是袋鼠云数栈 UED 团队,致力于打造优异的一站式数据中台产品。咱们始终保持工匠精神,探究前端路途,为社区堆集并传达经历价值。
本文作者:星野
困境频生前端代码办理何解?
前端代码办理一直是困扰着不少前端开发团队的难题,从开发到发布的全体作业流程中,除了常规的技术问题外,往往还伴随着交流本钱、保护本钱及协作功率等问题。这些问题在团队规划较小的时分可能不太明显,但是当团队规划变大时矛盾就越发凸显。 数栈前端开发团队负责着离线开发、实时开发、数据服务、数据财物等多条产品线的开发和保护作业,面临众多的产品线,怎么合理的办理代码,成了团队需求思考的问题,尽管借助了 Multirepo 进行办理,但仍是遇到了许多难题:
-
私有源保护本钱增加
为复用相关事务逻辑,团队内部笼统出一些私有包,由于不能在公网暴露,为了办理这些私有包团队运用了私有源,但由于建立私有源服务器资源问题,私有源常常不稳定且下载速度慢,特别是对于需求源码交给的某些客户来说,装置这些私有包更会遇到各种问题,交给的时刻和人力本钱大大升高。
-
逻辑难复用,重复造轮子
各个库房中会笼统出同一功能的组件,组件之间的同享往往难以同步,形成了「重复造轮子」现象。
-
东西/装备不一致,交流本钱高
各个库房所运用的东西和装备没有进行一致,在进行装备更新的过程中,往往需求同步到各个产品线负责人,交流本钱较高。
这些问题严重拖慢了数栈前端团队从开发到发布的全体流程,一起增加了团队的保护本钱和交流本钱,怎么寻找新的东西处理这些问题已火烧眉毛,在进行了深入调研和屡次讨论的过程中,新的项目办理方法 Monorepo 在这时映入了咱们的眼皮。
Multirepo VS Monorepo
那么 Multirepo 和 Monorepo 到底是什么呢?其实他们别离代表的是两种前端代码办理方法:
-
Multirepo
Multirepo 是一种分散式的前端代码办理方法,依照功能或其他维度,将项目拆分为不同模块并单独保护于各自库房中。作为传统的办理方法,Multirepo 具备灵敏度高、安全控制等特点,但一起也带了办理本钱和写作本钱的增加,依靠晋级等问题。
-
Monorepo
Monorepo 是集中式办理的前端代码办理方法,将所有的项目在集中一个代码库房中进行办理,严格的一致和收归,有利于一致的晋级和办理。作为新式的办理方法,Monorepo 有用降低了运营及协作本钱,但「一个代码库房」的办理模式带来了项目体积的上升,获取时刻延长,一起安全性也有所下降。
上图为 Multirepo 和 Monorepo 的比照图,从图中咱们能够简要归纳:
- Multirepo 由多个库房组成的项目办理方法,每个库房有着独立的作业流、组件与装备。
- Monorepo 将不同库房整合成为一个库房,并同享作业流、组件与装备。
两种办理方法各有千秋,不能简略的定义哪种方法更好,但 Monorepo 的同享机制、一致办理及协作本钱低等优势,显然更契合深陷复杂产品线挑战的数栈前端团队的需求,挑选 Monorepo 也是团队探究功率提高的必定路途。
合适才最好 Monorepo 计划规划
确定了新的办理方法后,接下来面临的便是怎么与数栈相适配的问题。市面上关于 Monorepo 的处理计划和相关东西有许多,尽管 rush、nx 之类的东西能够在特定的领域供给较好的处理计划,但却并不契合咱们的实践需求。 在调研了社区的各种 Monorepo 完成和处理计划之后,结合咱们本身的事务场景和需求,终究咱们挑选了 pnpm 和 turborepo 作为底层的包办理东西和使命调度东西,由于只有最合适的产品才是最好的处理计划。
-
包办理东西-pnpm
在前端社区中,npm、 yarn、 pnpm 三个包办理东西三足鼎立,而咱们终究挑选了 pnpm 原因在于:pnpm 对 monorepo 有着较好的支撑,一起比照其他两个包办理东西,pnpm 在性能等各个方面有着明显的优势
-
使命调度东西-turborepo
使命调度方面,社区中也存在许多优异的东西,如 rush、nx、lerna、turborepo等,综合比照之后,咱们挑选了装备简略易懂、调度更加科学的 turborepo 作为咱们的使命调度东西:
不断探究 Monorepo 落地实践
在确定了底层包办理东西和使命调度东西后,数栈&Monorepo 全体架构计划也清晰了: Monorepo 处理了之前运用 Multirepo 时存在的问题,帮助咱们更好的办理代码,接下来咱们将结合 Multirepo 存在的问题来详细说明 Monorepo 是怎么在数栈产品中落地的。
-
一致装备
Multirepo 存在的一个明显问题是装备的不一致导致的难以保护,所以咱们需求对格式化、代码检测、打包等相关流程的装备进行规范化和一致,一起针对不同产品线的细微差别,也需求支撑其灵敏的扩展。因而咱们在 Monorepo 库房的根目录供给了一致的根底装备,一起如需求进行调整,不同产品线能够承继该装备并进行必要的修正。
-
逻辑复用
Multirepo 存在的另一个明显问题便是逻辑难以复用,搬迁之前的逻辑复用主要是靠笼统到私有包并发布,或者直接复制粘贴,全体功率低,流程长且难以保护。搬迁之后咱们对各种装备等进行了一致的一起,也将公用的事务逻辑和组件整合到了库房根目录的packages目录下,一起通过 pnpm 的 workspace protocal 链接到各个产品线中以便复用。这样不仅处理了逻辑复用的相关问题,一起私有源也不必进行保护,Multirepo 下的私有源保护本钱问题得以处理。
-
权限校验
当根底装备和公共逻辑被暴露出来之后,就面临着这些内容能够被随意修正的问题,而这往往会影响所有的产品线,稍有不小心会形成巨大损失,因而咱们需求给这些重要的内容施以约束和保护。 咱们基于 git hooks 做了一些作业,在 pre-commit 和 pre-push 阶段别离对权限和分支名等内容进行了校验,并定义了 Maintainer、Owner、Deverloper 三个角色,对应的权限别离为:
- Maintainer: 具有悉数权限,能够修正包含根底装备文件等的所有内容。
- Owner: 各产品线或者公共组件主要负责人,具有对应范围内的所有权限。
- Developer: 该产品线或者公共组件的辅助开发人员,只具有包含开发新功能等的部分产品线权限。
角色权限进行清晰的区分之后,咱们能够将根底装备和公共逻辑等内容的修正交给更有经历的工程师。一起权限分配装备保护在本地,这样能够更清晰的了解不同产品线对应的人员,便利交流。
-
主动化搬迁
从 Multirepo 搬迁到 Monorepo 如果采用手动的方法逐一搬迁会有如下问题:
- 搬迁前的各产品线库房存在多个版别需求保护,手动搬迁多个版别作业内容重复且功率较低。
- 人为的操作往往会犯错,且犯错时交流本钱较高。
因而咱们在搬迁的过程中完成了主动化的搬迁流程,主要流程如下:
- 主动克隆原库房的目标分支内容到 Monorepo;
- 删去需求一致的装备如 commitlint 等装备;
- 删去 babel, webpack 等相关重复依靠;
- 检测并替换,采用pnpm的 workspace protocal 链接的内部依靠引进方法;
- 删去 yarn/npm 相关的 lock 文件,并装置依靠生成最新的 pnpm-lock.yaml.
主动化搬迁的完成,保证了搬迁过程的快速且顺利的进行,各产品线的同学能够较为滑润的过渡到新的项目办理方法——Monorepo。
总结
数栈前端团队正式搬迁到了 Monorepo,处理了之前 Multirepo 项目办理方法下的私有源保护本钱高,东西/装备不一致,逻辑复用链路长且难以保护等问题。在搬迁的过程中,完成了大部分搬迁作业的主动化进行,并对重要的装备等进行了权限校验以进行约束和保护。全体提高了数栈前端团队研制的功率,降低了协作和交流本钱,有用完成了降本增效。
最终
欢迎关注【袋鼠云数栈UED团队】~
袋鼠云数栈 UED 团队持续为广大开发者分享技术成果,相继参与开源了欢迎 star
- 大数据分布式使命调度体系——Taier
- 轻量级的 Web IDE UI 结构——Molecule
- 针对大数据领域的 SQL Parser 项目——dt-sql-parser
- 袋鼠云数栈前端团队代码评审工程实践文档——code-review-practices
- 一个速度更快、装备更灵敏、运用更简略的模块打包器——ko
- 一个针对 antd 的组件测试东西库——ant-design-testing