CI/CD 与 GitHub Actions

这一课你将能做到

1. 用自己的话区分 CI（持续集成） 与 CD（持续交付/部署），并指出「PR 上的红绿检查」与「新版本上线」各属于哪一边
2. 画出本站 monorepo 的理想流水线：push/PR → 并行测 backend 与 platform → 构建 Docker 镜像 → 推 GHCR →（可选）更新部署声明
3. 打开任意仓库的 Actions 页，指出一次 run 的触发事件、包含哪些 job，以及成功/失败状态在哪里看

为什么要学

本地能 mvn test、能 npm run build，不等于合并进 main 之后别人拉下来还能绿。人会忘装依赖、会漏改环境变量、会躲在「我机器上能跑」里自我安慰。

CI 把「能不能构建、能不能测过」固定成仓库里的自动检查；CD 再把「可发布的产物」送到环境。GitHub 托管代码时，GitHub Actions 与仓库同域：改 YAML 就是改流水线，走同一套 PR review。

本站是典型 monorepo：backend/（Maven + Spring Boot）与 platform/（npm + Next.js）各有一套构建。只有统一门禁——两边都绿——合并才安全；一边绿一边红就合并，等于在 main 埋雷。

面试视角：CI/CD 是后端与 DevOps 岗位的高频考点，从「CI 是什么」到「你们的流水线怎么设计」几乎必问。这一课给你的不是名词背诵，而是能用本站例子讲清楚的答案。

先建立图像

开发者 push / 开 PR
        │
        ▼
  GitHub Actions（仓库里的「自动工头」）
        │
        ├─ CI：lint / test / build（backend + platform 并行）
        │      → PR 上出现红叉或绿勾
        │
        └─ CD（可选）：打 Docker 镜像 → 推 GHCR
               → 更新 deploy/env/prod 里的 image.tag
               → 集群内控制器（如 Argo CD）或人工发布

人话：Actions 像仓库门口的质检流水线。每次有人送货（提交），机器按清单检查；检查不过，门卫不让进 main。CD 则是质检通过后，把合格品送上货架（环境）。

	CI	CD
目标	每次提交可构建、可测	可发布到某一环境
典型步骤	lint、单元测、mvn verify、next build	推镜像、改 values、SSH 拷贝
反馈形态	PR 检查红/绿	新版本号/tag 出现在集群或服务器
失败时	挡住合并（配合分支保护）	回滚 tag 或停止发布

跟着做

步骤 1：看懂官方定义并转成自己的话

打开官方文档首页读一遍「Actions 是什么」，合上页面用自己的话写一句：

Actions 是 GitHub 内置的 CI/CD 平台，用仓库里的 YAML 描述自动化任务，runner 按任务执行。

再补一句本课立场：本站用它给 monorepo 做质量门禁与镜像构建，业务逻辑仍在 Spring Boot 与 Next.js 里。官方文档强调的是 workflow、job、step、runner 四个名词——这正是后面几课的骨架。

步骤 2：打开任意仓库的 Actions 页

选一个你熟悉的开源仓库（或本站仓库）→ 顶栏 Actions。点开最近一次 run，记录三件事：

• 触发事件（push / pull_request / workflow_dispatch）
• 有几个 job，哪些并行
• 某个 step 的耗时与日志末尾几行

笔记写：「一次 run = 一次触发下的全部 job 执行记录。」

步骤 3：理解一次 run 的生命周期

Queued（排队等 runner）
  → In progress（正在跑 steps）
  → Success / Failure / Cancelled

run 详情页里每个 job 独立计时——这暗示 job 之间是独立机器（第三课展开）。排错时永远从「最早变红的那一步」看起，而不是从日志最后几行倒着猜。

步骤 4：画出本站流水线愿景

把下面的图抄进笔记，并标注本 track 每一课对应哪一段：

push/PR
  → 测 backend（setup-java → ./mvnw verify）       ← 第 7 课
  → 测 platform（npm ci → lint → test → build）    ← 第 8 课
  → 构建 Docker 镜像并推 GHCR                      ← 第 9 课
  → （部署）更新 image.tag / SSH 发布              ← 第 10 课

应看到：CI 先于 CD，绿了再谈上线。

步骤 5：区分「本机脚本」与「CI」

本机也能写脚本重复跑测试，但 CI 额外提供三样东西：

• 干净环境：每次新 runner，消灭「我本机有缓存所以过了」
• 与 PR 状态绑定：检查结果成为合并门禁，不只是日志
• 审计与日志：谁在哪个 commit 触发、每步耗时、历史可查

口头发一句：本地脚本是练习场，Actions 是仓库的公共门禁。

步骤 6：写下本课边界

在笔记写三行「本课不讲」：

1. 不写完整 ci.yml（下一课）
2. 不配 secrets / 分支保护（第 5、11 课）
3. CI 只负责跑测试，不教你怎么写好测试——那是 testing 轨道的事

讲清楚要点

