网站内容建设的原则是什么样的国内html5网站欣赏

网站内容建设的原则是什么样的,国内html5网站欣赏,google网站增加关键词,江苏最新消息今天阅读本文您将了解到#xff1a;什么是 monorepo、为什么要 monorepo、如何实践 monorepo。 项目管理模式 Monorepo 这个词您可能不是首次听说#xff0c;在当下大型前端项目中基于 monorepo 的解决方案已经深入人心#xff0c;无论是比如 Google、Facebook#xff0c;社区…阅读本文您将了解到什么是 monorepo、为什么要 monorepo、如何实践 monorepo。项目管理模式Monorepo 这个词您可能不是首次听说在当下大型前端项目中基于 monorepo 的解决方案已经深入人心无论是比如 Google、Facebook社区内部知名的开源项目 Babel、Vue-next 还是集团中 rax-components 等等都使用了 monorepo 方案来管理他们的代码。▐发展历程仓库repository简称 repo是我们用来管理项目代码的一个基本单元。通常每个仓库负责一个模块或包的编码、构建、测试和发布代码规模相对较小逻辑聚合业务场景也比较收拢。当我们在一整块业务域下进行研发时代码的解耦和复用是一个非常重要的问题。初期业务系统不复杂时通常只用一个仓库来管理项目项目为单体应用架构 Monolithic。这时我们会以合理划分目录提取公共组件的方式来解决问题。由文件的层级划分和引入来进行页面、组件和工具方法等的管理。此时其整个依赖和工作流都是统一的、单向的。当业务复杂度的提升项目的复杂性增长由此就会导致一系列的问题比如项目编译速度变慢调试成本变大、部署效率/频率低非业务开发耗时增加、单场景下加载内容冗余等等技术债务会越积越多。同时又有了代码共享的需求此时就需要按照业务和模块来拆分。那么组件化开发是一个不错的选择。这样每个仓库都能独立进行各模块的编码、测试和发版又能实现多项目共享代码研发效率提升也很明显特别是调 UI 样式的时候。同时在团队规模变大人员分工开始明确拆分的好处还带来不同开发人员关注点可按照域来分散研发队员只需关心自己模块所在的仓库对各自核心的业务场景关注思考更加集中和收拢。这种管理模式我们称之为多仓多模块管理 MultirepoPolyrepo也是一个意思。再随着时间的沉淀模块数量也在飞速增长。Multirepo 这种方式虽然从业务逻辑上解耦了但也同时增加了项目的工程管理难度。组件化的前期可以忽略不计当模块量到达一定体量程度下这个问题会逐渐明显。比如代码和配置很难共享每个仓库都需要做一些重复的工程化能力配置如 eslint/test/ci 等且无法统一维护当有工程上的升级时没能同步更新到所有涉及模块就会一直存在一个过渡态的情况对工程的不断优化非常不利。依赖的治理复杂模块越来越多涉及多模块同时改动的可能性急剧增加。如何保障底层组件升级后其引用到的组件也能同步更新到位。这点很难做到如果没及时升级各工程的依赖版本不一致往往会引发一些意想不到的问题。存储和构建消耗增加假如多个工程依赖 pkg-a那么每个工程下 node_modules 都会重复安装 pkg-a对本地磁盘内存和本地启动都是个很大的挑战增加了开发时调试的困难。而且每个模块的发布都是相对独立的当一次迭代修改较多模块时总体发布时效就是每个发布流程的串联。对发布者来说是一个非常大的负担。有没有一种更好的管理模式既能享受到 组件化多包管理 的收益又能降轻工程复杂度引起的影响呢这时就提出了单仓多模块管理 Monorepo 的概念。Monorepo 其实不是一个新的概念在软件工程领域它已经有着十多年的历史了。它是相对于 Multirepo 而言的一种模式概念上非常好理解就是把多个项目放在一个仓库里面。用统一的本地关联、构建、发布流程来消费业务域下所有管理的组件模块。▐单体应用架构 Monolithic项目初期起步阶段团队规模很小此时适合「单体应用」一个代码仓库承接一个应用管理成本低最简力度支撑业务快速落地。此时目录架构大概长这样project ├── node_modules/ │ ├── lib1.0.0 ├── src/ │ ├── compA │ ├── compB │ └── compC └── package.json优点代码管理成本低代码能见度高无需额外的学习成本发布简单链路轻便缺点代码量大了后调试、构建效率显著下降无法跨项目复用▐多仓多模块管理 Multirepo团队规模变大人员分工明确单体应用的缺点会愈发突出此时 「Multirepo」就更适合。模块分工更明确可拓展可复用性更强调试构建发布能力也有一定提升。此时目录架构大概长这样project ├── node_modules/ │ ├── lib1.0.0 │ ├── lib2.0.0 │ ├── pkgA │ ├── pkgB │ └── .. ├── src/ └── package.json packageA ├── node_modules/ │ └── lib1.0.0 ├── src/ └── package.json packageB ├── node_modules/ │ └── lib2.0.0 ├── src/ └── package.json优点便于代码复用模块组件独立开发调试业务理解清晰度高人员编排分工更加明确提高研发人员的公共抽取思维能力源代码访问权限设置灵活缺点模块划分力度不容易把握共同引用的版本问题容易导致重复安装相同依赖的多个版本构建配置不复用不好管理串行构建修改模块体量大时发布成本急剧上升Code Review、Merge Request 从各自模块仓库执行比较分散▐单仓多模块管理 Monorepo随着组件/模块越来越多 multirepo 维护成本越来越大于是我们意识到我们的方案是时候改进了。此时目录架构大概长这样project ├── node_modules/ │ ├── lib2.0.0 │ ├── pkgA │ ├── pkgB │ └── .. ├── src/ └── package.json mono-project ├── node_modules/ │ └── lib2.0.0 ├── packages/ │ ├── packageA │ │ └── package.json │ └── packageB │ └── package.json └── package.json优点所有源码在一个仓库内分支管理与单体应用一样简单公共依赖显示更清晰更方便统一公共模块版本统一的配置方案统一的构建策略并行构建执行效率提升保留 multirepo 的主要优势代码复用模块独立管理分工明确业务场景独立代码耦合度降低项目引入时除去非必要组件代码CR、MR 由一个仓库发布阅读和处理十分方便缺点git 服务根据目录进行访问权限划分仓库内全部代码开发给所有开发成员这种非特殊限制场景不用考虑当代码规模大到一定程度时git 的操作速度达到瓶颈影响 git 操作体验中小型规模不用考虑而且就算是 def 平台可并行量也为 500▐优缺点对比梳理场景multirepomonorepo项目代码维护❌ 多个仓库需要分别download各自的node_modules像这种上百个包的多少内存都不够用✅ 代码都只一个仓库中相同依赖无需多分磁盘内存。代码可见性❌ 包管理按照各自owner划分当出现问题时需要到依赖包中进行判断并解决✅ 对需要代码隔离的情况友好研发者只关注自己核心管理模块本身✅ 每个人可以方便地阅读到其他人的代码这个横向可以为团队带来更好的协作和跨团队贡献不同开发者容易关注到代码问题本身❌ 但同时也会容易产生非owner管理者的改动风险❌ 不好进行代码可视隔离代码一致性❌ 需要收口eslint等配置包到统一的npm包再到各自项目引用这就允许每个包还能手动调整配置文件✅ 当您将所有代码库放在一个地方时执行代码质量标准和统一风格会更容易。代码提交❌ 底层组件升级需要通知到所有项目依赖的相关方并进行回归❌ 每个包的修改需要分别提交✅ API 或共享库中的重大更改能够立即公开迫使不同的开发者需要提前沟通并联合起来。每个人都必须跟上变化。✅ 提交使大规模重构更容易。开发人员可以在一次提交中更新多个包或项目。唯一来源❌ 子包引用的相同依赖的不同版本的包✅ 每个依赖项的一个版本意味着没有版本冲突也没有依赖地狱。开发✅ 仓库体积小模块划分清晰。❌ 多仓库来回切换编辑器及命令行项目一多真的得晕。如果仓库之间存在依赖还得各种 npm link。✅ 只需在一个仓库中开发编码会相当方便。✅ 代码复用高方便进行代码重构。❌ 项目如果变的很庞大那么 git clone、安装依赖、构建都会是一件耗时的事情。工程配置❌ 各个团队可能各自有一套标准新建一个仓库又得重新配置一遍工程及 CI / CD 等内容。✅ 工程统一标准化依赖管理❌ 依赖重复安装多个依赖可能在多个仓库中存在不同的版本npm link 时不同项目的依赖可能会存在冲突问题。✅ 共同依赖可以提取至 root版本控制更加容易依赖管理会变的方便。代码管理✅ 各个团队可以控制代码权限也几乎不会有项目太大的问题。❌ 代码全在一个仓库如果项目一大几个 G 的话用 Git 管理可能会存在问题。❌ 代码权限如果需要设置暂时不支持部署这部分两者其实都存在问题❌ multi repo 的话如果各个包之间不存在依赖关系倒没事一旦存在依赖关系的话开发者就需要在不同的仓库按照依赖先后顺序去修改版本及进行部署。❌ 而对于 mono repo 来说有工具链支持的话部署会很方便但是没有工具链的话存在的问题一样蛋疼。社区推荐pnpm、lerna持续集成❌ 每个repo需要定制统一的构建部署过程然后再各自执行✅ 可以为 repo 中的每个项目使用相同的CI/CD部署过程。✅ 同时未来可以实现更自动化的部署方式一次命令完成所有的部署总体来说当业务发展到一定规模时monorepo 的升级相比 multirepo 来说是利远大于弊的。Monorepo 使用 or not▐业务现状天猫校园如意pos业务域场景丰富整体的代码逻辑比较复杂因此采取按照 app项目入口-bundle业务域板块可以理解为页面-component/util通用组件base组件、biz组件、utils和sdk平铺都属于这个 的形式进行整个项目的管理。目前项目所涉及的 npm 业务模块数量已经超过了 100 个。▐存在的制约应用规模增长构建依赖本地环境构建效率低下非业务投入成本不断上升主应用需要频繁构建构建前依赖的模块需要单独构建构建速度串行组件还在不断增长愈加不利于工程的维护组件类发布没有对接集团规范无CR卡点二级依赖凌乱代码 review 全靠 人工 diff 进行 cr每次的版本信息都是通过手动维护组件依赖的二级依赖不统一package-conflict 非常多▐优化目标构建部署发布提效全链路CR及需求管控全代码卡点管控后续代码质量单测节点补充等等降低构建部署成本对于一次合理的多包改动只需要进行1~2次的构建即可完成部署任务降低每次迭代的应用发布的维护成本对于一个应用及其包含的子应用包括集成包和微应用模式一次完整的研发流程只需要维护一个发布迭代。发布依赖关系通过自动化流程进行优化。对于主子应用/组件可以进行合理的CR管控每个有变更的子应用都可以关联到对应的aone需求可多个。能将整个研发和发布流程统一到一个平台上进行操作降低理解和操作成本。更进一步的优化将原来割裂的一些流程节点进行整合以及版本迭代修改日志的统一维护。在流程节点上可以提供扩展方式预留后续类似代码扫码质量评估灰度管控等体系。▐选用结论综上所述不管是当应用规模发展到一定规模下普遍遇到的情况还是历史包袱如意pos现在已经是一个超级复杂的应用。以上的问题所带来的制约只会愈加凸显。在这个大背景下这个阶段为了解决上面的问题使用 monorepo 进行项目管理升级是非常有价值的。▐落地结果落地过程参考后面的「最佳实践」打包开发发布架构升级前单组件打包时间7090s迭代 n 个包需要 *n 的时间单个包启动开发需要60s同时开发多个包会拖慢速度进入打包发布流程会打断开发脱轨线上发布平台CR/测试无卡点脱离管控架构升级后并行构建打包 n 个包只需要90s本地开发不会被打断节省重启时间云平台构建模式接入 CR 卡点进一步提高质量稳定性提效总结组件打包成本降低90%启动成本降低100%发版提效80%本地构建转云构建Monorepo 生态Monorepo 只是一个管理概念实际上它并不代表某项具体的技术更不是所谓的框架。开发人员需要根据不同场景、不同的研发习惯使用相应的技术手段或者工具来达到或者完善它的整个流程从而达到更好的开发和管理体验。目前前端领域的 Monorepo 生态有一个很显著的特点就是只有库而没有大一统的框架或者完整的构建系统来支持。目前的工具形态上像是传统的 CMake 那样的辅助工具而不是像 Gradle构建语言 生态链或 Cargo包管理器自身集成 那样统一的方式。可能未来的趋势是像 nx 或者 turborepo 这样的库要往完整的框架发展或者包管理器自身就逐步支持相应的功能不需要过多的三方依赖。以下介绍一下生态中的一些核心技术▐包管理方案Npmnpm 在 v7 才支持了 workspaces属于终于能用上了但是并不好用的情况重点是比较慢通常无法兼容存量的 monorepo 应用出来的时间太晚了不能像 yarn 支持自定义 nohoist 以应对某些依赖被 hoist 到 monorepo root 导致的问题也没有做到像 pnpm 以 link 的方式共享依赖能显著的减少磁盘占用除了 npm 自带之外没有其他优点。Yarnyarn 1.x最早支持 workspaces 模式的包管理器配合 lerna 占据了大部分 monorepo在比较长的一段时间里是 monorepo 的事实标准缺点是 yarn 的共享包才会提升到 root node_modules 下其他非共享库都会每个地方留一份占用空间比较多还有提升到 root 这一行为也会带来兼容性问题有些包的 require 方式比较 hackyarn berry(2 ~ 3)比较新的点就是 pnp 模式pnp 模式是为了解决 node_modules 臃肿、复杂度过高的问题而来的但是比较激进所以很难支持现有的项目。不过 yarn 3 基本上把各个包管理的功能都支持了nodeLinker 配置从功能上可以算是最多比较复杂概念好多。吸收了部分竞争对手的优点并开辟了许多有趣的功能特性。Pnpm全称是 “Performant NPM”即高性能的 npm。如它在官方文档介绍的所说“Saving disk space and boosting installation speed”Pnpm 是一个能够提高安装速度、节省磁盘空间的包管理工具并天然支持 Monorepo 的解决方案。除此之外它也解决了很多令人诟病的问题其中比较经典的就是 Phantom dependencies幻影依赖。pnpm 的优势安装依赖速度快软/硬链接结合安装过的依赖缓存全局复用缓存逻辑基于文件块不同版本的依赖可以只缓存 diff自身支持 workspaces 相关推荐导读pnpm官网https://pnpm.io/zh/▐包版本方案LernaLerna 是一个管理工具用于管理包含多个软件包package的 JavaScript 项目。它可以优化使用 git 和 npm 管理多包存储库的工作流程。Lerna 主流应用在处理版本、构建工作流以及发布包等方面都比较优秀既兼顾版本管理还支持全量发布和单独发布等功能。在前端领域它是最早出现也是相当长一段时间 monorepo 方案的事实标准具有统治地位很多后来的工具的概念或者 workspaces 结构都借鉴了 lerna是 lerna 的延续。在业界实践中比较多的时间上都是采用 Yarn 配合 lerna 组合完整的实现了 Monorepo 中项目的包管理、更新到发布的全流程。后来停更了相当长一段时间至今还是不支持 pnpm 的 workspacespnpm 下有 workspace:protocollerna 并没有支持与 yarn 强绑定。最近由 nx 的开发公司 nrwl 接手维护不过新增的 features 都是围绕 nx 而加nrwl 目前似乎还并没有其他方向的 bug fix 或者新增 features 的计划。不过社区也出现了 lerna-lite 可以作为 lerna 长久停滞的补充和替代主要的新 features 就是支持在 pnpm workspaces。推荐导读lernahttps://www.lernajs.cn/lerna-litehttps://github.com/ghiscoding/lerna-liteChangesetsChangesets 是一个用于 Monorepo 项目下版本以及 Changelog 文件管理的工具。在 Changesets 的工作流会将开发者分为两类人一类是项目的维护者还有一类为项目的开发者开发者在Monorepo项目下进行开发开发完成后给对应的子项目添加一个changeset文件。项目的维护者后面会通过changeset来消耗掉这些文件并自动修改掉对应包的版本以及生成CHANGELOG文件最后将对应的包发布出去。▐包构建方案Turborepo上述提到传统的 Monorepo 解决方案中项目构建时如果基于多个应用程序存在依赖构建耗时是非常可怕的。Turborepo 的出现正是解决 Monorepo 慢的问题。Turborepo 是一个用于 JavaScript 和 TypeScript 代码库的高性能构建系统。通过增量构建、智能远程缓存和优化的任务调度Turborepo 可以将构建速度提高 85% 或更多使各种规模的团队都能够维护一个快速有效的构建系统该系统可以随着代码库和团队的成长而扩展。推荐导读https://vercel.com/blog/vercel-acquires-turborepoNx定位上是 Smart, Fast and Extensible build system出现得比较早发展了挺久功能特别多基本上 cover 了各种应用场景文档也比较详细是现在几个 Monorepo 工具里比较接近完整的解决方案和框架的。最近的话他们也接手了 lerna 的维护不过给 lerna 加的东西都是围绕 nx 而来。推荐导读https://nx.dev/▐其它****生态工具Bolt和 lerna 类似更像是一个 Task Runner用于执行 workspaces 下的各种 script用法上和 npm 的 workspaces 类似已经停更一段时间。PreconstructMonorepo 下统一的 Dev/Build 工具。亮点是 dev 模式使用了执行时的 require hook直接引用源文件在运行时执行转译babel不需要在开发时 watch 产物实时构建调试很方便。用法上比较像 parcel、microbundle 那样 zero-config bundler使用统一的 package.json 字段来指定输出产物缺点是比较死板整个项目的配置都得按照这种配置方式支持的选项目前还不多不够灵活。Rushstack体感上比较像 Lerna Turborepo 各种东西的工具链比较老牌但是没用过也很少见到有用这个的。LageMicrosoft 出的定位上是一个Task Runner in JS Monorepos亮点是 pipeline 的任务模式构建产物缓存远程缓存等。Monorepo 工具链选用最终我们选用了 pnpm lerna-lite turborepo▐Pnpmpnpm 的依赖全局缓存global store and hard link与安装方式即是天然的依赖共享相同版本的依赖只会安装一次有效地节约空间以及节省安装时间在 monorepo 场景下十分切合。▐Lerna-litepnpm 推荐的方案其实是 changesets但是 changesets 的发版流程更贴近 Github Action Workflow以及 打 changeset 然后 version 的概念和流程相对 lerna 会复杂一些。不直接使用 lerna 的原因是 lerna 并不支持 pnpm 的 workspace protocol 。同时 lerna 比较久没有更新虽然最近被 nx 的组织 nrwl 接管了但是 nrwl 只扩展了针对 nx lerna 场景的功能并没有对 lerna 的其他功能进行维护所以社区里出现了 lerna-lite真正意义上的延续了 lerna 的发展目前比较有用的新功能是其 publish 命令支持了 pnpm 的 workspace protocol (workspace:)支持了 pnpm workspace 下 lerna 的发布流程。▐Turborepo如果有高速构建缓存需求则使用 turborepo。Turborepo 的基本原则是从不重新计算以前完成的工作Turborepo 会记住你构建的内容并跳过已经计算过的内容把每次构建的产物与日志缓存起来下次构建时只有文件发生变动的部分才会重新构建没有变动的直接命中缓存并重现日志。在多次构建开发时这也就意味更少的构建耗时。天猫校园 Monorepo 最佳实践▐前置准备使用 pnpm 作为包管理器全局安装 pnpm命令如下$ tnpm i -g pnpm▐创建 mono 仓库初始化该仓库为 mono 仓库# 初始化成功 $ tree ./your-mono-project your-mono-project ├── packages │ ├── bundles │ │ └── bundle-a │ │ └── package.json │ └── components │ └── util-a │ └── package.json ├── .gitignore ├── .npmrc ├── abc.json ├── lerna.json ├── package.json ├── pnpm-workspace.yaml ├── README.md └── turbo.json项目结构介绍packages/..monorepo 各个 workspaces 的目录abc.json云构建 builder 配置与 def 平台相关联lerna.jsonlerna 配置管理多个包的发布版本变更日志生成的工具package.jsonmonorepo 主目录 package 文件pnpm-lock.yaml,pnpm-workspace.yamlpnpm lockfile执行 pnpm i 后生成pnpm workspace 声明文件turbo.jsonTurborepo 配置主要用于产物缓存构建加速构建流配置。Turborepo 地址https://turborepo.org/▐基础 mono 配置设置这里是使用 def 云构建 builder 配置默认是 ali/builder-xpos{ builder: ali/builder-xpos }lerna 的配置包括 packages 的范围publishversion 的命令配置还有指定 npmClient 为 pnpm这里需要使用lerna-lite/cli{ packages: [ packages/*/* ], command: { publish: { conventionalCommits: true, }, version: { conventionalCommits: true, syncWorkspaceLock: true } }, version: independent, npmClient: pnpm }配置简要说明packages指定组件包所在文件夹限定了packages的管理范围。我们这里调整为「packages/*/*」。需要配置为二级目录。因为我们按照类型区分各种包然后相同类型的收纳到该类型的目录下方便研发人员阅读和理解可以看到初始创建后packages目录下有二级目录 bundles 和 componentsversion配置组件包版本号管理方式默认是版本号。我们这里调整为「independent」。注意 lerna 默认使用的是集中版本所有的package共用一个version如果需要packages下不同的模块 使用不同的版本号需要配置Independent模式commandcommand主要是配置各种lerna指令的参数这些命令可以通过命令行配置也可以在配置文件中配更多配置参考https://github.com/lerna/lerna#lernajsonpnpm-workspace.yaml 的配置packages: - packages/*/*同lerna配置说明turborepo 主要用于产物缓存构建加速{ $schema: https://turborepo.org/schema.json, pipeline: { build: { dependsOn: [^build], inputs: [ src/**/* ], outputs: [ es/**, lib/**, build/** ] } } }▐入驻组件选择需要入驻的组件判断该组件属于哪个mono分类如 bundles、components 等切换到相应的分类目录如 /packages/components入驻组件代码到该目录下通过手动复制代码或者 git clone 方式都可以清除入驻组件的 .git在其目录 /packages/components/your-component 下执行rm -rf .git只保留 mono 的 git 管理能力即可重点注意如果没有清除则无法被mono的gitdiff检测到增加/替换 入驻组件中 package.json 中 build script 为 gulp build“build”: “gulp build”注意同时请保证 组件的构建使用的是相同版本的 gulp如如意pos统一使用的是 gulp4在 mono目录下或者 /packages/components/your-component 目录下或者mono中任意位置都可执行 pnpm i执行成功后pnpm-lock.yaml 文件有对应的更新即入驻成功不需要特别关注相互依赖问题入驻之后 pnpm 将会自动识别本地的 package 变动仔细查看 pnpm-lock.yaml 中本仓库依赖的组件的版本号会变成 link: …/xxx▐本地开发关联入驻好组件后就可以尽情地开发编码了。正常情况下组件通过 npm linktnpm link、pnpm link 相似方式进行本地开发关联。组件体量大时这样就非常的麻烦因此我们升级了本地关联的方式通过webpack alias 方式将应用的依赖路径与本地mono仓库中的组件进行替换然后通过选择的方式实现关联。操作步骤应用中配置依赖的mono组件库构建器中实现module.exports { monorepo: xpos-ruyi-mono }启动本地构建$ def dev --mono选择需要关联的本地 mono 组件构建器CLI自行实现即可启动完成就可以开心编码了不再需要进行手动 link 的操作核心代码简要如下// relateLocalMonoLinks.js module.exports async function relateLocalMonoLinks(def) { try { const localLinks await getAppDepsLocalMainJsPath() // 获取app中的依赖项获取本地mono中的组件匹配存在的组件并将包名映射为本地组件入口文件的路径 const cacheLinks await getCacheLinks() // 获取缓存过的关联中的本地依赖 const chosenLinks await getChosenLinks(localLinks, cacheLinks) // 用户自行选择需要关联的本地依赖 await updateChosenLinks(chosenLinks) // 编写 local-links.js 依赖文件供 webpack 构建时 alias 使用 } catch (e) {} }// webpack.config.js const baseConfig { resolve: { alias: getAliasMap() } } // lib/util.js function getAliasMap() { let aliasMap { : path.resolve(cwd, ./src) } const pjson require(path.resolve(cwd, package.json)) Object.keys(pjson.dependencies || {}) .map(packageName { return { key: packageName, value: path.resolve(cwd, node_modules, packageName) } }) .forEach(({ key, value }) (aliasMap[key] value)) const isLocalDev process.env.IS_LOCAL_DEV if (isLocalDev) { try { let links require(path.resolve(cwd, local-links)) || {} aliasMap Object.assign({}, aliasMap, links) } catch (e) { console.log(invalid local links) } } return aliasMap }▐构建 发布组件如果有引入新的依赖请先执行 pnpm i开发完成后正常在 mono 仓库下进行 git 提交通过上述工具链实现的构建器进行发布发布成功后会根据代码提交进行增量改动判断产出对应改动的组件升级包将相应的包的版本号配置到应用的项目中使用即可结语本文分析的是我们在面对天猫校园业务-如意pos这样一个复杂应用场景下的一些项目管理模式的思考探索和落地实践monorepo 本质上不是一种框架而是面对一个项目发展阶段寻求满足当下最适合自己的方案的一个解决思路策略。在探索的过程中我们可以感悟到选方案并不是为了追逐「潮流」而是追逐「收益」。在不同情景下各种方案的思想并不是完全相对独立的相互结合往往会发挥奇效。团队介绍我们是天猫校园前端团队天猫校园业务旨在整合阿里巴巴生态业务赋能校园协助高校商业、服务、后勤数字化升级打造购物、学习、生活、实践为一体的校园生活新方式。业务技术形态包含线上阵地和线下阵地线上有天猫校园官旗小程序、互动h5项目线下有门店零售POS、商业化投放、共享业务等业务多种多样有挑战有机会欢迎您的加入。✿拓展阅读2025开年AI技术打得火热正在改变前端人的职业命运阿里云核心业务全部接入Agent体系字节跳动30%前端岗位要求大模型开发能力腾讯、京东、百度开放招聘技术岗80%与AI相关……大模型正在重构技术开发范式传统CRUD开发模式正在被AI原生应用取代最残忍的是业务面临转型领导要求用RAG优化知识库检索你不会带AI团队微调大模型要准备多少数据你不懂想转型大模型应用开发工程师等相关岗没项目实操经验……这不是技术焦虑而是职业生存危机曾经React、Vue等热门的开发框架已不再是就业的金钥匙。如果认为会调用API就是懂大模型、能进行二次开发那就大错特错了。制造、医疗、金融等各行业都在加速AI应用落地未来企业更看重能用AI大模型技术重构业务流的技术人。如今技术圈降薪裁员频频爆发传统岗位大批缩水相反AI相关技术岗疯狂扩招薪资逆势上涨150%大厂老板们甚至开出70-100W年薪挖掘AI大模型人才不出1年 “有AI项目开发经验”或将成为前端人投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘大模型目前在人工智能领域可以说正处于一种“炙手可热”的状态吸引了很多人的关注和兴趣也有很多新人小白想要学习入门大模型那么如何入门大模型呢下面给大家分享一份2025最新版的大模型学习路线帮助新人小白更系统、更快速的学习大模型2025最新版CSDN大礼包《AGI大模型学习资源包》免费分享**一、2025最新大模型学习路线一个明确的学习路线可以帮助新人了解从哪里开始按照什么顺序学习以及需要掌握哪些知识点。大模型领域涉及的知识点非常广泛没有明确的学习路线可能会导致新人感到迷茫不知道应该专注于哪些内容。我们把学习路线分成L1到L4四个阶段一步步带你从入门到进阶从理论到实战。L1级别:AI大模型时代的华丽登场L1阶段我们会去了解大模型的基础知识以及大模型在各个行业的应用和分析学习理解大模型的核心原理关键技术以及大模型应用场景通过理论原理结合多个项目实战从提示工程基础到提示工程进阶掌握Prompt提示工程。L2级别AI大模型RAG应用开发工程L2阶段是我们的AI大模型RAG应用开发工程我们会去学习RAG检索增强生成包括Naive RAG、Advanced-RAG以及RAG性能评估还有GraphRAG在内的多个RAG热门项目的分析。L3级别大模型Agent应用架构进阶实践L3阶段大模型Agent应用架构进阶实现我们会去学习LangChain、 LIamaIndex框架也会学习到AutoGPT、 MetaGPT等多Agent系统打造我们自己的Agent智能体同时还可以学习到包括Coze、Dify在内的可视化工具的使用。L4级别大模型微调与私有化部署L4阶段大模型的微调和私有化部署我们会更加深入的探讨Transformer架构学习大模型的微调技术利用DeepSpeed、Lamam Factory等工具快速进行模型微调并通过Ollama、vLLM等推理部署框架实现模型的快速部署。整个大模型学习路线L1主要是对大模型的理论基础、生态以及提示词他的一个学习掌握而L3 L4更多的是通过项目实战来掌握大模型的应用开发针对以上大模型的学习路线我们也整理了对应的学习视频教程和配套的学习资料。二、大模型经典PDF书籍书籍和学习文档资料是学习大模型过程中必不可少的我们精选了一系列深入探讨大模型技术的书籍和学习文档它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。书籍含电子版PDF三、大模型视频教程对于很多自学或者没有基础的同学来说书籍这些纯文字类的学习教材会觉得比较晦涩难以理解因此我们提供了丰富的大模型视频教程以动态、形象的方式展示技术概念帮助你更快、更轻松地掌握核心知识。四、大模型项目实战学以致用当你的理论知识积累到一定程度就需要通过项目实战在实际操作中检验和巩固你所学到的知识同时为你找工作和职业发展打下坚实的基础。五、大模型面试题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我们将提供精心整理的大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。因篇幅有限仅展示部分资料需要点击下方链接即可前往获取2025最新版CSDN大礼包《AGI大模型学习资源包》免费分享