本文介绍如何对一些典型的页面进行持续构建和部署(CI & CD)

在最近的开发过程中， 想对 Next 实现的项目进行自动化发布， 因此自己写了一些 Python 脚本来进行这样的任务。最开始的时候是利用 GitHub 的 WebHook 通过后端拉取然后构建部署，然后又尝试通过 Python 脚本在本地打包部署，两种方式对比，本地脚本的方式要复杂一些，灵活性更好。

在开发一个网页工程的过程中，通过 Next 框架实现 SSR APP。由于代码在内部服务器，可能的发布方式有如下：

  1. 编写自动化脚本进行构建测试和发布
  2. 利用 Gitlab runner 进行自动化构建测试和发布
  3. 直接通过生产服务器拉取代码，但需要暴露内部代码服务器到外网（暂不考虑）。
  4. docker 发布：仅几个简单的 HTML 页面，Docker 有点杀鸡用牛刀了。
  5. 通过一个三方中转，类似一些自动部署平台的方式，利用 GitHub 的 WebHook 通知生产服务器拉取生成物直接部署。

编写自动化脚本进行发布

这里选择的是 Python，利用 Fabric 可以直接和服务器建立链接并执行相关操作。将发布过程简化为如下几步：

  1. 从内部服务器拉取源码
  2. 本地从源码进行构建，输出待发布的产物（这里打包为 zip）
  3. 将 zip 上传到服务器
  4. 部署并启动服务

在编写脚本的过程中，通过 JSON 作为配置文件，这样不同的项目也可以通过上述流程直接使用相同的脚本不同的配置进行部署。

由于使用 Python 实现上述的过程非常简单，代码量也非常少，这里就不再赘述了，并且后续还可以添加测试执行阶段等，可以逐步完善。

配置文件大概是这样的结构：

json
{
  "repo": "", // 仓库 git url
  "branch": "master", // 需要构建的分支
  "artifacts_dir": "./public/", // 构建产物存放的目录
  "before_build": [["一些构建之前需要进行的动作, 比如创建临时目录等"]],
  "build": [["yarn", "build"]], // 执行构建脚本，也可以是命令
  "after_build": [["cp ./xxx.html ./public/"]], // 构建完成后的操作，比如要复制一些文件到最终产物的目录
  "compressed_zip_artifacts_name": "artifacts", // 产物压缩后的文件名，便于上传后识别文件
  "remote_ssh": "user@xxx.com", // ssh user@host
  "remote_deploy_dir_path": "/tmp/", // 上传到哪个远程文件夹
  "deploy_commands": [
    // 远程部署时需要执行的一些命令，当然也可以写一个脚本放到远端，这里直接执行它，传参即可
    "xx",
    "xxx"
  ]
}

下面再讲一下之前用到的 WebHook 的发布流程，仅提供多一种思路。。。

WebHook 自动发布的流程

只需如下几步：

  1. 在 GitHub 创建一个私有仓库用于存放输出的静态页面。
  2. 在生产服务器上部署一个简单的 web 服务用于接收 WebHook 的消息。
  3. 当比如 Push 到指定分支时， GitHub 会通过 WebHook 往 web 服务发送一个 POST 请求，并携带相关信息。
  4. 解析请求内容，拉取静态页面，替换生产服务器上相关文件即可。

一些注意事项

  1. 由于 Web 服务一直暴露在外，因此需要格外关注请求验证，处理非法或者是恶意构造的请求（比如伪造仓库 URL，短时间连续请求等）
  2. 最后进行部署时，需要考虑增量替换还是完整替换（比如利用 rsync 进行增量替换）