前言大家在工作中想必都是通过自动化部署来进行前端项目的部署的，也就是我们在开发完某个需求时，我们只需要将代码推送到某个分支，然后就能自动完成部署，我们一般不用关心项目是如何build以及如何deploy的，这就极大得提高了我们的开发效率 。
在没有自动化部署的情况下 ， 前端项目的部署流程一般是这样的：（手动部署）
- 开发完成后本地进行build
- 将build后的文件交给运维（前端人员有权限的可省略）
- 将打包文件上传到服务器的指定目录
所以今天给大家分享一下如何实现自动化部署自己的前端项目 。
如果这篇文章有帮助到你 ， ?关注+点赞?鼓励一下作者，文章公众号首发，关注
前端南玖 第一时间获取最新文章～自动化部署脚本【使用GitHub Actions实现自动化部署】先来分享一种简单的自动化部署方案 - 自动化部署脚本
我们每次部署项目时，会有几个步骤是固定的，既然它是固定的，那么我们就可以通过写脚本来帮助我们完成 ， 这样不仅能够提高我们的开发效率，还能避免人为操作时可能出现的纰漏 。
新建仓库我们可以在GitHub上新建一个项目并尝试把它部署到GitHub Pages上 。
文章插图
新建项目这里我们新建一个Vue3 + TS 项目
文章插图
添加脚本我们直接在项目根目录下新建一个脚本文件
deploy.sh#!/usr/bin/env shset -x# 这里是为了看错误日志# 打包项目npm run build# 进入打包后的文件夹cd distgit initgit add -Agit 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
CICD翻译过来就是持续构建、持续交付 。CI 持续集成（Continuous Integration）持续集成：频繁的将代码合并到主分支中 ， 强调通过集成测试反馈给开发一个结果，不管失败还是成功 。
持续集成分成三个阶段：
- 持续集成准备阶段：根据软件开发的需要，准备CI的一些前置工作
- 集成CI工具的代码仓库（Gitlab、Github、Jenkins等）
- 单元测试或者集成测试的脚本
- 触发CI的配置文件，实现各种功能的Jobs
- 持续集成进行阶段
- 推送代码出发CI系统
- 通过CI系统监听代码的测试、构建 ， 反馈集成结果
- 通过版本管理系统实现版本的管理
- 接续集成完成阶段：反馈集成结果
- 源代码：缺点 ， 代码依赖的环境不容易控制
- 打包的二进制文件或者系统包：存在兼容性问题和环境差异出现的部署失败
- 虚拟机镜像交付：系统隔离最好，但占用系统资源严重
- Docker交付：容器交付，成本最低，兼容性最好
CICD是目前大多数互联网公司选择的一种部署方案，因为它能够灵活配置项目部署过程中的各个阶段 。下面再来介绍下如何使用GitHub的CICD来部署前端项目 。
GitHub Action
GitHub Actions
推荐阅读
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Vue前端框架基础+Element的使用
- 手记系列之二 ----- 关于IDEA的一些使用方法经验
- k8s 中的 ingress 使用细节
- 在 .NET 7上使用 WASM 和 WASI
- Spring Boot 中使用 Swagger
- 迪奥小A瓶精华使用方法_迪奥小A瓶使用顺序
- Long Transactions 长事务
- ThreadLocal的使用及原理解析
- php注解使用示例
- netty系列之: 在netty中使用 tls 协议请求 DNS 服务器
