1. 治理共性模型：推进需要证据，失败需要可解释路径

跨平台对照的关键不是“哪个工具更花哨”，而是抽象出三个共性对象： 环境（Environment）：你把发布放到哪里；审批（Approval/Gate）：你凭什么允许放行； 回滚（Rollback）：如果失败了，你如何回到已知安全状态。 最好把它们写成同一张图，在任何平台里都能“找到对应元素”。

2. 环境（Environment）怎么跨平台表达？

环境不是“一个字符串”。在工程里它通常绑定： 部署目标（k8s namespace / cluster / VM group）、 凭据与密钥（secrets、config 注入）、 策略与窗口（sync windows、资源配额、审批要求）。 因此跨平台迁移时，先确定你的环境边界长什么样，再去看工具如何映射。

2.1 GitHub Actions：用 Environments 把目标绑定起来

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://prod.example.com
    steps:
      - uses: actions/checkout@v4
      - run: echo "Deploy to production"

2.2 GitLab CI：用 environments 把部署名与 URL 固化

deploy_prod:
  stage: deploy
  environment:
    name: production
    url: https://prod.example.com
  script:
    - echo "Deploy to production"

2.3 Jenkins：环境用 stage + 凭据组表达

pipeline {
  agent any
  stages {
    stage('Deploy to Prod') {
      steps {
        withCredentials([string(credentialsId: 'kubeconfig-prod', variable: 'KUBECONFIG')]) {
          sh 'echo "Deploy to prod"'
        }
      }
    }
  }
}

3. 审批（Approvals/Gates）：如何跨平台做“证据驱动的放行”

审批的正确姿势不是“等人点按钮”，而是把它设计成一个 可验证的决策点： 触发条件（例如测试通过、SLO 达标）、审批对象（谁可审批）、时间限制（避免长时间悬挂）、以及审批理由/证据（audit）。 不同平台实现略有差异，但都能抽象成 gate：input → decision → record。

3.1 GitHub Actions：Required reviewers（通过 Environments 配置）

# This is configuration in GitHub UI for the environment's required reviewers.
# The workflow references it via environment.name.
environment:
  name: production

3.2 GitLab CI：用 manual job 做 gate

deploy_prod:
  stage: deploy
  when: manual
  allow_failure: false
  script:
    - echo "Deploy to prod after manual gate"

3.3 Jenkins：用 input step + timeout

stage('Promote to Prod') {
  steps {
    timeout(time: 30, unit: 'MINUTES') {
      input message: 'Approve production deployment?', ok: 'Deploy'
    }
    sh 'echo "Deploy to prod"'
  }
}

3.4 GitOps：用 sync policy / manual sync 实现 gate

# Example: Argo CD Application with automated disabled (manual sync gate)
spec:
  syncPolicy:
    automated: null
    syncOptions:
      - CreateNamespace=true

4. 回滚（Rollback）：跨平台统一成“回到已知安全状态”

回滚必须解决两个问题：回到什么（上一版 revision / 上一个镜像 tag / traffic 权重拉回）、以及回滚是否安全（依赖兼容：DB 迁移是否可逆、配置是否同步、以及回滚后是否复核）。 最好的工程做法是把回滚也当成 stage：回滚后再跑一次最小验证（smoke checks 或指标门禁）。

4.1 GitHub/GitLab/Jenkins：re-deploy previous artifact

# Principle: pin artifact version (image tag / build id) then redeploy.
export IMAGE_TAG="v1.2.2"
kubectl set image deployment/payments payments=${IMAGE_TAG}

4.2 GitOps：回滚就是把 Application 指向历史 revision

# Example (Argo CD CLI illustrative)
argocd app history payments-api
argocd app rollback payments-api <revision-id>

5. 落地建议：把治理变成“可审计的流水线证据”

为了让跨平台经验真正迁移，建议你在治理层定义统一的证据字段： environment target、approved by、revision pinned、gate reason、rollback method、verify outcome。 不管你用的是 Jenkins 的输入、GitLab 的 manual job、还是 Argo CD 的 sync history，这些字段都应该能在日志/事件里找到。

6. 本章清单

1. 能抽象出 CD 治理的共性模型：environment / approval gate / rollback lane。
2. 能在 GitHub Actions、GitLab CI、Jenkins、GitOps 中分别找到“环境绑定”的对应物。
3. 能用 gate 设计 evidence-driven approval，并确保 gate 绑定到具体 revision。
4. 能用统一思路描述回滚：revert / previous revision / traffic back，并强调 post-rollback verify。
5. 能制定不可逆副作用的回滚边界（尤其 DB migrations）并在 runbook 里写清。
6. 预告下一章：把这些治理与可观测性/错误预算联动，让自动化止损更可信。