部署与灰度发布：从 CI 流水线到一键回滚

快（Velocity）：
□ 从合并到上线的时间（Lead Time）越短越好
□ 小批量、高频次发布 → 每次变更的风险更小
□ 全自动，无需人工点击与等待

稳（Safety）：
□ 每步都有自动门禁（测试、契约、性能）
□ 变更可观测：发布后指标自动比对
□ 有明确的「健康判据」决定是否继续放量

可回滚（Recoverability）：
□ 回滚必须比发布更快、更简单
□ 数据变更必须可前滚也可回滚
□ 回滚是「一条命令」而非「一次事故响应」

流水线阶段（由快到慢，快速失败）：
1. 触发：push / PR / tag
2. 静态检查：格式化、lint、类型检查（秒级）
3. 单元测试：纯逻辑，毫秒~秒级
4. 构建：编译、打包（产出制品）
5. 集成测试：真实依赖容器（分钟级）
6. 安全扫描：依赖漏洞、镜像扫描、SBOM
7. 制品推送：打标签、签名、入库
8. 部署到预发：自动或半自动

# 流水线骨架：阶段并行、快速失败、制品唯一
name: ci
on: [push]
jobs:
  verify:
    steps:
      - run: golangci-lint run
      - run: go test -race ./...
      - run: npm ci && npm run typecheck && npm run test -- --run
  build:
    needs: [verify]
    steps:
      - run: docker build -t $REGISTRY/miniblog:$GIT_SHA .
      - run: docker push $REGISTRY/miniblog:$GIT_SHA
      - run: cosign sign $REGISTRY/miniblog:$GIT_SHA

不可变制品（Immutable Artifact）：
□ 唯一标识：用 git SHA 或内容摘要（digest）而非 latest
□ 不可覆盖：同名标签一旦发布就不再改变
□ 可追溯：从制品能反查到 commit、构建号、依赖清单
□ 可复现：同样的源码与锁文件 → 同样的制品

镜像工程要点：
□ 多阶段构建：builder 与 runtime 分离，镜像更小
□ 固定基础镜像 digest，而非漂移的 tag
□ 非 root 用户运行，最小化攻击面
□ 只带运行时依赖，不带源码与构建工具
□ 带 SBOM（软件物料清单）与签名（cosign）

FROM golang:1.23-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/server

FROM gcr.io/distroless/static:nonroot
COPY --from=build /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

滚动更新（Rolling Update）：
□ 逐批替换旧实例，服务不中断
□ 优点：资源省、简单；缺点：新旧版本短暂并存
□ 关键参数：maxSurge / maxUnavailable、就绪探针
□ 适合：无状态服务、兼容性良好的变更

蓝绿部署（Blue-Green）：
□ 起一套全新环境（绿），验证后切流量（蓝→绿）
□ 优点：切换快、回滚即切回；缺点：资源翻倍
□ 关键：数据库与共享状态必须兼容两套
□ 适合：大版本、需要「一键切换」的场景

金丝雀（Canary）：
□ 先放一小部分流量到新版本，观测后逐步扩大
□ 优点：风险最小；缺点：需要精细的流量控制与观测
□ 关键：按比例/按人群分流、自动分析指标
□ 适合：高风险变更、需要真实流量验证

# Kubernetes 滚动更新：就绪探针 + 优雅停机是关键
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: app
          readinessProbe: { httpGet: { path: /healthz, port: 8080 }, initialDelaySeconds: 5 }
          livenessProbe:  { httpGet: { path: /livez,  port: 8080 }, periodSeconds: 10 }

放量维度：
□ 内部用户：员工 / 内测白名单（最安全的第一步）
□ 百分比：1% → 5% → 20% → 50% → 100%
□ 地域：先小市场（如某城市）再大市场
□ 设备/客户端：先某个 App 版本
□ 用户属性：新用户先试、老用户后试

放量节奏的决策依据：
□ 每档停留时长：看指标稳定所需的时间（如 30 分钟~24 小时）
□ 进入下一档的条件：核心指标不劣化 + 无新增错误
□ 中止条件：错误率、延迟、崩溃率超阈值 → 自动回退

