构建 job 流#12116;线化带来的是非势

我们对差异的⼯程项⽬进⾏了模板化，⽐如 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 失败：未找到安装包…

设置错误：构建未凭证类型输出…

遵守“调查⽇志-沉淀法则-批改反馈精确率”法则，来沉淀⽇志法则。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!