【08】Jenkins：关于发布

写在前面的话

 

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 那么好用。

至于我的本身公司的发布方式到底怎么取舍仍是看我的，我这里就是一些建议。