当公司CI/CD流水线蹦了，你该怎么办？

问题
今日份在对开发环境的项目进行了code push后，点击ci/cd执行工具流。打开今日头条悠闲的刷刷热点新闻，默认静默稍等片刻，部署完成后再验证一下。

理想：完美，没问题，提测，下班，回家。
现实：Failed to install “esbuild-linux-64” using npm：xxxxx

顿时头皮发麻，一个稳定的流水线被我给搞崩了，且是下班时间。
这个时候，兄弟们，是你们的话，你们会怎么办？欢迎评论区指导。

作为一个专业的前端切图仔，遇到这种流水线问题，瞬间绝望。说好的下班的快乐呢…
本身谁的问题谁解决的原则（实则大佬们都下班了），自己只能硬着头皮上了。
思考
当多人协作发生流水线问题的时候：
● 第一步：拉取相应分支代码。本地构建看有无出现与流水线一致的问题
● 第二步：如无问题，这个时候就可以判断是前端包的问题。这个时候就别头铁去找运维，因为不一定是平台的问题。
● 第三步：删除本地 node_modules，本地npm-lock文件。重新执行npm install，再进行产物构建。
● 第四步：复现问题，正常情况都会复现
● 第五步：前端问题排查接受，准备和运维大佬硬钢。这就需要你有很铁的操作系统相关知识，可以指挥运维大佬，不然就只能做好运维大佬的协同小弟，一起排查环境问题。

注意：当发现你的报错包没有的在package.json的依赖列表里面的时候，就去查询lock文件，看对应的包依赖项有无对应的包，和包的安装版本

除了上述的五步法流程以外，也提供一个常规的三步法：
当ci/cd的流水线出了问题时，一般都出在了前端构建脚本。毕竟运维大佬不好得罪，不能说是他的问题。排查三步走：
● 打开前端的构建流水线，查看构建日志
● 打开构建日志，根据前端的构建脚本，忽略一些黄色无关紧要的warning，找寻到那一抹最为亮眼的红色。
● 复制粘贴，有条件的上google，没条件的上百度。
● 散会，解决。

ps：google搜索也要有技巧，想出来是中文的，除了用翻译软件中文式翻译以外，最好带中文关键字。

验证
其实，英文条件比较好的童鞋看到报错信息就大概率知道是什么问题了。因为英文提示得很明显了，这就是为什么大佬英文都很好的原因。

这个问题就是当前的构建系统在预构建的时候，缺少了一个关键的预构建系统包 esbuild/linux-x64。
按照常规5步法，排查到再加载 @esbuild包的时候，缺少前置操作系统依赖包@esbuild/linux-64。

按照google大佬的指示，执行node node_modules/esbuild/install.js node命令就会根据当前操作系统加载相应的前置依赖包。
原理
本着打破砂锅问道底的原则，就打开了 install.js 文件查看命令行执行的步骤，以及到底做了什么事情。
排除掉node脚本的注释，报错warning信息，google一下几个主要核心 node包的使用手册，终于搞清楚了这个命令解决的是什么问题：
● 查询当前执行环境，是否是 shell脚本还是bin命令
● 如果是node 脚本，读取文件并手动添加环境变量，且判断当前操作系统是 linux或者 centerOs。
● 下载对应的预编译前置系统包，并对下载失败的时候增加换源重试操作。
● 写入文件输出到对应目录

完美，解决得彻彻底底。顺带学习了一些node 服务包，node经验+1。
离前端切图仔又远了一步！诶…

总结
经过这次的流水线‘事故’，想‘告诫’前端童鞋们，在这个时候，你遇到问题应该保持着一颗激动的心。
因为每次事故都是你的项目经验，每个问题都是你在前端的苦海中找寻到的落脚点。
面对问题，不给自己设限，跳出自己给自己画的职责圈，不要总以为有公司大牛替你解决。
因为你总有一天也会成为大牛。就算没有成为，那大牛也会有下班的时候…

就像我一样，当大牛下班了，也只有自己扛。
诶，又是搬砖的一天！下班…