CI/CD on 方糖猫Blog

CI/CD 端到端落地实录：从 Git Push 到 K8s 发布的完整流水线

Wed, 02 Sep 2026 10:00:00 +0800

CI/CD 端到端落地实录：从 Git Push 到 K8s 发布的完整流水线

目标读者：会写 Jenkinsfile、会用 kubectl，但还没在生产环境把「提交代码 → 自动发布 → 失败回滚」整条链路跑通的同学。文中例子取自我主导的真实项目 videocloud（视频云转码服务，Spring Boot + Nacos + K8s），与站内《Kubernetes 学习总结与避坑指南》（kubernetes-authoritative-guide-notes.md）互为补充。

CI/CD 的 Demo 半小时能搭出来，生产可用要踩半年坑。kubectl apply 返回 0 不代表发布成功，Pod Ready 不代表配置生效。本文按真实落地顺序拆解五个阶段，每个阶段给出可抄的配置和踩过的坑。

一、全景：一条流水线要干多少事

graph LR
    Dev[git push / merge] --> WH[Webhook 触发 Jenkins]

    subgraph S1["阶段一：拉取与编译"]
        A1[检出 commit] --> A2[恢复依赖缓存]
        A2 --> A3[单测 + 打包]
    end

    subgraph S2["阶段二：推送产物"]
        B1[构建镜像] --> B2[推 ACR<br/>tag = git commit]
        B3[渲染部署模板<br/>快照留档]
    end

    subgraph S3["阶段三：执行变更单"]
        C1[DB changelog<br/>Liquibase] --> C2[Nacos changelog<br/>OpenAPI 发布]
    end

    subgraph S4["阶段四：部署与验证"]
        D1[更新 ConfigMap<br/>+ 滚动更新] --> D2[rollout status 阻塞]
        D2 --> D3[冒烟测试]
        D3 -->|成功| OK[发布完成]
        D3 -->|失败| RB[rollout undo<br/>自动回滚 + 告警]
    end

    WH --> S1 --> S2 --> S3 --> S4

阶段顺序有一条铁律：先备好「环境」，再动「代码」——数据库先于应用升级（新代码依赖新表结构），配置先于 Pod 重启（新 Pod 不能拿旧配置）。顺序反了，就是半夜被叫醒的那种故障。

二、阶段一：Jenkins 拉取与编译

2.1 触发：Webhook，不是轮询

