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，记录三件事：