持续部署新法宝 - Github Actions

什么是 Github Actions

Github Actions 是 Github 推出的一项服务，旨在以自定义工作流的方式来简化团队开发协作中的各种需求。比如：

1. 基于 Code Commit 的代码构建/测试/打包，也就是常说的持续集成。
2. 应用的自动发布和部署，和上一步连起来就是所谓的持续部署。
3. 自动管理 PR（如自动 assign viewer）
4. 自动管理 issue（如自动给 issue 分类，自动关闭长期不更新的 issue ）

Github Actions 的优点

1. 灵活性

对比主要竞品 Jenkin/GoCD 以及 Circle CI/ Travis CI， 相较于 Jenkins/GoCD 只能够自建服务，CirCle CI(2.0 以前) / Travis CI 只能依靠官方提供的服务，Github Actions 可以使用 Github 官方的 Runner，同时 Github Actions 也支持使用用户自建的（比如搭载某内网环境的 instance）Runner。Github Actions 还自带 Linux/macOS/Windows 三种类型的 Runner，能够满足不同用户群体在不同场景的需要。

2. 复用性

对于开发者而言，编写重复的代码永远都是一种灾难。而在 Github Actions 的准则中，每一条 Action 都是一个最小的可复用单元，只需要一次编写，便可以在之后随时随地的使用。更棒的是，Action 可以通过组合的方式来使用，完成更为复杂的功能。

3. 可维护性

每一条 Action 其实就是一个 JavaScript module/Docker container，由于 Action 本身就是代码，所以 Action 本身是可以很好的被版本管理的。同时由于支持使用 JavaScript 编写 Action，只要你想，你可以使用大量的测试来保证你的 Action 的质量。

4. 社区支持

社区意味着生态，而在 Github 上有成千上万的开发者每天都在为 Github Actions 做着贡献。你能想到的任何一个会出现在 CI/CD 中的需求，比如发布到 AWS/GCP，或是生成一份测试覆盖率的报告并且发到 slack 上，可能都已经有人写好上传到了 Github Marketplace 里面了。

5. 经济性

对于 Github Actions， Github 提供了完全够用的使用额度（见下图）。除此之外，Github Marketplace 的 Actions 也可以免费的进行使用。

6. 自带 Github Buff 加成

由于是 Github 自家的产品，Github Actions 与 Github 的各项功能都无缝集成的非常好，除了上面提到的能自动管理 Issue，自动分配 Pull Request Reviewer 之外，还支持 Pull Request Checks 等等。

Github Actions 的基本要素

和所有的 CI/CD 系统类似， Github Actions 也有一些比较核心的准则，理解这些准则能帮助你能更好的使用和编写 Github Actions。

1. Action 是一个独立的 task，每一个 Action 是一个最小的可复用单元。设计 Action 应尊重 Unix 哲学，做一件事情，并且把一件事情做好（Do one thing and do it well)。比如，进行 eslint 检查就是一个 Action 。
2. Step 是多个 Action 或者多个 Command (CLI 命令）顺序执行的组合。比如，我除了有 eslint 的检查，还有 style lint 的检查，可以把这两个 Action 组合在一起，创建一个叫 lint 的 step。
3. Job 是 Step 的组合。Job 与 Job 之间并没有强烈的依赖关系（当然也可以声明 needs 来指定依赖关系），多个 Job 可以并行运行。在默认情况下，每个 Job 运行在不同的 Runner 中。比如，我可以把构建，测试，打包这三个 Step 组合起来，生成一个 Build Job，或者把发布，心跳测试组合在一起，生成一个 Deploy Job。
4. Workflow 是 Job 的组合。一个 Workflow 就是能被某个 Event 触发的完整的自动化工作流。比如上面的 Build 和 Deploy 这两个 Job 就能组合成一条发布的 Workflow。
5. Runner 是运行 Job 的一套虚拟运行环境，Github 官方支持 Linux/macOS/Windows 三种操作系统的运行环境。
6. Event 是 Github 上发生的能触发 Workflow 的行为，比如代码提交，生成 Pull Request，Issue 被评论等等，这些都是 Event。

最后，用一张图来总结一下

一个最简单的 Github Actions Workflow

下面这个例子演示了一个最简单的 Workflow，基于这个 Workflow ，我们能发布一个基于 Hugo 的博客到 GCP APP Engine

// .github/workflow/blog-publish.yml
name: Blog Publish
on: [push]
jobs:
 build:
   name: Build & Deploy
   runs-on: ubuntu-latest
   steps:
   - name: Check out code
     uses: actions/checkout@v2.0.0
   - name: Set up node
     uses: actions/setup-node@v1
     with:
       node-version: '12.x'
   - run: yarn
   - name: Setup Hugo
     uses: peaceiris/actions-hugo@v2.4.5
   - name: Hugo build
     run: hugo -d www/public
   - name: Setup Gcloud
     uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
     with:
       version: '281.0.0'
       service_account_email: ${{ secrets.GCLOUD_EMAIL }}
       service_account_key: ${{ secrets.GCLOUD_KEY }}
   - name: deploy
     run: |
       gcloud config set project ${{ secrets.PROJECT_ID }}
       gcloud app deploy -q

整个 Workflow 解析如下

1. Workflow 由代码 Push 触发 on: [push]
2. Workflow 只有一个 Job Build & Deploy
3. Job 运行在最新的 Ubuntu 上 runs-on: ubuntu-latest
4. Job 的第一步是拉取代码，调用了官方的 actions/checkout@v2.0.0 Action
5. 因为项目依赖 nodejs，第二步是配置 nodejs 环境，使用了官方的 actions/setup-node@v1 这个 Action，同时指定 nodejs 版本为 12.x
6. 第三步运行 yarn 命令来安装依赖
7. 第四步使用三方的 peaceiris/actions-hugo@v2.4.5 来初始化 hugo 环境
8. 第五步运行 hugo -d www/public 命令进行打包
9. 第六步使用 GCP 官方提供的 Action GoogleCloudPlatform/github-actions/setup-gcloud@master 初始化 GCP 命令行工具，在其中使用 secrets 来储存敏感信息。（如何配置 secret）
10. 最后一步使用 GCP 进行认证和部署。

当这样一个 Workflow 部署完成之后，每次当你的博客有新的代码 push 到 Github ，这个 Workflow 就会自动运行，帮助你把最新的内容发布到你的博客。你能看到这篇文章，也归功于 Github Actions。

参考链接

GitHub Actions Documentation - GitHub Help > GitHub Actions 入门教程