大家好,我是小九九的爸爸,本次给大家带来的内容是自动化部署。聊到这个方向,大家肯定都会想到CI、CD等一系列名词。那这次就来一遍看个透吧。这篇文章肯定会有没讲到的地方,也欢迎大家在评论区里补充。
首先来说一下 部署(Deployment)
,它其实就是代码发布的一种行为。就拿前端来举例子,如果是开发的工具库的话,那肯定避免不了下面的流程:
- npm config set registry xxx
- npm login
- npm version xxx
- npm publish
- npm run build(生成工具库的使用文档以及changelog)
- 将使用文档推到服务器上或者免费的托管平台。
这一套下来,你说是否繁琐呢,不好定义。这个时候出现了自动部署的概念。相当于你把你固定的操作流程写成一个任务清单,然后自动化部署工具执行这个任务清单就完事了。
所以你看,自动部署(Continuous Deployment,简称CD)干了什么事呢?其实就是帮你执行那些重复的部署动作。当然,如果你觉得手动部署也花费不了自己多长时间,那自动部署对你来说就完全没必要了。
实现自动化部署有哪些方案呢?Jenkins是一个,GitHub Action也是一个解决方案。
那我们本篇文章的主角就出来啦,GitHub Action。
GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台,这个平台主要是依靠“工作流”的概念来完成部署的功能。同时,它也可以将整个运行流程给可视化出来。下图就是我们今天要做出来的成果:
如何使用GitHub Action?
这个功能是依附在GitHub平台上的,所以要求就是你的项目必须托管在GitHub上。为了方便学习GitHub Action,我们可以随便在自己的账号下建一个项目,建项目的流程在这里就省略了,请自行发挥。
上面我们说过,这个功能是围绕“工作流”来展开。那我们就来说说“工作流”的概念吧。
什么是工作流?
工作流是一个可配置的自动化流程,将运行一个或多个作业。工作流由YAML文件定义。
上面这句话我第一次看的时候,其实内心是懵逼的,后来我知道了,它想表述的是一个工作流,就是一个yaml文件,就是一个可以执行具体命令的容器
。yaml文件的位置是有要求的,位于项目根目录下的.github目录下的workflows目录里。我的项目名称叫做play-github-action,所以我的项目结构应该是下面这样的:
/**
| - play-github-action
| - .github
| - workflows
- 11.yml
- learn-github-action.yml
*/
工作流有哪些配置?
配置 | 说明 | 是否必输 |
---|---|---|
name | 表明这次工作流的名称 | 是 |
on | 表明工作流里的任务什么时候被执行 | 是 |
jobs | 表明工作流里的任务集合 | 是 |
concurrency | 表明工作流里的最大任务数量 | 否 |
说了那么多,我们来配置下yml文件,来看看效果:
# learn-github-action.yml配置如下:
name: learn-github-action
on: [push]
# 11.yml配置如下:
name: 11
on: [push]
当我们push代码的时候,这2个工作流就会被执行,此时回到GitHub平台,点击actions页签来看一下具体的情况:
从上面的工作流程,我们可以暂时得出GitHub Action平台有以下几点规律:
- 只要你push来代码,就会执行yml文件。这是因为我们使用了on关键字。当然如果你想指定push某个分支时再执行话,这也是可以的。这种需求很常见,比如main分支里有yml文件,你今天基于main分支新切了一个develop分支,那此时develop分支里,自然就会有main分支的yml文件。如果你想指定push main分支时才会运行workflow,那么你可以这么写:
name: CI
on:
push:
branches: [ main ]
- 在这个平台里,一个yml就是一个数据list,点进去我们就会看到具体的任务,以及任务里的步骤。
- 当我们多次提交后,会发现,其实每个yml文件的执行顺序是不固定的。这是因为工作流之间默认的工作方式是并发。
- 上面的workflows报错啦,符合预期,因为我们并没有定义jobs。
什么是作业?
我们以单页面应用来举例子,我们部署应用的时候一般会经历以下步骤:
- 拉取代码
- 安装依赖
- 执行打包
- 将打包后的产物推到远程服务器里
那这个时候,这4个动作就可以被认为是4个作业。当然,你也可以把这4个动作合并为一个作业,你甚至也可以分解为2个作业,这完全取决于用户。
那如何声明job呢?使用jobs关键字。jobs定义里一个集合,你需要将跟本次需求相关的job都放入到这个集合里。还需要声明一点,当一个workflow里拥有多个job时,默认情况下,job的执行顺序是并行的。
作业有哪些配置?
配置 | 说明 | 是否必输 |
---|---|---|
jobs.job_id | 作业的id | 是 |
jobs.job_id.runs-on | 定义运行job时的计算机类型。其实就相当于指定服务器的运行系统。 | 是 |
jobs.job_id.steps | 完成id为job_id的任务,需要执行的步骤集合。 | 是 |
jobs.job_id.steps.run | 执行shell命令,相当于node里的child_process。 | 是 |
jobs.job_id.steps.use | 用于获取你上传的代码。 | 是 |
jobs.job_id.name | 当前作业id的名称。如果你只配置里job_id,那么平台会认为作业的id、name是一样的。 | 否 |
jobs.job_id.needs | 定义job之间的关系 | 否 |
又说了那么多,我们再来修改下配置,然后再see one see 效果:
# learn-github-action.yml配置如下:
name: learn-github-action
on: [push]
jobs:
checkout-bats-version1: # job_id
name: checkout-version1-name # job_id.name
runs-on: ubuntu-latest # job_id.runs-on
steps:
- uses: actions/checkout@v1 # 检出代码
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats # 执行命令
- run: bats -v
push一下代码,我们再来看下效果:
learn-github-action.yml文件执行成功了,但是 11.yml 文件失败了。符合预期,因为我们只改了learn-github-action.yml文件。点进去看一下:
那我如果再加一个任务呢?
name: learn-github-action
on: [push]
jobs:
checkout-bats-version1: #job1
name: checkout-version1-name
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
checkout-bats-version2: #job2
name: checkout-version2-name
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
运行一下,效果如下:
这个效果图告诉我们,当前这2个任务是并行的关系。那如何表示任务之间是继发的呢?needs关键字闪亮登场,修改yml文件如下:
name: learn-github-action
on: [push]
jobs:
checkout-bats-version1: #job1
name: checkout-version1-name
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
checkout-bats-version2: #job2
name: checkout-version2-name
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
checkout-bats-version3: #job3
needs: [checkout-bats-version1, checkout-bats-version2]
name: checkout-bats-version3-name
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
运行以后,我们就得到了文章开头的那个图。这段代码表示,job3的运行之前,必须先运行job1、job2。
可能会用到的其他知识点
上下文
它其实就是一个对象,这个对象里包含里当前workflow的信息、当前workflow下的每个job的信息、当前workflow下的所有变量的信息等等。
那如何访问上下文对象呢?语法如下:
${{ context上下文 }}
它可以在任何地方被使用,比如可以在if表达式里使用。举个例子,上面的步骤中,我们不是使用了on关键字实现了push指定分支才触发workflow
嘛,我们也可以使用上下文来实现这个功能:
name: learn-github-action
on: [push],
jobs:
checkout-bats-version1: # job_id
name: checkout-version1-name # job_id.name
if: ${{ github.ref == 'refs/heads/main' }}
runs-on: ubuntu-latest # job_id.runs-on
steps:
- uses: actions/checkout@v1 # 检出代码
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats # 执行命令
- run: bats -v
只有当if条件通过啦,github action才会将 名为checkout-version1-name的job 发送到运行器ubuntu-latest上,将作业发送到运行器后,执行job下的步骤。在这个步骤里,我们使用了内置的github上下文,还有很多内置的上下文,具体的可以去 上下文 - GitHub 文档看看。
环境变量
在env关键字下设置变量,语法如下:
name: learn-github-action
on: [push],
env:
DAY_OF_WEEK: Monday
部署
github action也支持将前端工具发布到npm上,具体的操作,相信有前面的铺垫后,阅读起来应该不成问题。文章来源:https://www.toymoban.com/news/detail-827444.html
最后
好啦,本期分享到这里就结束啦,希望我的分享对你有帮助,如果你觉得还可以,也可以给我来一个3星好评,我们下期再见啦~~文章来源地址https://www.toymoban.com/news/detail-827444.html
到了这里,关于GitHub Action一次看个透的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!