作者:HannahLin
起源:medium
有幻想,有干货,微信搜寻【大迁世界】关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录,有一线大厂面试残缺考点、材料以及我的系列文章。
Monorepository (简称 Monorepo) 概念尽管有一段历史了,但这个名词却是近几年才变得如此热门。本人公司也是这半年才导入这个架构,再尝到许多苦头后想写一篇来介绍它,心愿多一点人意识此架构。这篇并不会有源代码,而是从现有架构痛点开始 (Single Repo Monolith
、Multi-repo
)、为什麽要用 Monorepo 等等。
现有架构遇到了什麽问题 ?
20 年前的前端相当单纯,但在这 6 ~7 年却产生巨变,当初应该没几个人只用纯 html/css/js
做出网站了,大部分都是以前端框架登程搭配一大堆的 dependencies (SCSS preprocessors、task managers、npm、typescript…)。当团队倒退到肯定规模又会分出好几个不同产品,每一个产品应用的 dependencies
都不大雷同使得保护变得艰难,到底要怎麽做到防止重覆源码以及分好责任归属呢?通过理论例子来介绍一下。
若 shop.com 公司明天有数个专案,每一个专案都有不同负责的团队.
购物网站 shop.com (React)
结帐 shop.com/cart
购物网站手机版 m.shop.com (不是 RWD,是独立网站)
后盾 admin.shop.com (Vue)
剖析使用者网站 analytics.shop.com (Angular)
Note. 尽管不同专案你能够抉择用不同前端框架,但若都用同一种会看到 monorepo 的更大益处。
shop.com 跟 shop.ocm/cart 尽管是在一个 domain 底下,但负责的却是齐全不同的团队
在这种简单的架构下,咱们比拟相熟的办法为 Monolith 跟 Multi repo [延长浏览: 初探 Micro Frontends 程式架构]
Single-repo Monolith 😰
最开始大家都是应用这种架构开发的,但随著前端工程日益複杂,前端须要做的事越来越多、更多 dependencies 被引入,在 Single-repo Monolith 架构下整包会变超级瘦小,部署时也必须要整包一起,想当然尔 delopy 工夫都爆久,这样的架构毛病很显著,也无奈达到高扩充性与高效率的组织开发。
Single-repo Monolith
apps
├ node_modules
├ libs // 放 share 的東西
├ design-systems
| ├ node_modules
| ├ xx...
├ shop
| ├ node_modules
| ├ cart
| | ├ xx...
| ├ xx...
├ shop-mobile
| ├ node_modules
| ├ xx...
├ admin
| ├ node_modules
| ├ xx...
├ analytics
| ├ node_modules
| ├ xx...
├ e2e
| ├ xx...
Multi repo 😢
当初大部分的前端会採用 Multi repo,每一个独立案子都会有绝对应 repo,团队各自保护本人 product,釐清责任也很容易
Design-systems Repository
design-systems
├ node_modules
├ e2e
├ xxxx
Shop Repository
shop
| ├ node_modules
| ├ e2e
| ├ xx...
Shop Cart Repository: Cart Cart 因为附属另一个团队所以会拆分成两个 Repository
shop-cart
| ├ node_modules
| ├ e2e
| ├ xx...
Mobile Version Repository
shop-mobile
| ├ node_modules
| ├ e2e
| ├ xx...
Admin Repository
admin
| ├ node_modules
| ├ e2e
| ├ xx...
Analytics Repository
analytics
| ├ node_modules
| ├ e2e
| ├ xx...
看似不错,但问题又来了
重覆配置
Multi repo 因为每一个 repo
都是独立的,所以必须建本人的 webpack
、开发环境、如何 deploy
等等,若十个 repo
就要保护这 10
个配置,若 repo
之间都不统一,那治理很麻烦
共用代码保护老本变很高
projects
间许多逻辑是反复的,但因为不同 repo
,所以在 debug
时就要一次修五份,保护耗时耗力老本相当高。你可能会想那把会反复用到的货色另外拉进去独自创一个 libs Repository
,间接改 libs
得货色即可,那流程就会变成改
- libs Repository,version 从 1.0 到 1.1 2.
- shop、shop-mobile、admin、analytic 装置最新的 libs 1.1
- commit 变动,再 push 更新个自 repo,期待 deploy
这也是 Multi repo 最常被埋怨的事,因为 Repo 被切得太细了,导致只是 share code
小改变流程也超简单,所花工夫也绝对变很高。
dependencies 的版本治理变异样複杂
react 17.0.2
而 shop 还在 15.6
,若新版本捨弃某些反对,就会产生 bug。或是因为没有及时 pull 最新的 libs Repo 所以更新不及时而产生 bug。
Mono repo 😊
Mono repo
能够解决下面 Multi repo 的痛点,因为只有一个 Repo 所以治理起来很不便,一个 webpack、一个 test suite runner
、共用 dependency
若有变动,那有用到此 dependency 的 project 都会晓得,并且因为只有个 repo 所以大家都是应用最新的 code 不会用更新不及时的情况。
apps
├ design-systems
├ design-systems-e2e
├ shop
| | ├ cart
├ shop-e2e
├ shop-mobile
├ shop-mobile-e2e
├ admin
├ admin-e2e
├ analytics
├ analytics-e2e
node_modules
libs
├ utils
libs
上面能够放任何会被共用的货色,例如 design systems
、TS Interfaces
、JS Utilities
等等。这样架构各自团队是只专一本人的我的项目,例如 shop-mobile team 只会改这个 folder 里的货色,build 时也能够独自跑 shop-mobile only。
尽管 monorepo
是主打 一个 repo,一个 package.json
,但本人公司还是会把一些 team specific 的 package 放到本人的 folder 外面,例如很确定只有 design-system 有用到 gatsby。所以这边设置还是能够针对本人公司做调整,但若这个 package 将来很有可能被别的 team 用,最好也是放到最外层。
apps
├ design-systems
| ├ node_modules
├ design-systems-e2e
长处
- 对立治理 configs and tests: 因为只有一个
repo
所以不须要再重覆配置环境,包含CI/CD
、unit
、e2e
、webpack
都只须要保护一份就好 - 部署工夫很快 : 尽管是同一个 repo 但能够针对不同案子设定 CI/CD 个别部署。若 share code 有变动,你不须要 pull request multi-repo 的每一个专案,而是只有去更新有用到此 share code 的案子即可。
- 治理 dependency 变很容易 : 一个
repo
,一个package.json
- 能生蚝利用 share code (libs)
- 编译工夫: 应用
monorepo
编译工夫并不会变慢,因为应用好的monorepo
工具 (例如 nx) 都帮你做好缓存跟效力优化了
当然,monorepo 还是有一些毛病
- codebase 宏大
- 所有人都能够改变别的 team 的 code: 因为只有一个
repo
,但这不是大问题,因为把 code push 下来都须要通过 pull request 审核,若轻易都被 approved 那就是没有治理好了。
❌
// shop.js
import 'adminTools' from 'admin'
想要导入 monorepo,本人是蛮举荐 Nx,官网文件写的很分明也搭配一些视频教程。
总结
当然并不是每一个我的项目都适宜应用 monorepo
治理,还是要针对我的项目内容抉择适合的架构,但总体而言若我的项目够宏大、又有不同团队解决不同我的项目,monorepo
就蛮适宜的
代码部署后可能存在的 BUG 没法实时晓得,预先为了解决这些 BUG,花了大量的工夫进行 log 调试,这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文:https://medium.com/hannah-lin…
交换
有幻想,有干货,微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq44924588… 已收录,有一线大厂面试残缺考点、材料以及我的系列文章。