DAG总览 / 组目录 / 自动化部署

自动化部署:GitHub Actions(动作)

G05Layer 7
目录:前置概念账号与仓库版本管理协作项目管理自动化部署工具生态
层导航:L0L1L2L3L4L5L6L7 当前L8
上游 · 理解本功能前需先掌握的(2):
下游 · 依赖/承接本功能的(1):
前置依赖包含从属概念升级流程承接 边方向 = 学习顺序(A→B 表示先学 A 再学 B)

为什么需要它

心智模型

每次提交代码后,都要手动跑测试、打包、传到服务器,麻烦又容易漏。Actions 就像一个自动流水线,只要仓库里发生某件事(比如有人提交代码),它就自动替你干完这些重复的活,你只管睡觉,醒来代码已经发布好了。

历史背景 · 它为什么诞生诞生于 2018
诞生2018年前CI/CD市场碎片化:Travis CI、CircleCI、Jenkins等第三方服务各自为政,开发者需在GitHub与外部CI间反复切换。GitHub作为代码托管中心想提供内置的构建、打包、发布、部署一体化能力。2018-10-16以limited public beta发布,强调用容器连接软件工作流。
演进从2018年beta的容器化工作流理念,演进为2019-11-11 GA的YAML声明式workflow,存放在仓库.github/workflows目录中随代码版本化。2020年后加入marketplace可复用action生态、托管runner、复用workflow,从纯CI/CD扩展为通用自动化平台。
历史教训
平台化产品取胜的关键是"把工作流放进代码仓库版本化"——配置即代码让CI/CD可审查、可回滚、可协作。紧贴已有托管场景(代码仓库)顺势做一体化,比另起炉灶做独立CI产品阻力小。

功能介绍

GitHub Actions 是 GitHub 官方的持续集成和持续交付(CI/CD)平台,官方定义是 "a continuous integration and continuous delivery (CI/CD) platform"。它的核心思路是:当仓库里发生某个事件(Event)——例如拉取请求(Pull Request)被打开、或 Issue 被创建——就自动触发一段或多段任务。这些任务写在一个叫工作流(Workflow)的 YAML 文件里,放在仓库的 .github/workflows 目录下。一个工作流由若干作业(Job)组成,作业里又包含若干步骤(Step),每个步骤调用一个动作(Action),由运行器(Runner)在云端机器上实际执行。你不需要买服务器,Actions 自带免费运行机器。常见用法包括:代码推送后自动运行测试、自动构建、自动部署网站或发布软件包。

核心术语

持续集成(Continuous Integration,CI)持续交付(Continuous Delivery,CD)工作流(Workflow)作业(Job)步骤(Step)动作(Action)运行器(Runner)事件(Event)YAML

适用场景

怎么操作(网页 vs 命令行 双轨)

🖱️ 网页操作 (GitHub.com)
  • 进入仓库,点击顶部 Actions 标签页,你会看到已配置的工作流列表
  • 点击某个工作流运行记录,可查看每个作业(Job)和步骤(Step)的执行日志
  • 点击页面右上角 New workflow,可选用官方模板或自定义创建 workflow 文件
⌨️ 命令行 (进阶)
  • `gh workflow list` # 查看仓库中已配置的工作流
  • `gh workflow run <workflow_name> --ref main` # 手动触发一个工作流
  • `gh run list` # 查看最近的运行记录
  • `gh run watch <run_id>` # 实时查看某次运行的日志

新手建议先从网页操作入手,熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。

与其他功能的关系

关系(前置依赖 / 包含从属 / 概念升级 / 流程承接)说明
前置依赖创建仓库(Create Repository)Actions workflow 在仓库中运行,先有仓库
流程承接拉取请求(Pull Request)PR 事件触发 CI 检查,先懂 PR 再理解自动化触发
流程承接软件包托管:GitHub Packages(软件包)用 Actions workflow 自动发布包到 Packages

官方文档

小结

SUMMARY

GitHub Actions 用 YAML 工作流把「构建、测试、部署」变成自动流水线,事件触发、云端 Runner 执行,零维护服务器。下一步:从仓库 Actions 页面的模板开始,创建你的第一个工作流。