自动化部署
自动化部署
CI & CD
每个公司或多或少都会有这样的研发平台,通过这样的平台,我们无需关注CI/CD相关的内容
平台可以帮助完成:
- 日常环境发布
- 测试环境发布
- 线上环境发布
将发布流进行统一收口,无需关注整个发布过程,以及涉及的灰度,告警机制等
github actions
github actions 文档
将我们的项目(无论是github的,还是私有源的)通过自动化的方式打包构建到目标服务器上
.git 目录下的 workflows 目录,deploy.yml 和 test.yml 两个文件
前期配置
- 账号下 - settings - 创建 token
生成一个 ACCESS_TOKEN 和 GITHUBTOKEN,保存“ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”的token码
为什么要创建这个token?
需要对权限进行授权,对仓库的读,写权限,创建文件权限等设置,对仓库进行授权后,才能对当前仓库进行干预,有些工作流会去写些目录到当前工作当中,不会让其他人擅自对仓库内容篡改
- 在工程当中 - settings - 引入 Token
NAME:GITHUBTOKEN,secret:填写上面保存的token码
如果没保存的话,可以在生成token码的地方,点击重新生成token即可。
在 deploy.yml 文件中有一些变量的注入,下面这里的token就来自上面的token,通过上面的token查看权限,看是否对仓库有写权限,如果有写权限的话,就会写入一些文件
就比如 change-log,会自动的创建对应的change-log,去写入到当前的工程当中
这也是为什么有前置操作的原因
git actions 配置
- workflow 工作流程
- job 任务 一个工作流程可能由多个job组成的
- step 步骤,一个任务可能由多个步骤组成的
- action 动作,每个步骤由多个action组成
- step 步骤,一个任务可能由多个步骤组成的
- job 任务 一个工作流程可能由多个job组成的
=>有了这些配置可以完成 自动化测试
,自动化部署
,自动化构建
,自动化通知
和自动化相关文本生成
等等。
使用方法
- name 当前workflow的名称(deploy)
- on 触发当前workflow的条件,通常是 某些事件
on:[push, pull_request]- branchs:分支
- master 举例
- branchs:分支
- jobs: 可以完成一项或多项任务
- my_first_job :
- name:“my_first_job”
- job2:
- needs: my_first_job # needs当前任务依赖关系,运行顺序
- my_last_job:
- name:“my_last_job”
- needs:[my_first_job, job2]
- runs-on: ubuntu-latest # 设置所需要的虚拟环环境,必填 (ubuntu-latest,windows-latest,macos-latest)
- steps: 每个job运行的步骤
- name: install node_modules 安装当前依赖
- env: 设置运行时候的环境变量
- FIRST_NAME: abc
- LAST_NAME: def
- run: | # 运行脚本内容
- echo $LAST_NAME & $FIRST_NAME
- my_first_job :
正式流程
创建 deploy.yaml 和 test.yaml 文件
代码中创建 .github/workflows/deploy.yaml, .github/workflows/test.yaml文件,上传到github后,系统会自动触发部署,从而自动增加 gh-pages 分支,分支下相对应的文件 和 本地执行“pnpm run build”生成的 build/dist 文件下的内容一致
.github/workflows/deploy.yaml
文件示例:
name: Build and Deploy
permissions:
contents: write
on:
push:
branches:
- master
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# 步骤1:检出仓库代码到运行器环境
- name: Checkout
uses: actions/checkout@v2 # 使用官方 checkout 动作拉取仓库内容
# 步骤2:设置 Node.js 开发环境
- name: lock and version
uses: actions/setup-node@v3 # 配置 Node.js 运行时
with:
node-version: 18.12.0 # 指定使用 Node.js 18.12.0 版本
- name: Install dependencies and build
# 使用npm全局安装pnpm,然后使用pnpm安装依赖,最后使用pnpm build打包
run: | # 多行命令执行序列
npm i -g pnpm # 全局安装 pnpm 包管理器
pnpm install # 安装项目依赖
pnpm run build # 执行构建命令
env:
NODE_OPTIONS: --max_old_space_size=4096 # 分配 4GB 内存给 Node 进程
# 部署到 GitHub Pages 使用第三方 Action JamesIves/github-pages-deploy-action,将 build 目录中的内容推送到 GitHub Pages 分支(通常是 gh-pages),整个过程通过 ACCESS_TOKEN 进行安全认证
- name: Deploy 🚀
uses: JamesIves/github-pages-deploy-action@v4 #使用别人的包
with:
folder: build # 将dist目录内容放在哪个文件夹下,也就是指定要部署的构建目录
ACCESS_TOKEN: ${{ secrets.GITHUBTOKEN }} #需要写入的权限,使用仓库密钥进行认证
.github/workflows/test.yaml
test文件示例,添加自动化测试
name: test
permissions:
contents: write
on:
push:
branches:
- master
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: lock and version
uses: actions/setup-node@v3
with:
node-version: 18.12.0
- name: Install dependencies and build
run: |
npm i -g pnpm
pnpm install
env:
NODE_OPTIONS: --max_old_space_size=4096
- name: test
run: |
pnpm run test
自动生成 gh-pages 分支
设置 gh-pages分支
项目下:Settings - Pages - 设置分支 “gh-pages” - Save 保存
刷新后自动生成站点:
之后提交代码到 master 分支后,这里会监听到,就会重新打包,然后放到对应的文件夹,重新更新站点
还有像 vercel平台,无需写yaml,能够帮助完成相关的配置