一次有趣的部署经验

, ,

作为前端er，很少有机会能参与公司的部署流程。偶尔参加的几次部署也只能得到片面的经验，那就有一个记一个吧。部署流程是否丝滑，除了需要熟悉部署中各个工具的用法同时也和运维团队构建部署流程的严谨程度息息相关。比如说我这次就踩到一些坑。

  1. .npmrc配置项相关
.npmrc
1
2
3
4
strict-ssl=false
registry='网址'
timeout=100000
engine-strict=true

engine-strict=true 我的package.json文件中配置的engine是14.20.0，而在dockerfile里引用的公司定制化node版本，node版本号是14.21.0,这样就导致两处版本号不一致，部署失败。

错误日志
1
2
npm [0m[91mERR! notsup Required: {"node":"v14.20.0"}
npm ERR! notsup Actual:   {"npm":"8.19.2","node":"v14.20.1"}

另外与之相关的还有另一个坑，一般公司定制化的node镜像里打包的npm版本是6,这样做的好处是兼容低版本的peerDepandency。但是在我的项目里某些包依赖npm 8以上的版本，所以我需要在docker容器中手动下载一个新版本的npm。

配置公司内部的镜像源registry=<website>

设置超时时间，我经常碰到网络问题导致装包失败，timeout=100000即使配置了超时时间也可能会超时出错，到时候按照公司的规则触发重新打包就好了。

Dockerfile
1
2
WORKDIR /usr/src/app
RUN npm install npm@8.19.2 -g

这样做可能是有副作用的，我在Jenkins的部署日志里有看到我的docker cache从这一处（step）开始丢失。

  1. COPY . .

我发现很多别的项目，dockerfile里都执行了这一行，有些项目这个文件里还不止执行一次。这一行的意思是把容器里所有文件拷贝到当前目录，按道理执行一次即可。

  1. github branch命名

branch的命名规则和jenkins上设置的部署参数强相关，一般来说代码合并到develop、master、release这三个分支会触发项目自动部署，运维同学可能会给一些其他命名通配符，比如说:hotfix/fix/feature等，github上的分支如果刚好命中了这几个规则，也会触发Jenkins打包镜像，镜像不会直接同步并部署。

  1. npm script和package.json里面的script保持一致
  2. 排除错误的时候可以暂时注释掉一些不影响打包流程的文件，比如说字体文件。

这里是总结，公司的部署文件可能不止dockerfile，这里建议把整个部署流程挪动dockerfile里来做，这样你在本地也可以通过dockerfile部署，来模拟线上的部署流程。其他更多细节还需要多了解运维相关的知识。