前端工程化之自动化部署

自动化部署

CI & CD

每个公司或多或少都会有这样的研发平台，通过这样的平台，我们无需关注CI/CD相关的内容
平台可以帮助完成：

• 日常环境发布
• 测试环境发布
• 线上环境发布

将发布流进行统一收口，无需关注整个发布过程，以及涉及的灰度，告警机制等

github actions

github actions 文档
将我们的项目(无论是github的，还是私有源的)通过自动化的方式打包构建到目标服务器上

.git 目录下的 workflows 目录，deploy.yml 和 test.yml 两个文件

前期配置

1. 账号下 - settings - 创建 token

生成一个 ACCESS_TOKEN 和 GITHUBTOKEN，保存“ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”的token码

为什么要创建这个token？
需要对权限进行授权，对仓库的读，写权限，创建文件权限等设置，对仓库进行授权后，才能对当前仓库进行干预，有些工作流会去写些目录到当前工作当中，不会让其他人擅自对仓库内容篡改

2. 在工程当中 - 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组成

=>有了这些配置可以完成 自动化测试，自动化部署，自动化构建，自动化通知和自动化相关文本生成等等。

使用方法

• name 当前workflow的名称(deploy)
• on 触发当前workflow的条件，通常是 某些事件
  on:[push, pull_request]
  • branchs：分支
    • master 举例
• 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

正式流程

创建 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 Deploypermissions:contents: writeon:push:branches:- masterjobs:build-and-deploy:runs-on: ubuntu-lateststeps:# 步骤1：检出仓库代码到运行器环境- name: Checkout   uses: actions/checkout@v2  # 使用官方 checkout 动作拉取仓库内容# 步骤2：设置 Node.js 开发环境- name: lock and versionuses: 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: testpermissions:contents: writeon:push:branches:- masterjobs:build-and-deploy:runs-on: ubuntu-lateststeps:- name: Checkoutuses: actions/checkout@v2- name: lock and versionuses: actions/setup-node@v3with:node-version: 18.12.0- name: Install dependencies and buildrun: |npm i -g pnpmpnpm installenv:NODE_OPTIONS: --max_old_space_size=4096- name: testrun: |pnpm run test

自动生成 gh-pages 分支

设置 gh-pages分支

项目下：Settings - Pages - 设置分支 “gh-pages” - Save 保存

刷新后自动生成站点：

之后提交代码到 master 分支后，这里会监听到，就会重新打包，然后放到对应的文件夹，重新更新站点

还有像 vercel平台，无需写yaml，能够帮助完成相关的配置