1. 因为合并后修复成本远高于 PR 阶段，所以用 CI 在合并前自动跑构建与测试——把「能不能绿」变成可观察的检查项。
2. 因为「测过」不等于「交付了」，所以 CD 负责把产物放到环境——镜像 tag、部署声明、SSH 拷贝都是 CD 手段。
3. 因为仓库在 GitHub，所以优先用 Actions——与 PR、权限、GHCR 同一账号体系，省掉自维护 Jenkins 的成本。
4. 因为本站是 monorepo，所以 CI 要同时覆盖 backend/ 与 platform/——只测一边等于半扇门敞开。
5. 因为流水线也是代码，所以 workflow YAML 应走 PR review——改触发器、改 secrets 引用、改部署步骤，都和业务代码一样要人审。
6. 因为工具会换、概念不会换，所以先记住「触发 → 干净环境 → 步骤 → 产物/状态」这条抽象链——以后换 GitLab CI 只换语法，不换脑中模型。

你可能会懵的地方

1. 「CI/CD 是不是同一个东西？」 口语常连说。严格说 CI 偏质量门禁，CD 偏发布。很多仓库一个 workflow 里既有 test job 又有 deploy job——文件名叫 CI 也常见，看 job 意图即可。

2. 「没有 K8s 是不是不用学 Actions？」 不是。单机 VPS 上「PR 必须测过再合并」仍然极有价值。CD 可以是拷 JAR、也可以是 GitOps；CI 几乎总是值得先做。

3. 「Actions 分钟数会不会很贵？」 公开仓库有免费额度；私有仓库按计划计费。后面会用 paths 过滤、缓存依赖控制耗时。先保证测对，再优化测快。

4. 「和本机 Docker Compose 什么关系？」 Compose 多用于本机/单机编排；Actions 跑在 GitHub 托管的 runner（或自建 runner）上。二者可配合：CI 里 docker build 推镜像，生产用 Compose 或 K8s 拉镜像。

5. 「Jenkins 老了吗？还要学吗？」 Jenkins 仍大量存在于存量系统，面试常拿它对比。学Actions 时不亏：把 job/step/触发器的概念学扎实，迁移到任何 CI 工具都只是学语法。

错法对照

错法	问题	正解
只靠本机测，从不开 CI	别人环境一变就炸；PR 无公共红绿	仓库加 workflow，PR 必跑
把 CD 当 CI：main 一 push 就直推生产且无测	坏构建直接上线	先 CI 绿，再受控发布（审批/GitOps）
只测 frontend，假设 backend「我跑过」	monorepo 半边门禁失效	backend + platform 并行覆盖
流水线只存在于某个人笔记本脚本里	不可审计、难交接	YAML 进 .github/workflows/，跟 Git 走

卡点急救

1. 仓库看不到 Actions 页签：仓库 Settings → Actions → General 里可能被禁用了 Actions，选「Allow all actions」或按组织策略放开；fork 仓库默认关闭，需手动启用。
2. push 了但没出现 run：先查文件是否真的在 .github/workflows/ 下（第三课前的头号坑），再查 on 里写的分支名与实际 push 的分支是否一致（main vs master），最后确认文件已被 push 到远端而不是只存在本地。
3. run 排队很久不开始：Queued 状态说明在等 runner。免费公开仓库通常几十秒内分配；私有仓库额度用尽会一直排队。查 Settings → Billing 里 included minutes 是否耗尽。

面试常问

• CI 和 CD 的区别是什么？ CI 关注每次提交后自动构建、测试，尽快暴露集成问题，反馈是 PR 红绿；CD 关注把通过验证的产物（如 Docker 镜像）交付到环境，可以是持续交付（到 staging 人工确认）或持续部署（自动上线）。我会结合本站例子：PR 上跑 Maven verify 与 Next build 是 CI；镜像推 GHCR 后更新 image.tag 发布是 CD。

• 一条 CI 流水线通常包含哪些阶段？ 典型阶段：拉代码（checkout）→ 安装依赖（npm ci / Maven 解析）→ 静态检查（lint）→ 编译与单元测试 → 构建（打 JAR / next build）→ 打包产物（Docker 镜像）→（可选）安全扫描。顺序上「便宜的检查放前面，贵的放后面」，lint 秒级失败就不浪费后面几分钟的构建时间。

• 为什么选 GitHub Actions 而不是 Jenkins？ Actions 与 GitHub 仓库同域：YAML 进仓库走 review、托管 runner 免运维、与 GHCR/PR 权限一体，适合中小团队快速起步；Jenkins 优势在高度可定制插件生态与内网环境，但要自己维护控制器与节点。选型结论：仓库在 GitHub、团队小、流水线标准化程度高，用 Actions；已有 Jenkins 资产或强内网隔离需求，才考虑自建。

自测三问

1. 用两句话区分 CI 与 CD，并各举本站会做的一步。
2. 为什么 CodeRoadMap 这种 monorepo 不能只跑 npm test？
3. Actions 与 Jenkins 在「概念层」相同的是什么？不同的是什么？

小结一句话

CI 保每次提交可验证，CD 保可交付；GitHub Actions 是本站仓库的原生自动工头。

延伸

• Understanding GitHub Actions
• About continuous integration
• 下一课：Workflow 文件结构——把「自动工头」的说明书真正写进 .github/workflows/。