看到这个标题，如果你做过CI/CD并且对Monorepo有一定的了解，肯定知道我们面临的困难有多大了。

痛点分析

Monorepo的痛

这个项目有很多子项目，对，是很多，多达几十上百个。

几乎所有的CI/CD对Monorepo的支持都不好，执行一次CI/CD就构建全部的子项目吗？那得花多长时间？开发与QA能接受吗？

目前构建单个子项目大约20秒左右（已进行过webpack优化），构建5个大约1分零10秒。

构建100个至少需要1小时。

而且这么多业务型的子项目，也不太可能单独去管理它们的版本。

这是要做自动化待解决的首要问题！

前后端未完全分离

什么？都2020年了你告诉我前后端还搅在一起玩耍？

是的，公司领导层都是.NET后端出身，所以很多项目都是由后端主导的。

页面上其实没有后端的绘制代码，我们是用的React工程构建的项目，将打包结果拷贝到.NET项目中使用，页面引用打包结果，但是版本控制仍然由后端负责。

同事们一再抱怨流程复杂到令人颤抖：在React项目中开发，提交git，推送，提MR；然后构建，将打包结果拷贝到.NET项目中，再次拉分支提交git，推送，提MR。这个拷贝过程很容易导致.NET项目中的csproj文件同步失败导致.NET项目在构建时找不到资源而炸掉（对于chunk文件必须先删掉的，再移除，再添加新的到项目中去，一旦漏掉某项csproj就同步失败，用过VS的童鞋应该深有体会）。

这种前端页面由后端控制器绘制出来的项目要做资源分离，面临最大的难题是版本管理（也就是缓存复用与穿透）!

你的webpack构建版本处理得再风骚，也会被.NET这个后腿拖得动弹不得。

PS：这不是我的锅，是遗留项目要做重构导致的，这也是我入职以来面临的头疼问题。旧代码视图是用knockout+jquery+.net代码绘制的，重构后是使用React绘制，是独立的项目，但是需要将结果拷贝到遗留项目中运行。

这是要做自动化待解决的第二个难题！

CDN的引入

什么？都2020年了你告诉我还有项目没使用CDN？

是的，公司领导层都是.NET后端出身，不太在意前端资源的处理。

所有的脚本和样式都是项目启动时加载到内存里，通过后端代码去引入访问的。

@Script.Src("/page/a.js",
"/page/b.js");
@Style.Src("/css/a.css",
"/css/b.css");
复制代码

既然要搞自动化布署，前端资源肯定得分离，那么CDN的引入也是自然的了。

解决方案