Ch 28 四类发布流¶
面包屑
本书主页 › Part IV 基础设施与工程效能 › Ch 28
项目第 1 年 · 核心建设期——发布流设计
本章你将学到¶
- 四类发布物（ Terraform/Glue/Lambda/配置）各自的发布流设计
- feature→dev→qa→prod 的晋升路径与审批门禁
- 语义化版本在发布流中的应用
28.1 四类发布流¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
subgraph 四类发布物["四类发布物"]
TF@{ icon: "devicon:terraform", form: "rounded", label: Terraform 资源<br/>init→validate→plan→apply, pos: "b", h: 40 }
GLUE@{ icon: "logos:aws-glue", form: "rounded", label: "Glue 脚本<br/>打包→S3 上传→版本化", pos: "b", h: 40 }
LAMBDA@{ icon: "logos:aws-lambda", form: "rounded", label: Lambda 代码<br/>打包→S3 上传→更新函数, pos: "b", h: 40 }
CONFIG@{ icon: "logos:aws-dynamodb", form: "rounded", label: DynamoDB 配置<br/>JSON→发布→热更新, pos: "b", h: 40 }
end
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
class CONFIG,GLUE,LAMBDA,TF bpProcess
linkStyle default stroke:#697077,stroke-width:2px图 28-1 28.1-28.4 四类发布流
Terraform 发布流¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
INIT[terraform init] --> VALIDATE[terraform validate]
VALIDATE --> PLAN[terraform plan]
PLAN --> REVIEW[人工 review plan]
REVIEW --> APPLY[terraform apply]
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
class APPLY,INIT,PLAN,REVIEW,VALIDATE bpProcess
linkStyle default stroke:#697077,stroke-width:2px图 28-2 Terraform 发布流
| 阶段 | 作用 | 自动/手动 |
|---|---|---|
| init | 初始化后端+下载模块 | 自动 |
| validate | 语法校验 | 自动 |
| plan | 生成变更计划 | 自动 |
| review | 人工审查变更 | 手动（PROD 必需） |
| apply | 执行变更 | 手动（PROD）/ 自动（DEV） |
表 28-1 Terraform 发布流
Glue 脚本发布流¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
CODE[代码提交] --> PACK[CI 打包]
PACK --> UPLOAD[上传 S3 tooling 桶]
UPLOAD --> VERSION[语义化版本号]
VERSION --> REF[Terraform 引用新版本]
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
class CODE,PACK,REF,UPLOAD,VERSION bpProcess
linkStyle default stroke:#697077,stroke-width:2px图 28-3 Glue 脚本发布流
| 设计要点 | 说明 |
|---|---|
| S3 tooling 桶 | 脚本存 S3，Glue Job 通过 S3 路径引用 |
| 语义化版本 | 每次 CI 生成版本号（如 v1.2.3） |
| snapshot/release | feature 分支→snapshot， dev 分支→release |
| Terraform 引用 | tfvars 中指定脚本版本，apply 时更新 Glue Job |
表 28-2 Glue 脚本发布流
Lambda 代码发布流¶
与 Glue 类似：CI 打包 → S3 上传 → Terraform 更新 Lambda function 的 code source。但 Lambda 有一个 Glue 没有的特点——冷启动。Lambda 代码更新后，已运行的实例不会立即加载新代码，要等下次冷启动才生效。这意味着发布后有一个"新旧代码共存"的窗口期——有些请求走旧代码，有些走新代码。对于控制面 Lambda（触发、状态回写），这个窗口期影响不大（幂等设计兜底）；但如果 Lambda 里有状态ful逻辑（如全局变量缓存），新旧共存可能出问题。我的做法是发布后手动触发一次"预热"——发一个空请求让 Lambda 冷启动加载新代码，缩短窗口期。Lambda 发布不是"上传即生效"，要考虑冷启动窗口期——这是 Lambda 和 Glue 发布流的关键差异。
配置发布流¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
JSON[配置 JSON 提交] --> CI[CI 校验]
CI --> PUBLISH[发布到 DynamoDB]
PUBLISH --> HOT[热更新生效<br/>无需重启/重建资源]
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
class CI,HOT,JSON,PUBLISH bpProcess
linkStyle default stroke:#697077,stroke-width:2px图 28-4 配置发布流
Trade-off
配置发布流是"热更新"——推送到 DynamoDB 即生效，无需 Terraform apply。这让"加数据源"极快，但也意味着"配置错误会立即影响生产"。所以配置发布流同样需要 feature→dev→qa→prod 的晋升路径和审批门禁。
28.5 feature→dev→qa→prod 的晋升路径与审批门禁¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
FB[Feature Branch] -->|PR + Review|DEV[dev 分支<br/>DEV 自动部署]
DEV -->|验证通过|TAG[打 Tag]
TAG -->|手动触发|QA[QA 部署<br/>UAT 验收]
QA -->|验收通过|APPROVE[PROD 审批]
APPROVE -->|审批通过|PROD[PROD 部署]
style PROD fill:#fff1f1,stroke:#da1e28,stroke-width:2px图 28-5 feature→dev→qa→prod 的晋升路径与审批门禁
| 阶段 | 触发方式 | 门禁 | 部署目标 |
|---|---|---|---|
| Feature → dev | PR merge | 代码审查 + CI 通过 | DEV（自动） |
| dev → tag | 手动 打 tag | DEV 验证通过 | — |
| tag → QA | 手动触发 | 无额外 | QA |
| QA → PROD | 手动触发 | UAT 验收 + 审批 | PROD |
表 28-3 feature→dev→qa→prod 的晋升路径与审批门禁
审批门禁设计¶
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
subgraph PROD门禁["PROD 部署门禁"]
G1[CI 全绿<br/>plan 无错误]
G2[UAT 验收通过<br/>业务确认]
G3[审批人确认<br/>至少一人 approve]
G4[变更窗口<br/>非业务高峰期]
end
classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
class G1,G2,G3,G4 bpProcess
linkStyle default stroke:#697077,stroke-width:2px图 28-6 审批门禁设计
引申
PROD 门禁的核心是"防止错误变更上生产"。四道门禁（CI/UAT/审批/窗口）各有侧重：CI 防"代码错误"，UAT 防"业务逻辑错误"，审批防"未授权变更"，窗口防"业务影响"。不是所有变更都需要全部门禁——紧急修复可以简化流程，但必须有事后补审。
这四道门禁的设计，是我从企业征信"无门禁发布"的教训里提炼的。企业征信时 PROD 部署没有审批门禁——开发者 merge 到 main 就自动部署 PROD。结果有次开发者在周五下午 merge 了一个"小改动"就下班了，周末 PROD 跑出了一个报表数字全错的故障——而那个"小改动"其实改了 ETL 的聚合逻辑。从那以后我定了"四道门禁"铁律：CI 防代码错、UAT 防业务错、审批防未授权、窗口防业务影响。其中"变更窗口"是我最坚持的一条——周五下午不许发 PROD，因为周末没人值班，出了故障没人修。这个规则看似保守，但在两年内避免了至少三次"周末故障"——有次开发者想周五发，被门禁拦下，周一发时发现了 bug，如果周五发了就是周末爆炸。门禁的代价是"慢"，但慢是为了不炸——在 PROD 环境，这个权衡永远偏向安全。
本章小结¶
- 四类发布流：Terraform（init→validate→plan→review→apply）/ Glue（打包→S3→语义化版本→Terraform 引用）/ Lambda（同 Glue）/ 配置（ JSON→DynamoDB 热更新）
- 晋升路径：feature→dev（自动）→tag→QA（手动）→PROD（审批），每阶段有门禁
- PROD 四道门禁：CI 全绿 / UAT 验收 / 审批人确认 / 变更窗口——紧急修复可简化但需事后补审
下一章
Ch 29 OIDC 与凭证治理 —— 发布流走通了，但 CI 怎么安全地获取 AWS 凭证？接下来看 OIDC 无密钥设计。