大家在工作中想必都是通过自动化部署来进行前端项目的部署的,也就是我们在开发完某个需求时,我们只需要将代码推送到某个分支,然后就能自动完成部署,我们一般不用关心项目是如何build以及如何deploy的,这就极大得提高了我们的开发效率。
在没有自动化部署的情况下,前端项目的部署流程一般是这样的:(手动部署)
前端项目每次上线都得走一遍这个流程,对于程序员来讲这怎么能忍,宁愿将时间浪费在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
中可以查看到该页面的访问地址
最后我们访问这个地址https://bettersong.github.io/nanjiu/就能看到我们部署的页面了。
这种方案最后再与GitHooks
结合,可以在某个分支提交时自动完成打包部署,这里就不再介绍了。下面我们再来看另一种更加优雅的方案。
CICD翻译过来就是持续构建、持续交付。
持续集成:频繁的将代码合并到主分支中,强调通过集成测试反馈给开发一个结果,不管失败还是成功。
持续集成分成三个阶段:
持续集成准备阶段:根据软件开发的需要,准备CI的一些前置工作
持续集成进行阶段
接续集成完成阶段:反馈集成结果
持续交付:主要面向测试人员和产品,可以保证一键部署,常常要交付的内容包括
持续部署:此时要提供一个稳定的版本,包括所需的环境和依赖,主要面向用户提供服务,发生错误要能快速回滚。
CICD是目前大多数互联网公司选择的一种部署方案,因为它能够灵活配置项目部署过程中的各个阶段。下面再来介绍下如何使用GitHub的CICD来部署前端项目。
GitHub Actions
是一个持续集成 (Continuous integration)和持续交付 (Continuous delivery)的平台,它可以做到自动化构建、测试、部署。你可以创建工作流,构建和测试每一个 pull request
或者部署合并后的代码到生产环境。
工作流是一个可配置的自动化的程序。创建一个工作流,你需要定义一个 YAML 文件,当你的仓库触发某个事件的时候,工作流就会运行,当然也可以手动触发,或者定义一个时间表。一个仓库可以创建多个工作流,每一个工作流都可以执行不同的步骤。
事件是指仓库触发运行工作流的具体的行为,比如创建一个 pull request
、新建一个 issue
、或者推送一个 commit
。你也可以使用时间表触发一个工作流,或者通过请求一个 REST API,再或者手动触发。
任务是在同一个运行器上执行的一组步骤。一个步骤要么是一个shell 脚本要么是一个动作。步骤会顺序执行,并彼此独立。因为每一个步骤都在同一个运行器上被执行,所以你可以从一个步骤传递数据到另一个步骤 。
你可以配置一个任务依赖其他任务,默认情况下,任务没有依赖,并行执行。当一个任务需要另外一个任务的时候,它会等到依赖的任务完成再执行。
动作是 GitHub Actions
平台的一个自定义的应用,它会执行一个复杂但是需要频繁重复的作业。使用动作可以减少重复代码。比如一个 action 可以实现从 GitHub 拉取你的 git 仓库,为你的构建环境创建合适的工具链等。你可以写自己的动作 ,或者在 GitHub 市场找已经实现好的动作。
一个运行器是一个可以运行工作流的服务。每一个运行器一次只运行一个单独的任务。GitHub 提供 Ubuntu Linux,Microsoft Windows 和 macOS 运行器,每一个工作流都运行在一个独立新建的虚拟机中。如果你需要一个不同的操作系统,你可以自定义运行器。
了解完上面这些有关GitHub Actions
的概念,我们开始搭建一条自己的工作流用于项目的部署。
我们在之前建好的仓库中点击New workflow
来新建一条工作流。
然后会到选择工作流的页面
这里你可以选择一条别人建好的工作流,也可以选择新建自己的工作流。
我们还是选择新建自己的工作流,然后会在我们项目的根目录下新建一个目录.github/workflows
,这里会新建一个yml文件,我们这里就叫ci.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/checkout@v2.3.1
with:
persist-credentials: false
- name: Install and Build # 下载依赖 打包项目
run: |
npm install
npm run build
- name: Deploy # 部署
uses: JamesIves/github-pages-deploy-action@v4.3.3
with:
branch: static-pages # 部署后提交到的分支
folder: dist # 这里填打包好的目录名称
我们把这个文件提交上去,它就会在提交代码后自己完成打包及部署的工作。
在代码提交上去后,它会按照我们工作流的步骤进行打包及部署
并且上面可以查看整个工作流的日志,方便排查问题
部署完访问地址还是一样https://bettersong.github.io/nanjiu
到这里我们基于GitHub Actions
实现的自动化部署流程就完成了,现在我们在本地修改完代码后就只需要将代码推送到远程,就能够实现自动打包部署了。
喜欢的同学欢迎点个赞呀~
我是南玖,我们下期见!!!
手机扫一扫
移动阅读更方便
你可能感兴趣的文章