你知道什么是 GitHub Action 么？

本文是 GitHub Action 的入门教程，如您已有相关使用经验能够直接关掉。

GitHub Action 是 GitHub 于 2018 年 10 月推出的一个 CI\CD 服务。

以前一直都是 Beta 版本，正式版于 2019 年 11 月正式推出。

首先仍是先放几个官方的连接：

GitHub Action ： github.com/features/ac…

GitHub Action 官方市场： github.com/marketplace…

CI\CD

CI\CD 其实说的是三件事情：「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」、「持续部署（Continuous Deployment）」。

由于「持续交付」和「持续部署」的英文缩写是同样的，因此这三件事情缩写成了 CI\CD 。

持续集成

那么什么是「持续集成」？借用一幅图：

从这幅图上能够很清楚的看到「持续集成」的流程：

• 开发人员提交代码到 Source Repository （源代码仓库），并经过 git hook 等
• 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程
• 向开发人员反馈结果的 report

咱们在平常开发中常用到的集成方式是「阶段集成」（完成一个阶段的开发后执行代码的集成），相比较而言，「持续集成」能给咱们带来的好处有哪些？

• 易于定位错误：每一次的代码集成都须要执行相关的测试工做，持续集成频繁的集成次数自然的*将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误可以更加容易的被定位；
• 易于控制开发流程：更为细致的工做提交也就意味着更容易判断当前的工做进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工做的时间；
• 易于 CodeReview：对于大块工做的切分天然也有助于作 CodeReview；
• 易于减小没必要要的工做：build 以及 test 过程的自动化能够为你节约一大票的时间，从而投入到有价值的工做中去。

持续交付

什么是持续交付呢？

「持续交付」 指的是：一种可以使得软件在较短的循环中可靠的发布的软件工程方法。

与「持续集成」相比，持续交付的侧重点在于 交付 ，其核心对象不在于代码，而在于可交付的产物。

「持续集成」仅仅针对于新旧代码的集成过程执行了必定的测试，其变更到持续交付后还须要一些额外的流程。

从上面这张图能够看到，与「持续集成」相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

在这一增长的流程中，Test 环节不只仅包含基本的单元测试，还须要延伸到更为复杂的功能测试以及集成测试等。

在这里，Staging 指的是 类生产环境 ，其尽量的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。

流程中每个环节的执行结果都会对开发人员进行反馈，每个出现的错误都会致使版本的回滚。

当测试完毕确认无误以后，将由相关人员对其进行 手动 部署到生产环境。

持续部署

「持续部署」意味着：经过自动化部署的手段将软件功能频繁的进行交付。

与「持续交付」以及「持续集成」相比，「持续部署」强调了经过 automated deployment 的手段，对新的软件功能进行集成。

经过和「持续交付」的图对比，区别主要体如今对 Production 的自动化。

从开发人员提交代码到编译、测试、部署的全流程不须要人工的干预，彻底经过自动化的方式执行。

这一策略加快了代码提交到功能上线的速度，保证新的功能可以第一时间部署到生产环境并被使用。

从前面这些介绍能够看到，CI/CD 是由不少操做组成，好比抓取代码、运行测试、登陆远程服务器，发布到第三方服务等等。GitHub 把这些操做就称为 actions。

不少操做在不一样项目里面是相似的，彻底能够共享。GitHub 注意到了这一点，想出了一个很妙的点子，容许开发者把每一个操做写成独立的脚本文件，存放到代码仓库，使得其余开发者能够引用。

若是你须要某个 action，没必要本身写复杂的脚本，直接引用他人写好的 action 便可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

GitHub 作了一个官方市场，能够搜索到他人提交的 actions。

连接：github.com/marketplace…

在很长一段时间里， GitHub 我都是当作代码仓库或者版本管理工具来用，有时候还用做文件管理工具（速度属实有点慢，文件管理工具更多的是使用国内的 Gitee）。

有了 GitHub Action 之后， GitHub 除了上面这些功能之外，能作的事情就更多了，好比我在 master 分支上提交了一段代码， GitHub Action 能够自动的帮我部署到我本身的服务器上去，或者它还能够帮我把代码打成镜像，将镜像自动提交到镜像仓库里。

虽然这些事情本身手动也能作，可是，能让机器本身作的事情就让本身本身作嘛，毕竟懒惰是程序员的第一辈子产力。

GitHub Action 基本概念

GitHub Actions 有一些本身的术语。

1. workflow （工做流程）：持续集成一次运行的过程，就是一个 workflow。

