Ch 28 四类发布流¶
面包屑
本书主页 › Part IV 基础设施与工程效能 › Ch 28
项目第 1 年 · 核心建设期——发布流设计
本章你将学到¶
- 四类发布物的制品模型与审批差异：Terraform / Glue / Lambda / DynamoDB 配置
- feature→dev→qa→prod 晋升与 PROD 四道门禁
- 为何配置走热更新、脚本走版本化 S3、基础设施走 plan 制品
28.1 四类发布流¶
Ch 27 的变更检测会把一次推送拆进不同流水线。四类发布物不能共用同一套门禁强度：改字段映射，和改 Redshift 参数组，爆炸半径差两个数量级。
%%{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 四类发布流
| 发布流 | 制品 | 生效方式 | PROD 门禁 |
|---|---|---|---|
| Terraform | plan 文件（二进制/JSON） | apply | 人工 review plan + 审批 |
| Glue | 版本化 S3 对象（…/1.2.3/job.py） |
tfvars 改路径后再 TF apply，或绑定的 job update | 版本晋升 + 域验证 |
| Lambda | zip/layer + S3 | 更新函数代码；注意冷启动窗口 | 同 Glue，另加预热 |
| 配置 | 表级 JSON | 写入 DynamoDB，下次读取即生效 | 仍走环境晋升，但不跑全量 TF |
表 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 | -backend-config 注入 + 拉模块 |
自动 |
| validate / ASL lint | 语法 + 状态机 processed 校验 | 自动 |
| plan | 生成并上传 plan 制品 | 自动 |
| review | 人读 plan | PROD 必需 |
| apply | terraform apply plan.out（禁止无 plan 的 apply） |
DEV 可自动；PROD 手动 |
表 28-1 Terraform 发布流
我坚持 PROD 只 apply 已审查的 plan 文件，禁止审批后再跑一遍裸 plan。否则审查过的，和真正执行的，可能不是同一份差分。
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 桶 | 脚本与 whl 版本化存放 |
| snapshot / release | feature→snapshot；合并主线→release 版本 |
| 与 TF 解耦又耦合 | 制品可先上传；生效靠 tfvars 中 script_location 晋升 |
表 28-2 Glue 脚本发布流
Lambda 代码发布流¶
与 Glue 类似：打包 → S3 → 更新函数。差异在冷启动窗口：已热实例可能仍跑旧代码。控制面 Lambda 靠幂等兜底；有进程内缓存的，发布后我会触发一次预热，缩短双版本共存。上传不等于全流量立刻换成新逻辑。
配置发布流¶
%%{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
配置热更新让"加数据源"不必走 TF apply（呼应 Ch 25 边界），错误也会更快打到运行时。因此配置流仍走 feature→dev→qa→prod，只是跳过基础设施 plan。我见过有人做成"直写 prod 表"：两周后一次错误映射污染主数据，回滚靠 DynamoDB PITR。热更新不是无门禁（M1 / M5）。
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（自动） |
| feature 校验 | PR | 矩阵 plan 覆盖多环境（只读） | 不 apply prod |
| dev → tag | 手动打 tag | DEV 验证 | — |
| tag → QA | 手动 | UAT | 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 审批门禁设计
引申
四道门禁来自企业征信"merge 即生产"的周末事故。CI 防代码错，UAT 防业务错，审批防未授权，窗口防无人值守爆炸。紧急修复可以降级门禁，但必须事后补审：GxP 要的是可归属，不是永远不能 hotfix（M10）。周五下午默认不开 PROD。两年里拦下的"差点周末炸"，比门禁耽误的时间值钱。
发布流要落地，还差凭证。下一章讲 OIDC、中国区 STS，以及我们仍未完全消灭的长期密钥债。
本章小结¶
- 四类流制品不同：plan 文件 / 版本化 S3 脚本 / Lambda 包 / DynamoDB 配置热更新
- 晋升路径统一，门禁强度按爆炸半径调；配置热更新仍要环境晋升
- PROD 只 apply 已审 plan；变更窗口与可归属优先于发布手感
下一章
Ch 29 OIDC 与凭证治理 —— 发布流走通了，但 CI 怎么安全地获取 AWS 凭证？接下来看 OIDC 无密钥设计。