写在前面的话
Jenkins 对于我们用户而言，可能中间会有不同的需求，比如自动构建，接口测试，代码质量检测。但其实我们的最终目的还是打包上线。当然，各个公司的项目开发语言会不一样，但是总体而言发布方式是几乎一致的，不管不是前端还是后端。
插件：Publish Over SSH
简单说下该插件的作用：该插件能耐允许我们向配置好密钥验证的服务器发送文件，并且在远程 Shell 的情况下执行命令。
这就相当于该插件同时具有 scp 和 ssh 的功能。我们可以去插件中心搜索：
插件安装完成以后，打开：系统管理 --> 系统设置
会多出 Publish over ssh 的选项：
此时我们点击新增，就可以增加服务器认证，比如我们新增一台测试：
打开我们的任务，增加发送和包的操作，在 构建后操作 中有这样一项：
配置说明：
此时我们点击触发构建：
在构建的控制台输出的最后，我们可以看到 ssh 操作，同时也可以发现，在 ssh 之后，使用 ls -h . 命令的时候，我们的目录是当前用户的家目录。
而使用 ip 命令的时候却发现未找到命令，这就是在这里使用命令的一个值得注意的地方。
建议命令都写绝对路径，如 /usr/sbin/ip，否则可能出现找不到命令的情况。
在执行 shell 脚本的时候，也建议在脚本前面添加 /bin/sh。
连接服务器查看发送情况：
可以看到文件成功发送到了远程服务器。
关于后续更新
在将更新包发送到远程服务器以后，接下来的操作便是更新，这里就不给具体的脚本了，只给一些自己在使用过程中的以及设计的建议：
假如在远程服务器上面存在 Tomcat 应用服务地址：/data/service/tomcat-8080
1. 我们在设计目录结构的时候，建议设计三个目录：
| 目录 | 作用 |
|---|---|
| /data/service/tomcat-8080 | 应用目录 |
| /data/deploy/tomcat-8080 | 更新包传输临时存放目录 |
| /data/backup/tomcat-8080 | 旧版包归档目录 |
2. 更新过程大致如下：
发送更新包到临时目录 --> 解压更新包到指定的名称 --> 停止应用服务 --> 备份旧版包到备份目录 --> 解压的新版包移动到应用目录 --> 启动服务 --> 发送更新信息
简单说明：
发送更新包到临时目录：就是之前我们使用的 Publish Over SSH 发送文件。
后续的步骤都是在 Publish Over SSH 中执行命令时候执行远程服务器上面的脚本实现，该脚本的功能包括解压包，停服务，备份，更新，启动，发送通知。
对于发送通知，我们这里依然采用钉钉机器人 webhook 的方式：
对于通知消息，建议设置两个机器人，一个用于通知成功，一个用于通知失败以及失败原因。
这样是为了当项目多了起来，一次可能得更新多个项目，为了更好的就行区分通知类型。
3. 规范化管理服务器。
我们在设计服务器的时候就要求服务器设计目录的一致性，这样能够减少我们很多不必要的操作，比如我第一条中的目录结构设计。这样的好处在于，我当前公司的发布脚本一共只有 4 个，这还是为了维护方便的情况分成的 4 个：
一个是传统 NG 代理的前端静态发布脚本，一个是 nodejs 启动的前端服务发布脚本。
一个是传统 Tomcat 服务更新发布脚本，一个是 Springboot 微服务启动发布脚本。
这其中又涉及多项服务，但是脚本至始至终就这几个，每个构建我们通过传递两到三个不同参数用于区分不同项目。
因为目录结构，设计都类似，所以参数也非常简单。
4. 脚本集中管理。
当我们又很多机器的时候，我们不能将脚本存储在服务器本地。否则我们修改脚本就意味着需要修改每台机器上面的脚本，这样工程量很大。我的建议是在发布传输更新包之前多一步操作，就是传输更新脚本。这样能够时刻保持脚本是最新状态。且脚本都在 Jenkins 服务器上面保存，集中管理。
5. 关于回滚操作。
对于回滚操作，由于我们每次都有对服务包做备份，并将备份按照指定 tag 进行了归档，所以我们依然可以采用脚本的形式，将旧版本从新从备份目录更新到应用目录下面。并且我们可以通过指定 tag 传参的形式回滚到指定版本。
小结
整个发布流程大致如此，当然我们可能在很多地方看到 Deloy to container 这个插件，其实它没用 Publish 那么好用。
至于个人自己公司的发布方式到底怎么取舍还是看个人，我这里就是一些建议。