2. job （任务）：一个 workflow 由一个或多个 jobs 构成，含义是一次持续集成的运行，能够完成多个任务。

3. step（步骤）：每一个 job 由多个 step 构成，一步步完成。

4. action （动做）：每一个 step 能够依次执行一个或多个命令（action）。

React 项目发布至 GitHub Page

React 是由 FaceBook 开源的一个前端框架，有相关经验的同窗应该都清楚， React 项目是须要打包编译的，我此次就用 React 尝试下使用 GitHub Action 编译、打包以及部署。

源码仓库：github.com/meteor1993/…

GitHub Page：meteor1993.github.io/github-acti…

第一件事情是咱们须要先建立一个 GitHub 密钥，由于咱们须要将示例部署至 Github Page ，须要写权限，建立完成后将这个秘钥保存在当前仓库的 Settings/Secrets 里面。

建立秘钥能够参考官方文档：help.github.com/en/github/a… 。

点击本身头像，选择 Settings ：

在左边栏选择 Developer settings ：

而后在左边栏选择 Personal access tokens 点击头上的 Generate new token 建立一个新的 Token ：

注意： 建立完成后须要保存好这个 Token ，它只会出现这一次。

接下来，建立一个项目，我这里建立的名字叫作 github-actions-demo ，而后点击项目中的 Settings ，在 Secrets 的栏目中将刚才建立的 Token 填写进去：

这里的名称随便填写，可是要记住，后面咱们会用到。

接下来是建立一个标准的 React 应用：

npx create-react-app github-actions-demo
复制代码

等待进度条走完，而后打开项目中的 package.json 文件，添加一个 homepage 字段，以下：

"homepage": "https://[username].github.io/github-actions-demo",
复制代码

将 [username] 替换成你本身的 GitHub 用户名，

我这边完整的 package.json 文件内容以下，供参考：

{
  "name": "github-actions-demo",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^4.2.4",
    "@testing-library/react": "^9.5.0",
    "@testing-library/user-event": "^7.2.1",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-scripts": "3.4.1"
  },
  "homepage": "https://meteor1993.github.io/github-actions-demo",
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}
复制代码

接下来是在这个项目中，在 .github/workflows 的目录中生成一个 workflow 文件，名字能够随便取，这个我这里的名称是 ci.yml 。

下面是 ci.yml 中的内容：

name: GitHub Actions Build and Deploy Demo
on:
 push:
 branches:
 - master
jobs:
 build-and-deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@master # If you're using actions/checkout@v2 you must set persist-credentials to false in most cases for the deployment to work correctly.
 with:
 persist-credentials: false
 - name: Install and Build
 run: | npm install npm run-script build  - name: Deploy
 uses: JamesIves/github-pages-deploy-action@releases/v3
 with: 
 ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
 BRANCH: gh-pages
 FOLDER: build
 BUILD_SCRIPT: npm install && npm run build
复制代码

这里使用了一个别人已经写好的 Action ： JamesIves/github-pages-deploy-action ， Github Action 市场的地址为：github.com/marketplace… 。

大体讲下上面这个配置文件作了什么：

1. workflow 命名
2. 说明了整个流程在 master 分支发生 push 的时候触发
3. 而后获取源码，使用的 action 是 actions/checkout
4. 而后是构建和部署，使用的 action 是 JamesIves/github-pages-deploy-action
5. 而后是配置环境变量，这里的 ACCESS_TOKEN 就是咱们刚才申请的 Token ，由于个人命名是 ACCESS_TOKEN ，因此这里这么写，若是有其余命名请自行更换， BRANCH 是配置部署的分支，我这里是部署到了 gh-pages 分支。

workflow 文件的配置字段很是多，详情能够参考官方文档：help.github.com/en/actions/… ，悄悄说一句，有中文版的哦~

接下来最后一步就是将这个项目提交到 Github 的 master 分支，而后咱们在 Github 上点击 Action ，就能够看到当前的构建了：

而后点击进入 Action 之后，能够看到当前的实时日志：

日志默认保存 30 天。

等到项目部署成功后，访问咱们以前的连接：meteor1993.github.io/github-acti… ，就能够看到效果了：

而后每次推送到 mater 分支，Github Action 都会自动运行，将构建产物发布至 Github Page ，感受这个东西很适合作静态博客网站有木有，好比 Hexo 啥的。

参考

www.ruanyifeng.com/blog/2019/0…

blog.csdn.net/qq_35368183…

您的扫码关注，是对小编坚持原创的最大鼓励：）