先来一张照片吧

现在已经快10点钟了。在平安升级生产环境。大多数的人都已经下班了

之前也有很多次的 升级 生产 环境，而且基本每次都 搞到很晚

这次出差来搞平安的神兵系统，一套自动化部署的工具。

内部就是jenkins 的自动化打包之类的，平安的技术还是不错的，里面用到了 k8s 。

回到项目吧

我们的项目是一套springcloud 的项目。包含了多个微服务。生产环境一搞集群，那么多的机器手工部署，真的是要命了

详见 ：https://blog.csdn.net/a897180673/article/details/83280477

其实我一直很期待能够使用上jenkins，但是项目经理说时机不成熟 一直没让用。

后果了？

1.每一次升级都要升级到很晚

2.生产搞集群，一个jar包传到多个机器，如果操作不熟悉，就有可能导致漏传，错传，人不是机器，谁能保证百分百正确？20几台机器，传20几个jar包。重复机械的劳动。有可能因为一个jar 的小失误，导致系统不正常，定位起来很烦。

3.如果遇到某个bug，怎么办，升级之前都要把jar包备份，然后重新运行原来的jar包。这个还好，不是特别烦，稍微麻烦吧

4.每次升级生产都需要准备，生产测试各有一套git仓库，测试的代码的验证ok，需要测试代码合入生产，生产和测试2套代码，需要手动比对代码。 有可能人在合入代码的时候，一不小心就会出错，无法保证生产和测试代码的强一致性。

等等等等，何止这4个问题。

从我给平安部署升级生产环境以来，哪次不是12点左右升级成功的。每次都是一堆事。

落后的升级方式，要命。

这次来平安部署神兵 ，本质上 是一套jenkins+容器部署 ，但是做了很多的封装。因为封装了，很多的细节就看不到了。

所以自己整理个吧。

希望通过这个教程，可以实现自动化的jar 部署，解决上面提到的几个痛点
1.能够jenkins自动 打包，那么部署人员会节省很多的精力和时间，具体的包括：
（1）下载git仓库的源码，打包
（2）将jar包上传到linux服务器
（3）生产发布遇到问题了，直接回退，不需要手动回退代码，重复（1）（2）步骤

2.即使遇到了某些特定的问题，jenkins 可以根据git 的hash值，快速回退，省心

3.生产和测试公用一套git仓库。测试环境测试ok，直接把仓库的源码打包，发布到生产，这样可以保证代码强一致性，对于测试而言，代码强一致性，他的测试压力也小。

4.最关键的是，整个过程全部是自动化完成的，机器永远不可能出错，极大程度的避免了因为部署人员的操作而出现的错误。

5.升级部署快速，这个是大家都想看到的结果，早早的就下班了，谁不向往？

平安的神兵系统已经用到了k8s+docker 了，深感技术 发展太快。学习之路还很漫长。

今天想写下这个系列的文章，打算能够实现使用jenkins 自动的打包发布的功能，深刻践行devops 的路还很长，

先把开发打包部署这个痛点 解决掉吧。

不要停止学习的脚步，加油