由 dawei 我们对不同的⼯程项⽬进⾏了模板化，⽐如 PC项⽬、H5 项⽬、游戏项⽬、hybrid 项⽬等等，在模板基 础上，我们⼜封装出来打包流⽔线模板，这样的好处是，我们可以⾃⼰去针对各个类型的⼯程模板做⼀些 定向的配置优化，⽐如说我们的游戏类型项⽬，我们去做⼀个构建、打包，我们就可以在对应的开发组件 库依赖这⼀块，做⼀些对应的缓存、通知、报告等等。
流⽔线同时也带来了⼀些好处：
第⼀，我们把构建任务进⾏了⽣命周期化，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 失败：未找到安装包…
配置错误：构建未按照规范输出…
遵守“观察⽇志-沉淀规则-修正反馈准确率”规则，来沉淀⽇志规则。