第⼀，我们把构建任务进⾏了⽣命周期化，git cone、npm install、npm build，把这些阶段全部进⾏拆 开，让整个任务流程颗粒化，这样的好处是，我们可以在每⼀个颗粒之间找到优化空间，⽐如是不是可以 不进⾏npm install，⽐如上传制品仓库的逻辑优化等等。
第⼆，可以指定DSL，我们可以实时监听打包排队的情况，在资源调度层⾯做⼀些优化。同时可以做⼀些 埋点进⾏采集数据，给后续进⾏深⼊分析。
第三，我们甚⾄可以在构建、打包过程中，做⼀些交互的相关操作，⽐如，我们打包⼀个 h5 项⽬，需要测试同学来进⾏审核，只有测试审核通过完之后，才进⼊到下⼀流程，下⼀个流程可能是进⾏ UAT 打包、 ⽣产打包等等。
第四，针对项⽬依赖拉取，最开始的时候，我们做的是全量的拉取，我们现在可以优化为增量拉取，这 样，服务器的压⼒会减轻很多
错误治理
不管是在本地还是 cd 平台上进⾏构建，也容易出现各种意想不到的错误。⽐如开发的疏忽，流⽔线的 git commit 未经过验证进⾏提交代码，都可能在 npm run build、或者 npm install 这两个阶段报出不同的 错误，所以就需要对⽇志提示进⾏分级集，划分为两种类型：
warning 类型：没有 package-lock.json 提示，不影响到任务构建；
error 类型：导致 job 任务退出，⽐如依赖包未找到等； 4
我们对 npm install、npm run build，及构建的各个阶段的观察，可以把失败归纳为 4 个触发 warning 或 error 类型：
语法错误：代码冲突...
程序异常：内存溢出…
Install 失败：未找到安装包…
配置错误：构建未按照规范输出…
遵守“观察⽇志-沉淀规则-修正反馈准确率”规则，来沉淀⽇志规则。
npm install 跳过
在复⽤ Workspace 的情况下，已经 install 好的 node_modules，就没必要进⾏⼆次重复 npm install， 就需要考虑只有依赖进⾏变更时，再重新 npm isntall。同时也容易带来问题，node_modules 污染，我 们采取了多种⽅式来避免 node_modules 被污染掉。
cache 定期检查；
切换 node 版本时，执⾏ npm rebuild，重新进⾏编译⼀些需要依赖 gc++ 环境构建的包，如 node- sass；
CD ⻚⾯增加⼿动清理 Workspace 选项；
带来的收益⽬前，我们对⽐以前的 v1.0 ⽅案，整体有了 20%+ 构建速度的提升，这对我们团队来说，也算是⼀个不 ⼩的正向激励，说明我们之前努⼒的⽅向是正确的。
迁移过程在 v1.0 迁移到 v2.0，需要考虑如何进⾏平滑迁移，我们基于以下来进⾏迁移：
1：每个应⽤建⽴独⽴ v2.0 Job 任务，⽅便快速变更及排查问题；
2：⻚⾯上⽀持快速回滚到 v1.0；
3：选择 git commit、node 版本等信息保持不变，⽆感；
好的架构不是设计出来⽽是演进出来。在未来，构建任务可能会越来越多，项⽬也越来越复杂化，我们就 会考虑容器化⽅案，根据实际情况去考虑，容器构建，镜像发布，尽可能的节约资源。
