交付：CI/CD、供应链与基础设施

登录后可在不同设备间同步进度。在此之前，进度只保存在当前浏览器中。

为什么重要

AI 让你能写出十倍的变更。如果没有一条自动化、安全的上线路径，这就会变成十倍的事故。DORA 的研究结论很明确：速度和稳定性并不矛盾。最好的团队部署得更频繁，同时故障更少，因为每次变更都很小、经过测试、可以回退。

学习目标

1. 搭建带有质量和安全关卡的 CI/CD 流水线。
2. 用 Docker 实现可复现的容器化。
3. 保护软件供应链（lockfile、SBOM、来源证明、slopsquatting）。
4. 用 feature flag、滚动发布、canary 和蓝绿部署做渐进式发布。
5. 在一分钟内完成 rollback。
6. 用代码定义基础设施。
7. 知道什么时候该用（以及什么时候不该用）Kubernetes。

课程内容

11.1 流水线（6, 107）

每个 pull request：安装依赖（按 lockfile）→ lint → 类型检查 → 单元测试 → 集成测试（在容器里跑真实数据库）→ 安全扫描（密钥、SAST、依赖）→ 构建 → 预览环境部署 → 在预览环境上跑 E2E 测试。 合并到 main 时：只构建一次，把同一个构建产物先部署到 staging 再部署到 production，把数据库迁移作为受控步骤执行，跑冒烟测试，持续监控。

• 分支保护：必须经过评审并通过检查；任何人（包括任何 agent）都不能直接推送到 main。
• 构建缓存（107） 让 CI 保持快速（依赖缓存和镜像层缓存，monorepo 中使用远程缓存）。CI 一慢，大家就会想办法跳过它。

11.2 Docker（7）

• 多阶段构建；使用小体积基础镜像（distroless、alpine 或 slim）；锁定镜像 digest。
• 以非 root 用户运行；镜像和镜像层中不放密钥；使用 .dockerignore。
• 在 CI 中扫描镜像（Trivy）。本地、CI 和生产环境跑的是同一个镜像：从此告别“在我机器上是好的”。

11.3 供应链与依赖地狱（108，OWASP A03:2025）

• 提交 lockfile；CI 中使用 npm ci 或冻结版本的安装方式。
• Slopsquatting： AI 工具有时会推荐根本不存在的包，攻击者就去抢注这些名字。确认每一个新依赖真实存在、有人维护、有真实使用量，而且拼写正确。
• 自动更新（Dependabot/Renovate）配合测试；小版本更新合并处理；大版本更新逐个评审。
• 尽量减少依赖；优先使用平台能力和标准库。
• 每次构建生成 SBOM（CycloneDX 或 SPDX）；做来源证明和签名（SLSA 框架、Sigstore/cosign、GitHub artifact attestations）。越来越多的企业客户会要求提供 SBOM。
• 把 GitHub Actions 锁定到 commit SHA；GITHUB_TOKEN 权限遵循最小权限。

11.4 渐进式发布（51 至 55）

• Feature flag（51）： 代码先暗中部署，再发布给内部用户，然后按百分比放量，最后全量。把部署和发布分开。清理旧的 flag（它们是技术债）。
• 滚动发布（Rolling，54）： 逐步替换实例；大多数平台的默认方式。
• Canary（53）： 把一小部分流量导到新版本，对比错误率和延迟，自动晋级或中止。
• 蓝绿部署（Blue-green，52）： 两套完整环境；流量瞬间切换；也能瞬间切回。
• Rollback（55）： 最重要的一项。使用平台的即时回滚（Vercel、Cloudflare、Fly、Render），或重新部署上一个镜像 tag。要反复演练。数据库迁移必须向后兼容，代码回滚才安全（参见 03 · 数据基础 的 expand and contract）。

11.5 基础设施即代码（104, 105）

• 所有东西（DNS、存储桶、数据库、队列、IAM、告警）都用代码定义，在 PR 中评审，由 CI 执行变更。生产环境禁止手动点控制台。
• Terraform / OpenTofu（105）、Pulumi（TypeScript）或平台配置文件。状态远程存储并加锁。
• 好处：环境可复现、有审计记录、重新 apply 即可完成灾难恢复。
• 扫描 IaC 中的配置错误（Checkov、Trivy）。

11.6 Kubernetes、Helm 与服务发现（8, 9, 106）

• Kubernetes（8） 负责编排容器：调度、自愈、扩缩容、滚动更新。Helm（106） 用于打包 K8s 应用。服务发现（9） 让服务之间能按名字互相找到。
• 实话实说：对小团队来说，托管 PaaS（Vercel、Cloudflare、Fly、Render、Railway、Cloud Run、ECS）能以极小的运维负担拿到大部分好处。当你有很多服务、有平台团队，或有企业/私有化部署需求时，再上 K8s。

11.7 环境

本地 → 预览（每个 PR 一个）→ staging（接近生产，使用匿名化数据）→ production。每个环境使用独立的凭据和账号。默认情况下，AI agent 绝不持有生产凭据。

实验 11：一天上线十次

1. 在 GitHub Actions 中搭建上面完整的流水线。
2. 加上 SBOM 生成以及依赖和容器扫描；出现严重漏洞即失败。
3. 用 flag 包住一个新功能；先发布给 10%，再到 100%。
4. 故意上线一个有问题的版本；发现问题并回滚。记录耗时。
5. 用 Terraform/OpenTofu 或 Pulumi 定义你的基础设施（至少包括 DNS、数据库、存储和一条告警）。

完成标准（Definition of Done）

• main 分支已保护；所有变更都通过 PR 且 CI 通过证据
• 流水线中有安全扫描和 SBOM证据
• Actions 已锁定到 SHA；依赖更新机器人已启用证据
• 正在使用 feature flag 系统证据
• 实测 rollback 少于 1 分钟（证据：时间戳）证据
• 核心基础设施已代码化证据
• 跟踪部署频率和变更失败率（DORA）证据

AI 提示词包

• “写一个 GitHub Actions workflow，包含 lint、typecheck、带 Postgres service container 的测试、gitleaks、Semgrep、依赖审计、带 Trivy 扫描的 Docker 构建，以及 SBOM。所有 action 都按 SHA 锁定，并使用最小权限。”
• “对于这次 diff 中新增的每个依赖，确认它在 registry 上真实存在，并给出它的周下载量、最近发布日期和维护者数量。”