使用GitHub Actions实现自动化部署( 二 )

CD 持续交付(Continuous Delivery)持续交付:主要面向测试人员和产品,可以保证一键部署,常常要交付的内容包括

  • 源代码:缺点,代码依赖的环境不容易控制
  • 打包的二进制文件或者系统包:存在兼容性问题和环境差异出现的部署失败
  • 虚拟机镜像交付:系统隔离最好,但占用系统资源严重
  • Docker交付:容器交付,成本最低,兼容性最好
持续部署:此时要提供一个稳定的版本,包括所需的环境和依赖,主要面向用户提供服务,发生错误要能快速回滚 。
CICD是目前大多数互联网公司选择的一种部署方案,因为它能够灵活配置项目部署过程中的各个阶段 。下面再来介绍下如何使用GitHub的CICD来部署前端项目 。
GitHub ActionGitHub Actions 是一个持续集成 (Continuous integration)和持续交付 (Continuous delivery)的平台,它可以做到自动化构建、测试、部署 。你可以创建工作流,构建和测试每一个 pull request 或者部署合并后的代码到生产环境 。
使用GitHub Actions实现自动化部署

文章插图
Workflows(工作流)工作流是一个可配置的自动化的程序 。创建一个工作流,你需要定义一个 YAML 文件,当你的仓库触发某个事件的时候,工作流就会运行,当然也可以手动触发,或者定义一个时间表 。一个仓库可以创建多个工作流,每一个工作流都可以执行不同的步骤 。
使用GitHub Actions实现自动化部署

文章插图
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 Actions实现自动化部署

文章插图
然后会到选择工作流的页面
使用GitHub Actions实现自动化部署

文章插图
这里你可以选择一条别人建好的工作流,也可以选择新建自己的工作流 。
我们还是选择新建自己的工作流,然后会在我们项目的根目录下新建一个目录.github/workflows,这里会新建一个yml文件,我们这里就叫

经验总结扩展阅读