Expand-Contract（扩展-收缩）模式：
把「破坏性变更」拆成多步、每步都可独立发布：

第 1 步 Expand：新增列/表，代码双写（旧字段 + 新字段）
  · 旧代码只读旧字段，新代码读新字段，两边都能跑
第 2 步 Migrate：后台回填历史数据（分批、限速）
第 3 步 Switch：代码切到只读新字段，停止双写
第 4 步 Contract：确认无回滚需求后，删除旧字段

关键：任何一步之后，新旧代码都必须能同时运行

-- 安全：加列、加索引（并发建索引，不锁表）
ALTER TABLE posts ADD COLUMN IF NOT EXISTS visibility text DEFAULT 'public';
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_posts_visibility ON posts (visibility);

-- 危险（会锁表 / 不可回滚）：直接改类型、重命名、删列
ALTER TABLE posts ALTER COLUMN text TYPE varchar(280);  -- 可能长时间锁表
ALTER TABLE posts DROP COLUMN legacy_flag;              -- 回滚即数据丢失

回滚的三层手段（由快到慢）：
1. 开关回滚（秒级）：关闭功能开关，代码不换、行为回退
2. 流量回滚（秒级~分钟）：把流量切回旧版本（蓝绿切回 / 金丝雀缩容）
3. 版本回滚（分钟级）：重新部署上一个制品

前置条件（不满足就无法快速回滚）：
□ 制品保留：至少保留最近 N 个可部署版本
□ 配置兼容：新配置能被旧代码读取（或配置与代码同步回滚）
□ 数据兼容：数据库变更遵守 expand-contract，旧代码仍可运行
□ 回滚演练：回滚路径定期演练，而不是出事了才第一次用

# 版本回滚：切回上一个已知良好制品（不要重新构建）
kubectl set image deploy/miniblog-api api=$REGISTRY/miniblog:$LAST_GOOD_SHA
kubectl rollout status deploy/miniblog-api --timeout=120s
kubectl rollout undo deploy/miniblog-api   # 或直接用 undo

# 确认回滚生效：看新版本是否就绪、错误率是否回落

发布可观测（Deployment Observability）：
□ 部署标记：把每次部署作为一条事件打到监控图上
  · 指标突变的时刻能立刻对应到「谁在什么时候发了什么」
□ 变更关联：制品 digest ↔ commit ↔ PR ↔ 发布人
□ 健康判据自动化：发布后自动比对前后窗口指标
□ 发布看板：当前在跑哪些灰度、比例多少、是否达标

发布冻结（Release Freeze）：
□ 大促 / 活动期间冻结非紧急发布
□ 只允许「修复型」热修复，走加急通道
□ 冻结前做一次全量回归与容量确认
□ 冻结不等于停止一切：关键修复仍需能上

时间线对齐示例：
12:00  部署 v1.42.0（10% 金丝雀）
12:08  错误率 0.05% → 0.06%（正常波动）
12:15  放量到 50%
12:22  错误率跃升至 1.2%，P99 从 180ms → 900ms
12:23  自动金丝雀分析判定超标 → 自动回滚
12:24  指标回落，影响时长 2 分钟

环境分层：
□ dev（本地）：容器化依赖，快速启动
□ staging（预发）：与生产同构（同镜像、同配置结构、脱敏数据）
□ prod（生产）：分区域部署，灰度与滚动
□ 环境差异必须显式声明，不能靠「记忆」

基础设施即代码（IaC）：
□ 声明式：Terraform / Pulumi / Helm 描述期望状态
□ 版本化：基础设施变更走 PR 评审
□ 可重建：从代码能重建整套环境（灾难恢复的底气）
□ 幂等：重复执行结果一致

# 声明式基础设施：版本化、可评审、可重建
resource "aws_ecs_service" "api" {
  name            = "miniblog-api"
  desired_count   = 3
  deployment_configuration {
    maximum_percent         = 200
    minimum_healthy_percent = 100
    deployment_circuit_breaker { enable = true, rollback = true }
  }
}