1. 课程导入与CI/CD全景

在开始学习 GitHub Actions 之前，先把三个容易混淆的概念摆清楚：持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）。它们共享同一套自动化基础，但“自动化到哪一步”决定了团队的工作方式。

持续集成关注的是“代码合入主干”这件事。开发者把改动推送到共享分支或发起 Pull Request 时，自动触发构建与测试，尽早发现编译错误、单元测试失败、依赖冲突等问题。它的核心价值是缩短反馈周期：问题在提交后几分钟内暴露，而不是在发布前夜集中爆发。

持续交付在 CI 的基础上再往前一步：每次通过验证的构建产物都被打包、版本化，并部署到一个类生产环境（如 staging），随时可以由人工决定是否发布到生产。也就是说，持续交付保证“软件始终处于可发布状态”，但发布动作仍保留人工审批。

持续部署则把最后的人工审批也去掉：只要流水线全部通过，构建产物就自动发布到生产环境。它要求极高的测试覆盖率、可观测性和回滚能力，否则一次误提交就可能直接影响线上用户。

理解这三者的递进关系，可以用一条“代码到用户”的链路来观察：代码提交 → 触发流水线 → 构建与测试 → 产物归档 → 部署到环境 → 用户可用。CI 覆盖前段，持续交付覆盖到“可发布”，持续部署覆盖到“已发布”。下面这张图把这条链路和三种模式的边界放在一起对照。

把这条链路映射到 GitHub Actions，就能看清它的定位：GitHub Actions 是 GitHub 原生的自动化平台，用 YAML 描述工作流（workflow），由仓库事件（push、pull_request、schedule、release 等）触发，在 GitHub 托管的 runner 或自托管 runner 上执行 job 与 step。它把“代码托管”和“自动化执行”放在同一个平台里，不需要额外搭建 Jenkins 之类的独立服务，也不需要维护 Webhook 转发。

它的典型优势可以归纳为四点。第一，与仓库深度集成：权限、Secrets、环境、PR 状态检查都在 GitHub 内闭环，PR 页面直接显示检查结果。第二，事件驱动：几乎任何仓库事件都能作为触发器，天然适合“提交即验证”的 CI 场景。第三，生态丰富：Marketplace 提供大量现成 action，如 actions/checkout、actions/setup-node、actions/upload-artifact，减少重复脚本。第四，矩阵与复用：matrix 可一次跑多版本、多系统组合，reusable workflow 和 composite action 支持跨仓库复用。

典型应用场景包括：PR 门禁（lint + 单元测试 + 构建）、多平台构建矩阵、自动发布 npm 包或 Docker 镜像、定时任务（如每日依赖扫描）、以及部署到云环境（AWS、Azure、Vercel 等）。这些场景的共同点是“由仓库事件驱动、需要可重复执行、结果需要可追溯”。

本课程的学习路径按“先跑通、再工程化、后治理”组织。第一阶段建立最小可用流水线：理解 workflow / job / step / runner 四个基本概念，写出第一个在 push 时运行的 YAML。第二阶段补齐工程能力：缓存依赖、矩阵构建、Secrets 管理、环境与审批、制品归档。第三阶段进入发布与治理：版本策略、回滚、权限最小化、成本与并发控制、可观测性。实战目标是在课程结束时，你能为一个真实仓库交付一条从提交到部署的完整流水线，并知道每个环节失败时如何定位。