你知道什么是 GitHub Action 么?

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

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

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

首先还是先放几个官方的链接:

GitHub Action : https://github.com/features/actions

GitHub Action 官方市场: https://github.com/marketplace?type=actions

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。

链接: https://github.com/marketplace?type=actions

在很长一段时间里, 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 编译、打包以及部署。

源码仓库: https://github.com/meteor1993/github-actions-demo/settings

GitHub Page: https://meteor1993.github.io/github-actions-demo/

第一件事情是我们需要先创建一个 GitHub 密钥,因为我们需要将示例部署至 Github Page ,需要写权限,创建完成后将这个秘钥保存在当前仓库的 Settings/Secrets 里面。

创建秘钥可以参考官方文档: https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line

点击自己头像,选择 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 市场的地址为: https://github.com/marketplace/actions/deploy-to-github-pages

大致讲下上面这个配置文件做了什么:

gh-pages

workflow 文件的配置字段非常多,详情可以参考官方文档: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions ,悄悄说一句,有中文版的哦~

接下来最后一步就是将这个项目提交到 Github 的 master 分支,然后我们在 Github 上点击 Action ,就可以看到当前的构建了:

然后点击进入 Action 以后,可以看到当前的实时日志:

日志默认保存 30 天。

等到项目部署成功后,访问我们之前的链接: https://meteor1993.github.io/github-actions-demo/ ,就可以看到效果了:

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

参考

http://www.ruanyifeng.com/blog/2019/09/getting-started-with-github-actions.html

https://blog.csdn.net/qq_35368183/article/details/84558134

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章