问题是什么？
上班第一天，修个了几个bug，本地自测觉的自己处理的很完美，自信的把代码提交了，开始在自动化构建部署后台开始傻瓜点几下，就等部署完成，到测试环境看一下。结果过了一会，去后台看构建结果，发现失败了，这个很常见，可能是超时了，我再试几次，发现都是失败，直觉告诉我，这次应该不是网络超时的原因呢。
此时我想着，去对比下，成功的构建日志和错误的构建日志，看看这之间的差别，到底问题出现在那里呢？ 毕竟过年之前，都是正常的，为啥才过一个年，就成这样呢？而且在代码什么都没有改动的，真的很奇怪。
但是既然有这个问题，肯定是那里出现了问题，那就得解决它，不然构建发布不了，咋给测试呢。慢慢找吧，我分别从下面几个方向查找处理的这个问题。
怀疑是npm包的问题
修改Jenkinsfile的构建，更改的npm包的代理仓库，测试发现无用。
查构建日志
- 看当前构建失败的错误日志，看看报错信息
- 对比之前正常的构建日志和现在错误的构建日志，看看两者的区别
- 确定真正的报错信息是什么
查找下来，只有这个是真正导致构建异常的原因，其他报错正常和失败的日志，都同时存在不影响。 就是这个ip-address@9.0.5这个包，需要node版本大于等于12。但是现在10.xx, 版本不匹配导致。 但是我在项目里面找了，package-lock.json找了一圈都没有发现这个包。
求助运维
由于不常用到，Jenkinsfile和dockerfile这些内容，导致对这些问题很陌生。就去求助了运维大哥。跟运维描述了上述问题，为啥都没有修改Jenkinsfile和dockerfile的配置，为啥会出现这个问题。
运维说就是那个包问题，哎，还得自己看看。刚好借这次机会，学习一点点相关知识，看了一下Jenkinsfile和dockerfile的配置，再搜了一下资料，发现docker里面，启动的时候应用的时候，安装了pm2@4.5.6里面就依赖这个ip-address@9.0.5。而这个包，要求的node版本又需要node12。
对各种构建部署步骤，进行修改尝试
-
Jenkinsfile构建里面的node版本是10，那么我把里面的node环境，修改为12尝试下，测试失败，一构建就报错，node-sass的版本和node不兼容，我又不能修改，项目里面的node-sass, 这个改动挺大，不知道会引起什么问题，放弃这个修改。
-
既然jenkins不行，那就修改dockerfile里面的node版本，反正错误就是docker里面用的node10,跟pm2里面的ip-address不兼容导致的，将docker里面的node修改为12版本。
构建是成功了，但是docker里面启动的时候， 又不成功，看日志又是内存溢出。哎，本来以为构建没问题，发布应该也会成功，成功的道路，总是这么艰辛。还得重新再来。
- Jenkinsfile和dockerfile的配置内容还原，感觉路走远了，需要回过头来，再重新梳理，不能调整docker里面的node版本，因为在Jenkinsfile里面的node版本是10， 整个项目的构建都是以10为基准的，而docker的node又调整为12，两者的版本是有差距的，会导致版本不兼容，出现问题。
最终处理
- 既然node版本不能调整，Jenkinsfile和dockerfile需要保持一致，版本要求为10
- 而docker里面安装的pm2的又需要node12。那么只能调整pm2的版本了，但是pm2@4.xx都用了这么久了，突然降低为pm2@3.xx会不会，有什么问题。
- 管不了那么多了，只能先尝试下。再看看有什么问题，有问题再修改。发上去了构建发布都没有问题。
总结
对Jenkins和docker有了浅浅的认识，在整个的自动化部署平台中，Jenkin是根据项目的package进行包的依赖安装，然后将前端code进行打包编译成静态文件，上传到对应的服务器上，然后在docker中，启动对应的前端node服务。
通过这次问题的排查，发现这部分的知识比较欠缺，需要找个教程学习下。 以前总是觉得这部分不需要前端了解，就每次都忽略掉，但真的用到的时候，却啥都不知道，真的是应证那句话，书到用时，方恨少。难倒你的，往往就是你忽略的。
上述只是自己浅浅理解，肯定存在些许错误，如有错误，恳请指正