使用GitHub Actions实现自动化部署

前言

大家在工作中想必都是通过自动化部署来进行前端项目的部署的，也就是我们在开发完某个需求时，我们只需要将代码推送到某个分支，然后就能自动完成部署，我们一般不用关心项目是如何build以及如何deploy的，这就极大得提高了我们的开发效率。

在没有自动化部署的情况下，前端项目的部署流程一般是这样的：（手动部署）

• 开发完成后本地进行build
• 将build后的文件交给运维（前端人员有权限的可省略）
• 将打包文件上传到服务器的指定目录

前端项目每次上线都得走一遍这个流程，对于程序员来讲这怎么能忍，宁愿将时间浪费在B乎上也不可能浪费在这些毫无技术的工作流程上，并且人工操作，难免会出错。

所以今天给大家分享一下如何实现自动化部署自己的前端项目。

如果这篇文章有帮助到你，❤️关注+点赞❤️鼓励一下作者，文章公众号首发，关注 ​​前端南玖​​ 第一时间获取最新文章～

自动化部署脚本

先来分享一种简单的自动化部署方案 - 自动化部署脚本

我们每次部署项目时，会有几个步骤是固定的，既然它是固定的，那么我们就可以通过写脚本来帮助我们完成，这样不仅能够提高我们的开发效率，还能避免人为操作时可能出现的纰漏。

新建仓库

我们可以在GitHub上新建一个项目并尝试把它部署到GitHub Pages上。

新建项目

这里我们新建一个Vue3 + TS 项目

添加脚本

我们直接在项目根目录下新建一个脚本文件​​deploy.sh​​

#!/usr/bin/env sh

set -x  # 这里是为了看错误日志

# 打包项目
npm run build

# 进入打包后的文件夹
cd dist

git init
git add -A
git commit -m 'auto deploy'

# 将打包后的文件推送到指定分支

git push -f https://github.com/bettersong/nanjiu.git main:static-pages

执行脚本

现在我们可以执行​​sh deploy.sh​​，然后就会执行我们脚本文件中的内容，先是打包，然后将打包产物推送到远程指定分支（static-pages）。我们可以到github仓库中查看打包产物。

部署完我们怎么访问这个页面呢？

在仓库的​​Setting -> Pages​​中可以查看到该页面的访问地址

最后我们访问这个地址​​bettersong.github.io/nanjiu/就能看到…​​

这种方案最后再与​​GitHooks​​结合，可以在某个分支提交时自动完成打包部署，这里就不再介绍了。下面我们再来看另一种更加优雅的方案。

CICD

CICD翻译过来就是持续构建、持续交付。

CI 持续集成（Continuous Integration）

持续集成：频繁的将代码合并到主分支中，强调通过集成测试反馈给开发一个结果，不管失败还是成功。

持续集成分成三个阶段：

• 持续集成准备阶段：根据软件开发的需要，准备CI的一些前置工作

• 集成CI工具的代码仓库（Gitlab、Github、Jenkins等）
• 单元测试或者集成测试的脚本
• 触发CI的配置文件，实现各种功能的Jobs

• 持续集成进行阶段

• 推送代码出发CI系统
• 通过CI系统监听代码的测试、构建，反馈集成结果
• 通过版本管理系统实现版本的管理

• 接续集成完成阶段：反馈集成结果

CD 持续交付（Continuous Delivery）

持续交付：主要面向测试人员和产品，可以保证一键部署，常常要交付的内容包括

• 源代码：缺点，代码依赖的环境不容易控制
• 打包的二进制文件或者系统包：存在兼容性问题和环境差异出现的部署失败
• 虚拟机镜像交付：系统隔离最好，但占用系统资源严重
• Docker交付：容器交付，成本最低，兼容性最好

持续部署：此时要提供一个稳定的版本，包括所需的环境和依赖，主要面向用户提供服务，发生错误要能快速回滚。

CICD是目前大多数互联网公司选择的一种部署方案，因为它能够灵活配置项目部署过程中的各个阶段。下面再来介绍下如何使用GitHub的CICD来部署前端项目。

GitHub Action

​​GitHub Actions​​​ 是一个持续集成 (Continuous integration)和持续交付 (Continuous delivery)的平台，它可以做到自动化构建、测试、部署。你可以创建工作流，构建和测试每一个 ​​pull request​​ 或者部署合并后的代码到生产环境。

Workflows(工作流)

工作流是一个可配置的自动化的程序。创建一个工作流，你需要定义一个 YAML 文件，当你的仓库触发某个事件的时候，工作流就会运行，当然也可以手动触发，或者定义一个时间表。一个仓库可以创建多个工作流，每一个工作流都可以执行不同的步骤。

Events(事件)

事件是指仓库触发运行工作流的具体的行为，比如创建一个 ​​pull request​​​、新建一个 ​​issue​​​、或者推送一个 ​​commit​​。你也可以使用时间表触发一个工作流，或者通过请求一个 REST API，再或者手动触发。

Jobs(任务)

任务是在同一个运行器上执行的一组步骤。一个步骤要么是一个shell 脚本要么是一个动作。步骤会顺序执行，并彼此独立。因为每一个步骤都在同一个运行器上被执行，所以你可以从一个步骤传递数据到另一个步骤 。

你可以配置一个任务依赖其他任务，默认情况下，任务没有依赖，并行执行。当一个任务需要另外一个任务的时候，它会等到依赖的任务完成再执行。

Actions(动作)

动作是 ​​GitHub Actions​​ 平台的一个自定义的应用，它会执行一个复杂但是需要频繁重复的作业。使用动作可以减少重复代码。比如一个 action 可以实现从 GitHub 拉取你的 git 仓库，为你的构建环境创建合适的工具链等。你可以写自己的动作 ，或者在 GitHub 市场找已经实现好的动作。

Runners(运行器)

一个运行器是一个可以运行工作流的服务。每一个运行器一次只运行一个单独的任务。GitHub 提供 Ubuntu Linux，Microsoft Windows 和 macOS 运行器，每一个工作流都运行在一个独立新建的虚拟机中。如果你需要一个不同的操作系统，你可以自定义运行器。

了解完上面这些有关​​GitHub Actions​​的概念，我们开始搭建一条自己的工作流用于项目的部署。

搭建工作流

.github/workflows

我们在之前建好的仓库中点击​​New workflow​​来新建一条工作流。

然后会到选择工作流的页面

这里你可以选择一条别人建好的工作流，也可以选择新建自己的工作流。

我们还是选择新建自己的工作流，然后会在我们项目的根目录下新建一个目录​​.github/workflows​​​，这里会新建一个yml文件，我们这里就叫​​ci.yml​​好了

yml

在这个文件中，我们要做的事情还是打包以及部署

name: Build and Deploy
on: # 监听 main 分支上的 push 事件
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest # 构建环境使用 ubuntu
    steps:
      - name: Checkout  # 将代码拉到虚拟机
        uses: actions/[email protected]
        with:
          persist-credentials: false

      - name: Install and Build # 下载依赖 打包项目
        run: |
          npm install
          npm run build

      - name: Deploy 

标签：集成,GitHub,工作,部署,Actions,一个,自动化,打包	

From： https://blog.51cto.com/u_13756259/5848573