devops：为了稳定三分钟，请你花这半小时

背景

我有一个朋友搭了一个CICD平台。发布平台后端项目基本秒发，前端工程构建耗时较长，还经常错误终止，被吐槽。针对此情况尝试分析出的常见原因如下：

部分项目缺乏必备lock文件，部分三方依赖版本兼容存在问题，导致重新安装出错
部分同学在构建平台打包期间，误操作执行了安装yarn的流程，导致其它所有打包中的项目崩溃
node版本问题。前端工程先前并未进行严格的node版本限制，导致出现兼容问题。代表性的node-sass，各版本依赖于不同的node版本。node-sass版本对照：github.com/sass/node-s…
滥用包管理器，本地开发使用pnpm，构建平台却又变成了npm或yarn

发布平台环境说明

发布平台——Jenkins
构建执行逻辑——shell脚本，并非pipeline脚本
共享node，为最大化利用包管理工具缓存，加快构建速度故并未提供单独的容器
统一使用了yarn管理

风险分析

1. 缺乏lock文件

缺乏根本的lock文件会导致项目处于裸奔的环境，无任何保障措施。考虑到众多依赖包间相互协作的可靠性，基本此类项目维护时间超过一年，都会出现兼容问题。从而导致开发环境无法启动，构建环境无法打包。影响范围——单个项目

经调研，市面上经常有不少同学版本管理意识较薄弱，团队内又未作严格要求，项目中的lock文件经常直接丢到.gitignore里。这种行为，基本等同于让项目处于裸奔状态，无任何保障。

2. lock文件绝对匹配问题

由于修改依赖包方式不规范，导致即使有lock文件，也出现了依赖匹配问题。继而导致部分情况下存在lock文件，却还要删除重新install才能正常安装的情况。通常出现此类问题，是由于开发者修改依赖包未进通过合法手段修改（eg: 手动修改了package.json的依赖版本号后不重新生成可用lock文件，而是直接提交git）

团队人员关于lock文件作用不了解，习惯性install，未通过严格的 npm ci（yarn install --frozen-lockfile; pnpm install --frozen-lockfile）的方式安装

lock文件说明：blog.csdn.net/xgangzai/ar…

3. CI平台重新安装包管理工具

上文提到，为复用包管理器本地缓存，install与build的流程，并未新启一个容器进行，这就导致若是某个工程的shell中出现了npm install yarn -g的行为，将会导致其他进行中的构建错误中止。

4. node版本切换能力

node作为前端工程的基本环境，其兼容性通常被很多人视为可靠。而这一并不可靠的可靠会经常出现兼容问题。

打包服务器的环境是全局共享，可能会出现 a 项目必备的依赖于node v8.0.0版本，b项目必备的依赖于node v14.1.0版本，此类情况，打包服务器目前未提供node环境隔离方案

5. 滥用包管理器（乱花渐欲迷人眼？？？）

相信大家也曾经见到过这样一个场景：刚拿到一个项目，clone下来发现里面既有npm lock文件，又有yarn lock文件。其危害基本等同于没有lock文件，往往让人不知所措。

优化草案

1. 解决常见的包管理器滥用问题

强制限制同一个项目只能使用一种包管理器。分析node工程的执行流程，不难想到preinstall钩子，在install时机做出判断。碰巧，有现成的开源库only-allow可以实现。在项目package.json中加入如下代码即可。

{
  "scripts": { "preinstall": "npx only-allow yarn" } 
}

2. 解决不能提供多种node版本的缺陷

切换node版本，社区已经有较多的解决方案。典型的如 nvm，nvs，n等等。结合多方考虑，最终选择了nvm的方案，碰巧Jenkins社区也提供了nvm相关插件nvm-wrapper

3. 解决不能提供多种包管理器的缺陷

CI平台力求一统，但难免各个开发人员有各种各样的原因选择了不同的包管理器，有npm，有yarn，nvm切换后无法识别是否兼容。见此情形，思考通过shell解决

uninstalled_module=""
# 判断是否已安装当前命令
command_has() {
  type "$1" > /dev/null 2>&1
}

if test -f $HOME/.nvm/nvm.sh;then
  echo "当前处于nvm环境"

  for i in "yarn" "pnpm"
  do
    if ! command_has $i;then
      if [ "$i" = "ni" ];
        then
          uninstalled_module="$uninstalled_module $i"
      fi
    fi
  done

  if [ ! -z "$uninstalled_module" ];then
    echo "安装如下依赖：$uninstalled_module"
    npm install -g $uninstalled_module
  fi
fi

shell可以实现，但十分不推荐将过多的执行流程放在构建脚本中，构建脚本理应越简单越好。多方查询之下，发现antfu大佬早已默默的实现好了这一切——@antfu/ni。 @antfu/ni可以判断当前项目所使用的包管理工具（留对lock文件），并自动执行后续构建流程，若发现所依赖的包管理工具缺失，也会自动下载，可省去上述繁琐的shell判断。

antfu/ni: github.com/antfu/ni