Git 平台配 Webhook，push/merge 时推给 Jenkins。不要用 SCM 轮询——几十个仓库每分钟扫一遍，Jenkins 自己先爆了。分支与环境对应：feature/* 只编译+单测，develop 自动部署到 dev，master/tag 走完整流水线 + 人工审批发 prod。

2.2 编译提速：缓存 + 并行

stage('拉取与编译') {
    steps {
        checkout scm
        sh '''
            mvn -q -T 1C test                      # 单测先跑，挂了直接终止
            mvn -q -T 1C -DskipTests package       # -T 1C 按核数并行
        '''
    }
}

依赖缓存是性价比最高的优化：~/.m2 挂共享 PVC，构建从 5 分钟压到 1 分钟。
单测只跑变更相关模块（mvn -pl -am），全量留给 nightly。门禁是拦问题的，不是表演严格的。

2.3 Jenkins 自身怎么部署才不拖后腿

流水线慢，一半原因在 Jenkins 自己的形态。我们的规范五条：

Controller 只调度不构建（executors 设为 0），否则构建打满 Controller，UI 卡死、webhook 丢失。
agent 用 Kubernetes 插件动态拉起：按语言预定义 Pod 模板（maven/node/go），构建完即销毁，并发上限就是集群容量：

# agent Pod 模板要点
spec:
  nodeSelector: { node-pool: ci-build }      # 调度到 CI 专用节点池
  containers:
    - name: maven
      image: registry.../ci/maven:3.9-jdk17  # 自维护构建镜像，工具一次装好
      resources:
        requests: { cpu: "4", memory: 8Gi }
      volumeMounts:
        - { name: m2-cache, mountPath: /root/.m2 }
  volumes:
    - name: m2-cache
      persistentVolumeClaim: { claimName: ci-m2-cache }

CI 独立节点池：SSD 磁盘（编译是 IO 密集型）、taint 防业务混部、闲时自动缩容。
构建镜像自己维护：JDK、Maven 私服配置、docker/kubectl/cosign 全打进去，agent 起来就能干活。
部署阶段并行化：无依赖的服务用 parallel 并发部署。我们 8 个服务的流水线从 25 分钟降到 9 分钟。

三、阶段二：推镜像、推配置

3.1 镜像 tag：回滚能力的地基

environment {
    IMAGE = "registry.cn-hangzhou.aliyuncs.com/mycompany/videomart-videocloud"
    TAG   = "${env.GIT_COMMIT.take(8)}"   // git commit 短哈希：唯一、可追溯、可回滚
}

三条规矩：

部署 tag 必须唯一可追溯，杜绝 latest——回滚时说不清「上一个 latest」是谁。
生产仓库开 tag 不可变，禁止覆盖推送，否则同 tag 不同代码，回滚失效。
推送后 cosign 签名，K8s 侧用 Kyverno 校验，未签名拒绝部署——镜像仓库凭证泄露时，这是最后一道闸。

3.2 部署配置：仓库里只存一份参数化模板

原则：代码仓库不按环境拆分配置（没有 prod/、dev/ 目录）。同一份配置写三遍，改一处忘两处是必然结局。videocloud 的做法——部署模板随应用仓库，全部 ${占位符}：

videocloud/
├── k8s_deploy/                                    # 部署模板：环境无关，只有一份
│   ├── k8s-deployment-videomart-videocloud.yaml   # 头部注释列出全部参数
│   ├── k8s-service-videomart-videocloud.yaml
│   └── k8s-persistentvolumeclaim-videomart-videocloud.yaml
├── changelog/          # 数据库/Nacos 变更单（第四章）
└── src/main/resources/bootstrap.properties   # 服务读 Nacos 的方式（第五章）

### 参数: APP_NAME, APP_PORT, NAMESPACE, VERSION
kind: Service
apiVersion: v1
metadata:
  name: videomart-videocloud
  namespace: ${NAMESPACE}      # 发布到哪个环境，由 CD 注入
spec:
  ports:
    - { name: http-0, port: 9577, targetPort: 9577 }

流水线在这一步把渲染结果（含镜像 tag、namespace、副本数的完整快照）提交到发布记录库留档。模板只有一份保证「写法一致」，快照留档保证「可审计、可回滚」，两件事分开解决。

四、阶段三：变更单驱动——数据库与 Nacos

发布事故的头号根源不是工具，而是变更没落盘：开发改了字段口头通知运维，配置加在 Nacos 控制台、测试环境忘了加。规范只有一条：一次迭代对「环境」的所有变更——表结构、Nacos 配置——必须作为 changelog 文件随代码提交、随代码评审。

videocloud/changelog/
├── database/    # Liquibase 格式
│   ├── videomart-videocloud-changelog-db-v6.0.4.0-01.yaml
│   └── ...-02.yaml ...
└── nacos/
    └── videomart-videocloud-changelog-nacos-v6.0.4.0-01.yaml

命名 {服务}-changelog-{db|nacos}-{版本}-{序号}.yaml，序号定执行顺序。CD 的职责是按序、幂等地执行：

graph LR
    A[扫描 changelog<br/>按版本+序号排序] --> B{changeSet id<br/>已执行?}
    B -->|是| C[跳过，幂等]
    B -->|否| D["渲染占位符<br/>${VAR} ← Jenkins 凭据"]
    D --> E[执行<br/>DB: liquibase update<br/>Nacos: OpenAPI]
    E --> F[记录 id<br/>失败即终止流水线]

4.1 数据库变更单（Liquibase）

# changelog/database/videomart-videocloud-changelog-db-v6.0.4.0-01.yaml（节选）
databaseChangeLog:
  - changeSet:
      id: videomart-videocloud-changelog-db-v6.0.3.0-05
      author: cline
      comment: Add stream task table for transcoding
      changes:
        - sql:
            sql: |-
              CREATE TABLE `GTT_VIDEOMART_VIDEOCLOUD_STREAM_TASK` ( ... );

CD 用官方镜像执行，已执行的 changeSet 记在 DATABASECHANGELOG 表里，天然幂等：

sh '''
    docker run --rm -v $WORKSPACE/changelog/database:/liquibase/changelog \
        liquibase/liquibase:4.29 \
        --url=jdbc:mysql://prod-mysql:3306/videomart \
        --username=$DBU --password=$DBP \
        --changelog-file=videomart-videocloud-changelog-db-${VERSION}.yaml \
        update
'''

纪律三条：

只增不改、向后兼容：滚动更新期间新旧 Pod 同时在线，新代码要的表结构先就位，旧代码不能被新结构弄挂。
破坏性变更拆两次发布：先发「代码不再读写该字段」，观察一周，再发「删字段」。代码能回滚，删掉的列回不来。
执行过的 changeSet 绝不许改（checksum 变了 Liquibase 直接拒绝），要改就写新变更单。

4.2 Nacos 变更单

自定义格式，与 DB 同一套约定（videocloud 真实文件）：

# changelog/nacos/videomart-videocloud-changelog-nacos-v6.0.4.0-01.yaml
nacosChangeLog:
  - changeSet:
      id: videomart-videocloud-changelog-nacos-v6.0.4.0-01
      comment: videocloud drm configuration
      changes:
        - namespace: ${NAMESPACE}
          group: videocloud
          dataId: gtt-videomart-videocloud.properties
          format: properties
          patchContent: |-
              gtt.videomart.videocloud.db.username = ${VIDEOMART_VIDEOCLOUD_DATABASE_USERNAME}
              gtt.videomart.videocloud.aws.s3.accessKeyId = ${FUSIONSTORAGE_ACCESS_KEY}
              gtt.videomart.videocloud.aws.s3.secretAccessKey = ${FUSIONSTORAGE_SECRET_KEY}

注意：变更单里没有一个真实密钥，全是 ${占位符}——「key 叫什么、引哪份凭据」可以进 Git，「值是什么」不可以。

patchContent 是增量。CD 脚本逻辑：GET 现有配置 → envsubst 渲染增量 → 合并（增量覆盖同名 key）→ 整体发布 → 读回校验 → 记录 id。发布用的是 Nacos OpenAPI（POST /nacos/v1/cs/configs），Nacos 客户端长轮询秒级生效，不需要重启 Pod。生产 Nacos 必须开鉴权。

五、凭证权限划分：密钥只有 CD 管理员可见

占位符背后的真实值在哪、谁能碰？分三层：

graph TB
    Dev[开发者] -->|只能看到| Git[Git 仓库<br/>changelog 占位符 / 模板]
    CD[CD 管理员] -->|独占维护| Cred[Jenkins 凭据<br/>DB 账号 / S3 密钥]
    CD -->|独占维护| Sec[K8s Secret<br/>videomart-videocloud-secret]
    Pipe[CD 流水线] -->|"withCredentials 临时注入"| Cred
    Pod[运行中的 Pod] -->|"envFrom / secretRef"| Sec

四条规矩：

1. Jenkins 分角色。 Role-Based Strategy 插件：开发者能触发构建、看日志；只有 CD 管理员能管凭据、改生产流水线。凭据按 Folder 隔离，prod 的 DB 账号对开发者连「存在」都不可见。流水线里 withCredentials 临时注入，用完即销毁。

2. 服务只引用配置，绝不内嵌。 videocloud 的 bootstrap.properties 节选：

spring.cloud.nacos.config.server-addr=${NACOS_SERVER_ENDPOINT:localhost:8848}
spring.cloud.nacos.config.namespace=${NACOS_NAMESPACE:videomart}
spring.cloud.nacos.config.group=videocloud
spring.cloud.nacos.config.username=${NACOS_USERNAME}
spring.cloud.nacos.config.password=${NACOS_PASSWORD}
spring.cloud.nacos.config.refresh-enabled=true
spring.config.import=optional:nacos:gtt-videomart-videocloud.properties

服务只声明「连哪个 Nacos、读哪个 dataId」，账号全占位，生产由 K8s Secret 注入。默认值只给本地开发用，宁可留空让缺参时启动直接报错，也不要把内网地址当真默认值写进仓库。

3. 注入靠 Secret 引用。 看 k8s_deploy 的 Deployment 模板：

envFrom:
  - configMapRef: { name: gtt-common-config }        # 公共非敏感配置
  - secretRef:    { name: videomart-videocloud-secret }  # 本服务的 Nacos/DB 账号
  - secretRef:    { name: gtt-common-secret }        # 公共敏感配置

Secret 由 CD 管理员提前建好，开发者不需要、也不应该知道里面的值。

4. 轮换只动一处。 换 DB 密码 = 更新 Jenkins 凭据 + K8s Secret + 触发一次流水线，代码和模板都不用动。这就是「引用配置」相对「携带配置」的收益。

六、阶段四：更新 ConfigMap

《Kubernetes 学习总结与避坑指南》第七章讲透了两个坑，这里给结论：

环境变量注入的 ConfigMap，改了不生效，必须重启 Pod；文件挂载方式 kubelet 分钟级同步，但应用要自己支持 reload。
subPath 挂载单文件的 ConfigMap 永远不自动更新。

流水线的稳妥做法：kubectl apply 更新 ConfigMap 后无脑跟一次滚动更新——反正接下来要换镜像，合成一次滚动零成本。「要不要重启」交给脚本做死，比交给值班同学半夜判断可靠。

七、阶段五：部署与验证

7.1 部署配置长什么样

发布完成后集群里的对象关系：

graph TB
    GW[Gateway<br/>order.example.com] --> RT[HTTPRoute<br/>/api/order/**]
    RT --> SVC[Service videomart-videocloud<br/>ClusterIP 9577]
    SVC --> P1[Pod ✅] & P2[Pod ✅] & P3[Pod ✅]
    DEP[Deployment<br/>replicas: 3<br/>RollingUpdate] -.管理.-> P1
    CM[ConfigMap] -.挂载.-> P1
    NC[(Nacos)] -.长轮询推送.-> P1
    NC -.长轮询推送.-> P2
    NC -.长轮询推送.-> P3
    P1 --> DB[(MySQL)]

videocloud 的 Deployment 模板里有几处直接抄的规范：podAntiAffinity 强制同服务 Pod 分散到不同节点、topologySpreadConstraints 跨可用区打散、revisionHistoryLimit: 10 留回滚版本、探针端口与容器启动端口写死一致。对外暴露用 Gateway API（已 GA，Ingress 停止演进），把「入口」（Gateway，运维管）和「路由」（HTTPRoute，开发管）拆开。

7.2 部署与验证：流水线里真正干活的命令

stage('部署与验证') {
    steps {
        sh '''
            # 1. 渲染模板并部署
            envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml \
                | kubectl --kubeconfig=$KUBECONFIG apply -f -

            # 2. 阻塞等待滚动更新完成，超时/失败非零退出
            kubectl --kubeconfig=$KUBECONFIG -n $NAMESPACE \
                rollout status deployment/videomart-videocloud --timeout=300s

            # 3. 冒烟测试：健康检查 + 核心业务接口
            curl -fsS --retry 5 http://videomart-videocloud:9577/healthz || exit 1
        '''
    }
    post {
        failure {
            sh "kubectl --kubeconfig=$KUBECONFIG -n $NAMESPACE \
                rollout undo deployment/videomart-videocloud || true"
            // + 钉钉/邮件告警
        }
    }
}

再强调一遍：apply 成功只代表 apiserver 收下了 YAML。rollout status 阻塞 → 冒烟测试 → 失败自动 undo 三件套缺了，你的流水线只是「自动提交 YAML 的机器」。

7.3 部署凭证：别把 admin kubeconfig 给 Jenkins

给 Jenkins 一个只能操作特定 namespace、只能 patch Deployment 的 ServiceAccount（Role 限定 verbs get/list/watch/patch/update，完整 RBAC 示例见笔记 12.3 节）。凭证泄露的爆炸半径锁死在一个 namespace，且随时可 delete rolebinding 吊销。prod 部署再叠一个 input 人工审批。

7.4 弹性伸缩：HPA 不是配上就完事

前提：requests 必须配准（按 P95 实际用量）——HPA 的利用率是 实际用量 / requests，requests 瞎填，扩缩时机全错。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: videomart-videocloud }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: videomart-videocloud }
  minReplicas: 3        # 生产最小副本 ≥ 2，单副本没资格谈弹性
  maxReplicas: 20       # 按下游容量倒推（DB 连接数 / 每 Pod 连接数）
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 60 } }
  behavior:             # 快扩慢缩
    scaleUp:
      stabilizationWindowSeconds: 0
      policies: [{ type: Percent, value: 100, periodSeconds: 60 }]   # 每分钟最多翻倍
    scaleDown:
      stabilizationWindowSeconds: 300                                # 缩容观察 5 分钟
      policies: [{ type: Pods, value: 1, periodSeconds: 120 }]

配套三条：HPA 必搭 PDB（防节点维护+缩容+发布叠加把服务缩没）；GitOps 场景 Deployment YAML 别写死 replicas（否则 ArgoCD 每次同步把 HPA 扩的副本压回去）；HPA 管 Pod、Cluster Autoscaler 管节点，两层都要配，流量可预期的业务用 KEDA 定时伸缩提前备容量。

7.5 灰度发布：现有流程加两个 stage 就能支持

前面几节的设计纪律已经埋好了灰度所需的前提：模板里 Deployment 命名带版本（videomart-videocloud-${VERSION}）、Pod 打 app + version 双标签，而 Service 的 selector 只选 app——新旧两个 Deployment 可以并行存在，Pod 同时挂在同一个 Service 下。在这个基础上，灰度有两级做法：

第一级：副本级灰度（零新组件）。 渲染同一份模板，只换 VERSION 和 REPLICAS，拉起 1 个新版本副本与旧版并存——流量比 ≈ 副本比（3 旧 + 1 新 ≈ 25% 流量进新版）：

VERSION=v6.0.5.0 REPLICAS=1 IMAGE=$IMAGE:$TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml \
    | kubectl --kubeconfig=$KUBECONFIG apply -f -

第二级：权重级灰度（精确比例）。 新旧版本各起一个 Service（selector 分别锁定各自 version），用 Gateway API 的 HTTPRoute backendRefs 配 weight: 95 / 5，或上 Istio VirtualService 按权重/请求头分流。要「只让内部员工进新版」这类按用户维度的灰度，只能走这一级。

流水线形态——在「变更单执行」和「全量部署」之间插入灰度段：

graph LR
    A[变更单执行] --> B[部署 canary<br/>1 副本或 5% 权重]
    B --> C[观察期<br/>指标对比 / 人工 input]
    C -->|正常| D[全量滚动更新<br/>删除 canary]
    C -->|异常| E[删除 canary<br/>流量即刻回稳]

要点四条：

灰度期新旧版本同时在线，DB/Nacos 变更必须向后兼容——changelog「只增不改」的纪律正是为此准备的；不兼容的变更没有资格灰度。
观察期看指标不看感觉：canary 的错误率、P99 延迟与 stable 对比，Prometheus 按 version 标签分组就能出数——这就是 Pod 要打 version 标签的另一个理由。观察期可以是定时（如 10 分钟）加 Jenkins input 人工确认。
回滚动作极轻：删掉 canary Deployment，Service selector 自动不再选中它，秒级完成，不用动旧版本一根毫毛。
Nacos 配置也能灰度：配置支持按 IP/标签灰度下发，配置类变更先推给 canary 实例验证，再全量。

7.6 实操：给新版本分 20% 流量的完整跑法

以「线上 v6.0.4.0 共 4 副本，给 v6.0.5.0 分 20% 流量」为例，两种做法选一。

做法 A：副本比例近似（4 旧 + 1 新 ≈ 20%）。改动最小，适合服务间（东西向）流量或没有网关层权重能力的场景：

# 1. 变更单已执行完毕（DB/Nacos，向后兼容）
# 2. 起 1 个新版本副本（与旧版并存，同一个 Service 下）
VERSION=v6.0.5.0 REPLICAS=1 IMAGE=$IMAGE:$NEW_TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml | kubectl apply -f -
kubectl rollout status deployment/videomart-videocloud-v6.0.5.0 --timeout=300s

# 3. 观察：Prometheus 按 version 分组对比错误率 / P99

# 4a. 正常 → 全量：新版本扩到满配，再删旧版本
VERSION=v6.0.5.0 REPLICAS=4 IMAGE=$IMAGE:$NEW_TAG \
    envsubst < k8s_deploy/k8s-deployment-videomart-videocloud.yaml | kubectl apply -f -
kubectl rollout status deployment/videomart-videocloud-v6.0.5.0 --timeout=300s
kubectl delete deployment videomart-videocloud-v6.0.4.0

# 4b. 异常 → 回滚：删掉 canary 即可，旧版全程没动过
kubectl delete deployment videomart-videocloud-v6.0.5.0

做法 B：HTTPRoute 权重精确 20%。适合入口（南北向）HTTP 流量。需要两个按 version 锁定 selector 的 Service：

# stable 和 canary 各一个 Service，selector 分别锁死版本
# videomart-videocloud-stable:  selector { app: videomart-videocloud, version: v6.0.4.0 }
# videomart-videocloud-canary:  selector { app: videomart-videocloud, version: v6.0.5.0 }
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: videocloud-route }
spec:
  parentRefs: [{ name: prod-gateway }]
  hostnames: ["videocloud.example.com"]
  rules:
    - backendRefs:
        - { name: videomart-videocloud-stable, port: 9577, weight: 80 }
        - { name: videomart-videocloud-canary, port: 9577, weight: 20 }

调比例就是改 weight（20% → 50% → 100%)，每次 kubectl apply 即时生效。全量后把 stable Service 指向新版本、删掉 canary，路由权重归位。

做法 B 有一个必踩的坑：原来那个 selector 只选 app 的 Service，灰度期间会同时选中新旧 Pod——HTTPRoute 里 20% 的权重之外，走老 Service 的内部调用方还在按副本比随机进新版，等于流量叠加失控。所以权重灰度前，必须把老 Service 的 selector 也加上 version 锁到旧版，或者干脆只保留 stable/canary 两个 Service。

对应的 Jenkinsfile 就是在「变更单执行」后加两个 stage：

stage('灰度 20%') {
    steps { sh 'deploy-canary.sh $NEW_TAG 20' }   // 上面做法 A/B 的脚本化
}
stage('灰度观察') {
    steps {
        sh 'check-canary-metrics.sh'              // 错误率/P99 对比，超阈值非零退出
        input message: '灰度指标正常，是否全量？'    // 人工确认，prod 必备
    }
}
stage('全量') { steps { sh 'promote-canary.sh $NEW_TAG' } }
post { failure { sh 'cleanup-canary.sh || true' } }  // 任何失败自动清理 canary

八、配置治理：文档化与三环境一致性

8.1 配置文档化：阈值不再是「口口相传」

症状：限流阈值为什么是 500 不是 1000，只有离职的那个人知道。解法：每个服务在仓库里维护 CONFIG.md，强制四列——配置项 / 含义 / 当前值 / 取值依据与影响面：

配置项	含义	当前值	取值依据与影响面
`upload.retryCount`	上传重试次数	5	对象存储偶发抖动 P99 在 3 次内恢复；超过 5 次基本是故障，应快速失败
`upload.chunkSize`	分片大小	5MB	内网带宽实测拐点；调大加剧内存压力

纪律三条：配置项三处一致（Git 里的值、CONFIG.md、代码注释，评审时卡点检查）；阈值必须写取值依据（拍脑袋的值两个版本后就成了没人敢动的屎山）；开关必须有退役计划（全量后一个迭代内删除）。进阶：用 JSON Schema 在推送 Nacos 前校验类型和取值范围，低级错误 CI 阶段拦住。

8.2 三环境一致性：写法一致，取值注入

「在测试环境是好的」的根源：各环境配置是各自维护的副本。解法前面已经埋下——仓库里只有一份参数化模板和变更单，差异压缩成发布时注入的参数：

差异项	注入方式	维护者
namespace、集群地址	CD 环境参数	CD 管理员
副本数、资源 requests/limits	CD 环境参数	CD 管理员
DB 账号、密钥、合作方地址	Jenkins 凭据 → envsubst	CD 管理员（开发者不可见）
业务阈值、特性开关	changelog 变更单，三环境执行同一份	开发者（评审把关）

「写法」必须三环境一致，「取值」本来就该不同。再加两道保险：发 prod 前用各环境参数分别渲染同一份模板并 diff（源头只有一份，diff 干干净净只有几行）；每周漂移检测，发现有人手工改过线上配置就告警（上 ArgoCD 后免费获得）。

九、行业动态：2025–2026 值得关注的变化

GitOps 成默认答案：Jenkins 只构建推镜像，集群内 ArgoCD 从 Git 同步部署——CI 不再需要生产集群凭证，安全性质变。
Gateway API 取代 Ingress：后者已停止演进，新项目别再用它起头。
供应链安全成必修：cosign 签名、SBOM、SLSA 框架已进入金融政企招标要求。
CI 引擎分化：Tekton、Dagger 各有拥趸，GitHub Actions 吞噬中小团队；Jenkins 份额缓降，但存量企业和内网仍是主力。
AI 进流水线：CI 失败日志自动归因、pipeline 脚本生成评审已经实用；「AI 自动决定发布」不建议——爆炸半径需要人负责。

十、思考与感悟

1. 流水线的本质是「把运气变成流程」。 手工发布的质量取决于值班同学当晚的状态。流水线的价值不是快，是把「老司机会记得检查、新人一定会漏」的 20 个检查点固化成代码——先消灭方差，其次才是耗时。

2. 最贵的知识是顺序和兼容。 DB 先于应用、配置先于重启、破坏性变更拆两次——背后是同一个认知：发布中系统处于新旧混合的中间态，所有设计都要保证中间态可用。蓝绿、金丝雀、滚动更新都只是它的具体实现。

3. 验证深度决定发布频次。 没有可靠自动验证 → 发布靠人肉兜底 → 怕 → 少发 → 单次变更量大 → 更怕，恶性循环。打破循环的入口就是把验证做深：rollout 阻塞、冒烟、自动回滚。验证越可信，发布越敢小而频。

4. 配置有权限边界。 「引用关系」进 Git，「真实值」进凭据系统，且只有 CD 管理员能碰。这条边界一开始不划，等密钥躺在几百人可见的仓库里再补救就晚了。

十一、避坑清单（速查）

Webhook 触发，不用轮询；Controller 不跑构建；agent 用一次性 Pod + 依赖缓存 PVC + CI 专用 SSD 节点池；无依赖的部署步骤并行。
镜像 tag = git commit 短哈希，杜绝 latest；仓库开 tag 不可变；cosign 签名。
DB 与 Nacos 变更一律走 changelog 变更单，随代码评审，CD 按序幂等执行；控制台手工改属违规。
数据库变更只增不改；破坏性变更拆两次发布；执行过的 changeSet 绝不许改。
变更单和模板只写 ${占位符}；真实密钥只在 Jenkins 凭据和 K8s Secret，只有 CD 管理员可见；服务一律 envFrom/secretRef 引用。
每个服务维护 CONFIG.md 四列（配置项/含义/当前值/取值依据）；开关有退役计划。
仓库只存一份环境无关模板，环境差异由 CD 注入；发 prod 前渲染结果 diff；每周漂移检测。
ConfigMap 更新后跟一次滚动更新（env 注入和 subPath 都不自动生效）。
Deployment 必配 readinessProbe + maxUnavailable: 0 + preStop 延迟；revisionHistoryLimit 别设 0。
验证三件套：rollout status → 冒烟 → 失败自动 undo + 告警。
HPA：requests 按 P95 配准；minReplicas ≥ 2、maxReplicas 按下游容量倒推；快扩慢缩 + PDB；GitOps 场景别写死 replicas。
灰度发布：Service selector 只选 app、Deployment 按版本并行，先副本级灰度，要精确比例再上 HTTPRoute 权重；观察期看 version 分组的指标；回滚 = 删 canary。
Jenkins 用最小权限 ServiceAccount，prod 加 input 审批；新系统对外暴露用 Gateway API；渲染快照进发布记录库，为 GitOps 铺路。

参考资料：

《Kubernetes 学习总结与避坑指南》（本站 kubernetes-authoritative-guide-notes.md）：ConfigMap 注入机制、RBAC 最小权限、rollout 验证的完整细节

Jenkins 官方文档 / Liquibase / Nacos OpenAPI

Kubernetes Gateway API / ArgoCD / SLSA

《持续交付》笔记：每步可退，把集成风险日常化

Fri, 08 Sep 2023 10:40:00 +0800

《持续交付》笔记：每步可退，把集成风险日常化

《持续交付》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）是 Jez Humble 和 David Farley 2010 年的作品，拿过 2011 年的 Jolt 大奖。这本书可以说是 DevOps 运动的奠基文献之一——后来《DevOps Handbook》《Accelerate》这些书，根子上都能追溯到这里。

全书 500 多页，核心其实就一个问题：怎么让"把软件放到生产环境"这件事，从一年几次的高风险仪式，变成随时可以按一下按钮的平常操作？

我读完最大的感受是：这本书表面讲工具和流程，骨子里讲的是一种风险管理哲学——不消除风险，而是把风险切碎、摊平到每一天。这篇笔记是我消化后的版本，不是章节摘要。

一、全书的核心主张：一张图看懂

先把整本书的骨架画出来，后面每节都能对号入座：

flowchart TB
    subgraph P["核心哲学：把风险日常化"]
        PHIL["'If it hurts,<br/>do it more often'"]
    end
    subgraph PL["部署流水线 Deployment Pipeline"]
        S1["① 提交阶段<br/>编译 + 单元测试<br/>分钟级反馈"]
        S2["② 自动化验收<br/>验收测试 + 容量/安全测试<br/>小时级反馈"]
        S3["③ 手工验证<br/>UAT / 探索性测试 / 演示"]
        S4["④ 发布<br/>点按钮，随时可发"]
        S1 --> S2 --> S3 --> S4
    end
    subgraph F["支撑地基"]
        F1["配置管理<br/>一切皆版本控制"]
        F2["自动化测试金字塔"]
        F3["主干开发 + 特性开关"]
    end
    PHIL --> PL
    F --> PL

这本书的立论链条是这样的：

软件发布之所以痛苦，是因为它罕见——几个月才发一次，每次集成了几百个变更，出问题没法定位；
解决思路不是"更小心地发布"，而是更频繁地发布——频率高了，每次变更就小，小了就好定位、好回滚；
要支撑高频发布，必须有一条自动化的部署流水线，让每个提交自动走完所有质量关卡；
流水线要可靠，底下得有配置管理、自动化测试、增量式开发三块地基。

感悟：这个逻辑其实和健身一个道理——很久不运动，偶尔跑一次十公里肯定受伤；每天跑两公里反而没事。发布也一样，“少做"不是降低风险的办法，“把每次做小"才是。

二、“If it hurts, do it more often”：全书最反直觉的一句话

书里有一句被广泛引用的话：“如果某件事让你痛苦，那就更频繁地去做它”（If it hurts, do it more often, and bring the pain forward）。

直觉上，痛苦的事应该少做。但作者的论证是：痛苦的根源是批量太大、间隔太久。以集成为例：

两个程序员各写两周代码再合并，冲突一大堆，合并花两天——于是大家说"少合并”；
正确的解法恰恰相反：每天合并多次，每次冲突只有几行，顺手就解了。

同样的道理适用于：数据库迁移、发布上线、甚至和客户的沟通。频率提高会逼着你把流程自动化、把每一步做小，而"小"本身就是最好的风险对冲。

踩坑记录（书外）：我待过的一个团队，发布周期是一个月一次，每次发布日都要通宵，发布完还要留人值班一周"灭火”。所有人的共识是"发布太危险，得再慎重些"——于是变更冻结期越来越长，每次积压的变更越来越多，发布越来越危险。这是典型的用制造问题的方式解决问题。后来换了 CTO 强推两周一次、再到一周一次，逼着团队把部署脚本自动化、把回滚预案做出来，半年后发布变成了一个普通下午就能做的事。

感悟：“痛苦"是个信号，但它指示的方向经常和直觉相反。看到团队里某件事人人回避，正确的反应不是绕着走，而是问：能不能把它自动化、高频化、常态化？

三、部署流水线：每个提交都是可发布候选

这是全书最核心的工程概念。部署流水线（deployment pipeline）的正式定义是：从代码提交到生产发布之间，所有验证步骤的自动化呈现。

flowchart LR
    C["提交 Commit<br/>触发流水线"] --> B["① 构建 + 单元测试<br/>编译 / 静态检查<br/>几分钟内出结果"]
    B --> A["② 自动化验收测试<br/>面向业务的端到端场景<br/>在类生产环境跑"]
    A --> U["③ 手工验证<br/>UAT / 探索性测试<br/>非功能需求确认"]
    U --> R["④ 发布<br/>同一构建产物<br/>一键部署到生产"]
    B -.->|"失败即止"| X["❌ 流水线终止<br/>修复优先于新功能"]
    A -.->|"失败即止"| X

几个关键点，都是容易理解偏的：

3.1 每个阶段都是质量关卡，失败即止

流水线的本质是递进式的信心建设：便宜的、快的测试放前面（单元测试几秒出结果），贵的、慢的放后面（验收测试、性能测试）。任何一个阶段失败，这个构建版本就"死"了，不进入下一阶段。

这带来一条重要的团队纪律：流水线红了，修复它就是最高优先级——比写新功能优先。因为流水线红着的时候，后面所有人的提交都拿不到反馈，等于团队集体失明。书里管这个叫"不要带着broken的构建回家”。

3.2 每次提交都产生一个可发布候选

这句话值得单独强调：流水线的每个成功产出都是 release candidate。注意是"候选"不是"一定发"——它保证了技术上随时可以发，发不发是业务决策（这点在第六节展开）。

做到这一点有个硬要求：部署到每个环境的必须是同一个构建产物。测试环境用 A 包、生产环境重新打一个 B 包，等于你在生产环境跑了一个从没被验证过的东西——测试全白做了。正确的做法是：构建只发生一次，产出的二进制包（jar、镜像）在流水线里逐级晋升（promote），环境差异全部由外部配置注入。

3.3 流水线的反馈速度是硬指标

提交阶段要在几分钟内给出结果——慢了就没人愿意等，大家开始绕过流程。验收测试可以慢一些，但也要控制在小时级。如果一个阶段慢到天天被跳过，那它不是"严格"，是"无效"。

感悟：流水线画出来都不难，难的是维护它的"纪律成本"。红了几天的流水线比没有流水线更糟——它教会团队的是"告警可以无视"。

四、自动化测试：金字塔而不是冰淇淋筒

书里的测试分层思想，后来被大家画成了著名的"测试金字塔"（Mike Cohn 提出，本书把它发扬光大了）：

flowchart TB
    subgraph 金字塔["自动化测试金字塔（数量：下多上少；成本：下低上高）"]
        E2E["少量：端到端 UI 测试<br/>慢、脆、维护贵"]
        ACC["适量：验收/服务层测试<br/>面向业务行为<br/>不依赖 UI"]
        UNIT["大量：单元测试<br/>毫秒级、定位精准"]
    end
    UNIT --> ACC --> E2E

书中几个至今仍然尖锐的观点：

验收测试要用业务语言写，由开发者、测试、业务三方共同拥有。它不只是测试，更是"可执行的规格说明书"——需求变了，先改验收测试；
别把测试挂在 UI 上。UI 是系统里最不稳定的层，通过 UI 驱动的测试又慢又脆。验收测试应该打在 UI 之下的服务/API 层；
手工测试不会被消灭，但角色变了：从"重复执行回归用例"变成"探索性测试、可用性评估"——机器做重复的，人做需要判断力的。

反面形态叫"冰淇淋筒"：大量手工测试 + 一堆脆弱的 UI 自动化 + 几乎没有单元测试。症状是测试跑一遍要一整天、失败了大半天定位不到问题、最后团队对测试结果失去信心开始无视红灯。

感悟：测试金字塔真正的价值不在"比例"，在它背后的经济学：反馈越快、定位越准的测试越便宜，应该最多。所有"冰淇淋筒"团队的问题，本质都是把测试成本结构搞反了。

五、增量式发布：把风险一刀一刀切小

这部分是全书我最服气的一章——它回答了一个实际问题：大功能开发要好几个月，总不能这几个月不发版吧？书里给的答案是把"部署"和"发布"解耦。

5.1 主干开发 + 特性开关：和长寿命分支说再见

业界常见的做法是"功能分支"：每个大功能拉一个分支，开发几个月再合并。书里的态度很明确：长寿命分支是持续交付的头号敌人。分支活得越久，合并那天的集成爆炸越大——你只是把集成风险攒起来，并没有消除它。

替代方案是主干开发（trunk-based development）：所有人都频繁提交到主干（至少每天），没做完的大功能用**特性开关（feature toggle）**藏起来——代码已经在生产环境，但功能入口被开关挡住，用户看不见。

这样做的好处是双重的：

集成每天都在发生，冲突永远是小的；
“部署新代码"和"向用户开放功能"变成了两件独立的事。

代价也要认账：开关本身是技术债，上线后要记得清理；半成品代码要保证"编译得过、不破坏现有行为”，对代码组织（抽象分支、按业务边界拆分）有要求。

5.2 蓝绿部署与金丝雀发布

发布阶段的两个经典模式：

蓝绿部署（blue-green deployment）：维护两套生产环境。当前流量在"蓝"，新版本部署到"绿"，验证没问题就把流量切过去。出问题？切回来就是秒级回滚。
金丝雀发布（canary release）：先把新版本暴露给一小部分流量（比如 1% 的用户或一台服务器），盯着错误率和关键指标，没问题再逐步扩大范围。名字来自煤矿里的金丝雀——鸟先下井，出事人有时间撤。

两者的共同点：回滚能力内建在发布机制里，而不是出事后临时想办法。书里有句话大意是：发布计划里最重要的一条是回滚计划，而回滚计划必须真的演练过才算数——没演练过的回滚方案约等于没有。

5.3 数据库变更：expand-contract 模式

蓝绿部署最怕的拦路虎是数据库：两套环境共用一个库，schema 一变，新旧代码没法同时跑。书里的解法是expand-contract（扩张-收缩）模式：

Expand：先做一次只做"加"的变更——加新列、加新表，旧的什么都不动。这次变更对旧代码完全兼容，可以安全部署；
迁移：应用代码改为同时读写新旧结构（或双写），后台任务把存量数据搬过去；
Contract：等所有在用版本都不依赖旧结构了，再单独做一次变更删掉旧列、旧表。

核心思想一句话：每一次变更都向前向后兼容，让 schema 演进和应用部署可以分开走。这也解释了为什么"上线一个大变更顺便重构一下表结构"是事故高发操作——你把两个本可以解耦的风险捆在了一起。

六、配置与环境：把环境也当代码管

这本书反复强调的一个纪律是：一切进版本控制——不只是源代码，还包括：

构建脚本、部署脚本；
应用配置（环境相关的那部分参数化）；
数据库迁移脚本；
环境本身的定义（后来演化成了 Infrastructure as Code，IaC）。

理由很朴素：如果环境的搭建靠"运维同学的记忆和一台手工调出来的服务器"，那你的测试环境和生产环境一定存在没人知道的差异，而每个差异都是一颗雷。书里对这种手工维护的服务器有个后来的流行叫法——宠物（pets） vs 牲畜（cattle）：宠物有名字，病了要治；牲畜只有编号，病了换掉重来。环境应该朝"牲畜"方向走：不可变、可重建、随时销毁再拉起。

配置管理上的一条实用原则：把"什么变"和"什么不变"分开。代码和各环境共用的配置进版本库，环境差异（连接串、密钥、开关值）由部署流程注入。同一份代码 + 不同的配置 = 不同的环境，而不是各环境维护不同的代码分支。

七、发布是业务决策，不是技术决策

这是全书观点中我认为最容易被低估、也最改变组织行为的一条。

传统模式下，“什么时候发布"是技术团队说了算的——因为只有他们觉得"差不多了"才敢发，发布本身是高危操作，自然由承担风险的人拍板。

持续交付把这件事倒过来：当流水线保证了每个提交技术上都可发布之后，“何时发布、对谁发布"就纯粹变成了业务问题——市场时机、合规窗口、用户沟通节奏，都应该由产品和业务来定。技术团队的职责是保证这个按钮随时可以按、按了不出事、出了事能秒回。

这也是特性开关、金丝雀发布的深层价值：它们把"发布"从技术动作变成了业务杠杆——按客户群分批开放、给内部员工先试用、关键客户定制节奏，都是业务手段而不是工程手段。

感悟：很多团队的技术债，根子其实是"发布权力错配”：业务想要的速度给不了，因为发布在技术上做不到随时可做。先把工程能力补到位，权责自然归位。

八、案例：正面与反面

正面：高频部署的先行者

Flickr：2009 年 Velocity 大会上，Flickr 的 John Allspaw 和 Paul Hammond 做了那场著名演讲《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》——每天 10 次以上部署。这个演讲被公认为 DevOps 运动的引爆点之一。他们的经验核心正是本书的思想：小批量、特性开关、完善的监控和一键回滚，让高频发布不是冒险而是常态。
Amazon：以部署频率著称。后来 Amazon 高管在公开分享中提到过，2011 年前后 Amazon 平均每隔十几秒就有一处变更部署到生产（这个数字随年份增长，到 2014 年的分享里已经是秒级）。支撑它的是高度自动化的流水线和"谁构建谁运行"的服务负责制。

这些公司证明了一件事：部署频率和生产稳定性不是此消彼长，而是可以同向增长的——前提是自动化、小批量、快速回滚三件套齐全。后来 DORA 的年度行业报告用数据反复验证了这一点：部署频率最高的那批组织，变更失败率反而最低、恢复最快。

反面：Knight Capital，45 分钟 4.4 亿美元

2012 年 8 月 1 日，美国做市商 Knight Capital 发生了一起教科书级的部署事故，大约 45 分钟内亏损约 4.4 亿美元，公司险些倒闭，最终被收购。

事后的公开报道和美国 SEC 的调查文件还原了链条：

他们为新的"零售流动性计划”（Retail Liquidity Program）功能做部署，生产环境共 8 台服务器，人工部署只更新了 7 台，漏了一台；
新代码复用了一个旧的标志位（flag），而这个标志位多年前曾用于一个早已弃用的功能"Power Peg"——沉睡的旧代码没有被删除，只是被开关挡着；
那台漏更新的服务器上，旧标志位被请求触发，沉睡多年的 Power Peg 代码被唤醒，开始以错误逻辑疯狂下单；
现场没有一键回滚机制，工程师手忙脚乱，花了 40 多分钟才止住。

用本书的概念框架看，这个事故几乎踩中了所有反面：

部署靠人工——8 台漏 1 台是人工部署的必然概率问题，不是偶发失误；
死代码 + 标志位复用——特性开关没被治理，旧开关复用、死代码不清理，开关从保护伞变成了定时炸弹；
没有快速回滚——如果有一键回滚，损失可能是零头。

感悟：这个案例我逢人就讲，因为它完美诠释了本书的中心论点：事故的根源不是"发布太多"，而是发布过程不可重复、不可回滚。Knight Capital 一年也发不了几次版，“少发布"没有保护他们。

九、思考与感悟

“持续"是方法，“交付信心"才是目的。 读完回头看，这本书所有技术手段——流水线、金字塔、特性开关、蓝绿——都服务于同一件事：让团队在任何时候都能有底气地说"现在的版本是可发布的”。这种底气本身会改变团队的开发方式：敢重构、敢提交、敢试验。
纪律比工具难买。 流水线的搭建一个 Sprint 就能做完，难的是"红了就停下手头一切去修"这条纪律。工具解决的是"能不能”，纪律解决的是"做不做”。后者只能靠团队共识和管理者背书。
和客户开发方法论同构。 这是我读完联想最多的一点：之前读的创业方法论里，客户开发（Customer Development）讲的是市场侧的小步试错——别闭门造车一年再赌一把大的，把假设拆小，快速放到真实客户面前验证。持续交付是工程侧的同一件事：别把代码攒三个月再赌一次大发布，把变更拆小，快速推到真实环境里验证。一个在验证"需求假设"，一个在验证"代码正确性假设"，底层的认识论完全一致：小批量、快反馈、可回退，用高频试错替代单次豪赌。精益创业（Lean Startup）把这两条线拧在了一起，不是巧合——Eric Ries 本人就是持续部署的早期实践者。
每步可退，才能每步敢进。 “可回滚"听起来是防御性能力，实际上是进攻性能力——只有确信每一步都退得回去，团队才敢把步子迈快。这本书最深的洞察也许就这一句：速度和安全不是天平的两端，可回滚性把它们焊在了同一侧。

本篇小结

部署流水线是核心骨架：提交 → 构建+单元测试 → 自动化验收 → 手工验证/UAT → 发布，每个阶段是质量关卡，失败即止，修复红灯优先于新功能；
哲学上是 “If it hurts, do it more often”：痛苦的事要做小、做勤，风险切碎摊平，而不是攒起来赌一次大的；
每次提交产出可发布候选；同一构建产物逐级晋升，环境差异靠外部配置注入；
测试要金字塔不要冰淇淋筒：单元测试打底，验收测试讲业务语言，UI 测试最少；
主干开发 + 特性开关替代长寿命分支，把"部署"和"发布"解耦；
蓝绿部署和金丝雀发布把回滚能力内建在发布机制里；数据库变更走 expand-contract，每步向前向后兼容；
配置和环境定义全部进版本控制，环境朝"可重建的牲畜"方向走；
发布是业务决策，技术团队的职责是让那个按钮随时可按、按了能回；
收尾的同构关系：客户开发是市场侧的小步试错，持续交付是工程侧的小步试错，精益创业把两者拧成一股。