前言每个人在工作中都必须通过自动化部署来部署前端项目，也就是当我们开发出某个需求后，只需要将代码推送到某个分支即可。然后就可以自动完成部署了。一般情况下，我们不需要关心项目是如何构建的，如何部署的，大大提高了我们的开发效率。在没有自动化部署的情况下，前端项目的部署流程一般如下：（手动部署）开发完成后在本地构建，将构建好的文件交给运维（前端人员有权限可省略）上传打包文件到服务器指定目录，前端项目每次上线都要经过这个过程。对于程序员来说，这是难以忍受的。他们宁愿把时间浪费在B上，也不愿浪费在这些不熟练的工作流程上，人工操作难免出错。那么今天就来给大家分享下如何自动化部署自己的前端项目。自动化部署脚本先分享一个简单的自动化部署方案——自动化部署脚本我们每次部署一个项目，都有几个步骤是固定的。既然是固定的，那么我们就可以编写脚本来帮我们完成，这样既可以提高我们的开发效率，也可以避免手动操作时可能出现的错误。新建一个仓库我们可以在GitHub上新建一个项目，尝试部署到GitHubPages上。新建一个项目这里我们新建一个Vue3+TS项目来添加脚本我们直接在项目根目录下新建一个脚本文件deploy.sh#!/usr/bin/envshset-x#这里是看错误日志#打包项目npmrunbuild#进入打包文件夹cddistgitinitgitadd-Agitcommit-m'autodeploy'#推送打包文件到指定分支gitpush-fhttps://github.com/bettersong/nanjiu.gitmain:static-pages执行脚本现在我们可以执行shdeploy.sh，然后执行我们脚本文件中的内容，先打包，然后将打包好的产品推送到远程指定的分支（static-pages）。我们可以去github仓库查看打包后的产品。部署后我们如何访问这个页面？可以在仓库的设置->页面中查看该页面的访问地址。最后，我们可以访问这个地址https://bettersong.github.io/nanjiu/来查看我们部署上去的页面。最后，该方案结合GitHooks，可以在提交分支时自动完成打包部署，这里不再介绍。让我们看看另一个更优雅的解决方案。CICDCICD的翻译意思是持续建设和持续交付。CI持续集成（ContinuousIntegration）：经常将代码合并到主分支，强调集成测试反馈给开发一个结果，无论失败还是成功。持续集成分为三个阶段：持续集成准备阶段：根据软件开发的需要，为CI准备一些前期工作集成CI工具（Gitlab、Github、Jenkins等）的代码仓库单元测试或集成测试脚本触发CI配置Files、Jobs实现各种功能持续集成阶段推送代码启动CI系统通过CI系统监控代码测试和构建，反馈集成结果通过版本管理系统实现版本管理持续集成完成阶段：反馈集成结果CD持续交付(ContinuousDelivery)持续交付：主要针对测试人员和产品，可以保证一键部署，往往要交付的内容包括源代码：缺点，代码依赖的环境不容易控制打包的二进制文件或系统包：存在兼容性问题和Deployment环境差异导致失败虚拟机镜像交付：系统隔离最好，但占用系统资源严重Docker交付：容器交付，成本最低，兼容性最好持续部署：此时提供稳定版本，包括所需的环境和依赖项主要是为用户提供服务，需要在出错时能够快速回滚。CICD是目前大多数互联网公司选择的部署方案，因为它可以灵活配置项目部署过程中的各个阶段。下面介绍一下如何使用GitHub的CICD部署前端项目。GitHubActionGitHubActions是一个持续集成（Continuousintegration）和持续交付（Continuousdelivery）平台，可以自动化构建、测试和部署。您可以创建工作流来构建和测试每个拉取请求或将合并的代码部署到生产环境中。工作流（Workflow）工作流是一个可配置的自动化程序。要创建工作流，您需要定义一个YAML文件。当您的仓库触发某个事件时，工作流将运行。当然也可以手动触发，或者定义一个时间表。一个仓库可以创建多个工作流，每个工作流可以执行不同的步骤。Events（事件）事件是指仓库触发工作流运行的特定行为，例如创建拉取请求、创建新问题或推送提交。您还可以使用计划、通过请求RESTAPI或手动触发工作流。作业（任务）作业是在同一个运行器上执行的一组步骤。步骤是shell脚本或操作。步骤按顺序执行且彼此独立。因为每个步骤都在同一个运行器上执行，所以您可以将数据从一个步骤传递到另一个步骤。您可以将任务配置为依赖于其他任务。默认情况下，任务没有依赖关系并且并行执行。当一个任务需要另一个任务时，它会等到依赖任务完成后再执行它。Actions是GitHubActions平台的自定义应用程序，可执行复杂但经常重复的工作。可以通过使用操作来减少重复代码。例如，一个操作可以从GitHub拉取你的git存储库，为你的构建环境创建一个合适的工具链，等等。您可以编写自己的操作，或在GitHub市场中查找已实施的操作。运行器（runner）运行器是一种可以运行工作流的服务。每个跑步者一次只运行一个任务。GitHub提供了UbuntuLinux、MicrosoftWindows和macOS运行器，每个工作流都运行在一个单独的新创建的虚拟机中。如果您需要不同的操作系统，您可以自定义运行器。在了解了以上关于GitHubActions的概念后，我们开始构建自己的项目部署工作流。构建工作流.github/workflows我们在之前构建的仓库中点击Newworkflow，创建一个新的工作流。然后你会进入选择工作流的页面，在这里你可以选择别人创建的工作流，也可以选择创建自己的工作流。我们还是选择创建自己的workflow，然后在我们项目的根目录下新建一个目录.github/workflows，在这个目录下新建一个yml文件，这里我们称之为ci.yml。要做的就是打包部署name:BuildandDeployon:#在主分支上监听推送事件push:branches:-mainjobs:build-and-deploy:runs-on:ubuntu-latest#使用ubuntu搭建环境步骤：-name:Checkout#拉取代码到虚拟机uses:actions/checkout@v2.3.1with:persist-credentials:false-name:InstallandBuild#下载依赖打包项目run:|npminstallnpmrunbuild-名称：Deploy
