S15-A02 · 容器化部署与 CI/CD

适用读者：要把"手动上线"变成"可回滚的流水线"的人。
前置：S15-J05、S14-A01。
覆盖旧文：400（CI/CD 入门，733 点）。
覆盖扩展：E-S15-009（流水线四阶段）、E-S15-018（回滚三要素）。
上一篇：S15-A01 · Nginx：反向代理、gzip 与 TLS
下一篇：S15-A03 · 多平台安装与中间件编排。

1. 一句话结论

CI/CD 的价值不在"自动"，在"每次变更都可重复、可验证、可回滚"。四阶段：构建 → 测试 → 制品 → 部署。

阶段	产出	关键要求
CI（构建）	镜像/包	可重复（S06-A02 的四要素）
测试	报告	失败即停
制品	带版本号/摘要	不可变
CD（部署）	运行实例	可回滚

2. 为什么"制品不可变"是核心（E-S15-018）

反例	后果
每次部署都重新构建	同一 commit 可能产出不同结果
用 `latest` 标签	无法知道线上是哪版
直接在生产机上改文件	无法回滚、无审计

正确做法：

构建一次 → 打上 commit hash 标签 → 同镜像在测试/生产都用它 → 回滚=切标签

判据："线上跑的是哪个 commit？" 答不上来 → 制品治理有问题。

3. 四阶段流水线（E-S15-009）

# 伪代码（GitHub Actions / GitLab CI 同构）
build:   docker build -t app:${GIT_SHA} .
test:    docker run app:${GIT_SHA} npm test
publish: docker push app:${GIT_SHA}
deploy:  kubectl set image / docker compose up -d  (按环境)

阶段	失败怎么办
构建	直接失败（不产出）
测试	阻断（不许发布）
发布制品	重试
部署	自动回滚到上一个标签

4. 回滚三要素

要素	说明
旧制品存在	镜像保留 N 个版本
切换是原子的	容器/负载均衡切标签
数据兼容	迁移脚本要向后兼容（S11-A02）

"数据库是最难回滚的"——所以先做兼容性变更（加列），再改代码，最后删旧列（expand-contract）。

5. 观测：部署完怎么判断成功

指标	阈值
错误率	恢复基线
延迟 P99	不高于部署前
健康检查	`/healthz` 200
日志	无新异常

判据："部署成功"由指标判定，不是由"命令返回 0"判定。

6. 五个误区

误区	真相
"流水线就是跑个脚本"	关键是制品与回滚
"用 `latest` 更省事"	无法追踪版本
"回滚就是 `git revert`"	要回滚制品，不是源码
"数据库也能一键回滚"	需 expand-contract
"部署成功=服务正常"	要看指标

7. 自检（架构师版）

四阶段各产出什么？
为什么"制品不可变"是核心？
回滚三要素？
数据库为什么最难回滚？怎么缓解？
"部署成功"怎么判定？

8. 下一篇

S15-A03 · 多平台安装与中间件编排

流水线讲完，最后一篇：同一套 compose 怎么在开发/生产复用（含 WSL2 与中间件安装）。

本篇属于系列《S15 · Linux 与运维》。旧文来源：A-400；扩展点 E-S15-009/018。