skip to content
OnionTalk

持续部署新法宝 - 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

// .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 入门教程