持续部署新法宝：GitHub Actions

最近，我把我的博客部署从 Travis 迁移到了 Github Actions。在迁移过程中，我发现 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

        1234567891011121314151617181920212223242526272829

        // .github/workflow/blog-publish.ymlname:BlogPublishon:[push]jobs:build:name:Build&Deployruns-on:ubuntu-lateststeps:-name:Checkoutcodeuses:actions/[email protected]:Setupnodeuses:actions/setup-node@v1with:node-version:'12.x'-run:yarn-name:SetupHugouses:peaceiris/[email protected]:Hugobuildrun:hugo-dwww/public-name:SetupGclouduses:GoogleCloudPlatform/github-actions/setup-gcloud@masterwith:version:'281.0.0'service_account_email:${{secrets.GCLOUD_EMAIL}}service_account_key:${{secrets.GCLOUD_KEY}}-name:deployrun:|gcloudconfigsetproject${{secrets.PROJECT_ID}}gcloudappdeploy-q

整个 Workflow 解析如下

1. Workflow 由代码 Push 触发 on: [push]
2. Workflow 只有一个 Job Build & Deploy
3. Job 运行在最新的 Ubuntu 上 runs-on: ubuntu-latest
4. Job 的第一步是拉取代码，调用了官方的 actions/[email protected]Action
5. 因为项目依赖nodejs，第二步是配置 nodejs 环境，使用了官方的 actions/setup-node@v1这个 Action，同时指定 nodejs 版本为 12.x
6. 第三步运行 yarn命令来安装依赖
7. 第四步使用三方的 peaceiris/[email protected]来初始化 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 入门教程