1.3 核心原则与生命周期

1.3 核心原则与生命周期

本节摘要：CI/CD 八大原则——自动化、版本控制、频繁集成、构建一次随处部署、尽早失败等——构成流水线设计的检查清单。本节用 Jenkins Declarative Pipeline 把原则映射到 stage，并梳理从 commit 到 rollback 的完整生命周期。

你能学到什么

阅读完本节，你应当能够：

1. 列举并解释 CI/CD 的八项核心原则
2. 将每项原则对应到流水线中的具体配置
3. 描述典型 CI/CD 生命周期的九个阶段
4. 设计「尽早失败」的 stage 顺序

一、八项原则 = 八条流水线自检

动手优先：下面 Jenkinsfile 几乎覆盖全部原则——先通读，再对照表格找对应关系。

pipeline {
  agent any
  options {
    buildDiscarder(logRotator(numToKeepStr: '20'))
    timeout(time: 30, unit: 'MINUTES')
  }
  stages {
    stage('Checkout')     { steps { checkout scm } }           // 原则2: 版本控制
    stage('Build')        { steps { sh 'mvn -B clean package -DskipTests' } }
    stage('Unit Test')    { steps { sh 'mvn test' } }          // 原则4: 每次提交触发
    stage('Static Scan')  { steps { sh 'mvn sonar:sonar' } }    // 原则7: 质量内建
    stage('Archive')      { steps { archiveArtifacts 'target/*.jar' } } // 原则5: 构建一次
    stage('Deploy Staging') {
      steps { sh './deploy.sh staging target/app.jar' }
    }
    stage('Smoke Test')   { steps { sh 'pytest tests/smoke' } }
  }
  post {
    failure { slackSend color: 'danger', message: "Failed ${env.JOB_NAME} #${env.BUILD_NUMBER}" }
  }
}
​

二、八大原则详解

三、CI/CD 生命周期九阶段

1. 代码提交：开发者 push 或 merge PR——生命周期起点
2. 构建 Build：拉代码、装依赖、编译——CI 服务器 Jenkins/GitLab CI/GitHub Actions 触发
3. 自动化测试：单元→集成→静态分析，快测前置
4. 制品生成：JAR、Docker 镜像推 Nexus/Registry——不可变 tag 用 commit SHA
5. 部署测试环境：自动或按需，跑集成/API 测试
6. 验收与性能测试：E2E、JMeter/k6——CD 阶段门禁
7. 预发验证：类生产环境，UAT 或自动 smoke
8. 生产部署：手动 approve（CD）或自动（CDP）
9. 监控与回滚：Prometheus 告警、kubectl rollout undo

阶段耗时参考（中型 Java 服务）

⚠️ 常见坑：把 E2E 放在 unit test 之前——反馈从 2 分钟变成 30 分钟，开发者开始 skip CI。

💡 关键直觉：「尽早失败」= 把最便宜的测试放最前。单元测试毫秒级，E2E 分钟级；顺序错了，CI 失去意义。

GitHub Actions 生命周期映射

jobs:
  ci:
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test          # 阶段 2-3
      - run: npm run build               # 阶段 4
      - uses: actions/upload-artifact@v4
        with: { name: dist, path: dist/ }
  cd-staging:
    needs: ci
    steps:
      - run: ./deploy-staging.sh         # 阶段 5-7
  cd-prod:
    needs: cd-staging
    environment: production              # 阶段 8 审批
    steps:
      - run: ./deploy-prod.sh
​

原则5「构建一次」的反模式

# 错误：每个环境重新 mvn package
deploy-staging.sh  → mvn package -Dstaging=true
deploy-prod.sh     → mvn package -Dprod=true
# 正确：晋级同一镜像
docker pull myapp:abc123 && deploy to staging
docker pull myapp:abc123 && deploy to prod  # 同一 digest
​

四、生命周期各阶段详解

代码提交阶段开发者须在本地跑 lint 与快测——pre-commit hook 可强制 pytest tests/unit -q 通过才允许 commit。这不是 CI 替代，而是把失败左移到秒级。

构建阶段CI Server（Jenkins 2.x Pipeline、GitLab Runner、GitHub-hosted runner）分配 executor。Runner 应不可变：每次 job 用新容器或 clean workspace，避免上次构建残留污染本次。GitHub runs-on: ubuntu-latest 每次是新 VM。

测试阶段分 fast path 与 slow path。Fast：unit + lint + SAST，目标 5 分钟内。Slow：integration + contract test，可并行。Flaky test 须 quarantine——标记 @pytest.mark.flaky 并单独 job，不阻断主干。

制品阶段成功构建产出 immutable artifact。Java 推 Nexus maven-releases，Docker 推 Harbor registry/app@sha256:digest。制品元数据记录：commit SHA、构建号、依赖 SBOM——供审计与 CVE 追溯。

部署测试环境通常自动——merge main 即 deploy dev/staging。环境须可丢弃：Terraform 或 Helm 从零创建，禁止「祖传 staging 服务器」手工调过配置。

验收性能测试k6/JMeter 在 staging 跑，对比上一版本 P95。劣化超 20% 阻断 prod promote——性能回归与功能回归同等重要。

预发验证最接近 prod：数据量可缩但拓扑一致。UAT 可选手动，自动化 smoke 必选。

生产部署CD 需 approve，CDP 自动。无论哪种，deploy 后 5 分钟 error rate 监控是安全网。

监控回滚Prometheus alert → PagerDuty → runbook 或 auto rollback。Postmortem 24h 内 blameless 完成。

构建一次的技术实现

# 晋级脚本：同一 digest 从 staging 到 prod
DIGEST=$(docker inspect registry/app:abc123 --format='{{index .RepoDigests 0}}')
docker pull $DIGEST
docker tag $DIGEST registry/app:prod-current
kubectl set image deploy/app app=$DIGEST
​

digest 比 tag 更 immutable——tag 可被覆盖，digest 不能。

核心回顾

• 八大原则 是流水线设计 checklist，不是口号
• Jenkinsfile stage 顺序 体现尽早失败：单测先于 E2E
• 生命周期九阶段 从 commit 到 rollback 闭环
• 构建一次随处部署 用 immutable 制品晋级，禁止 per-env 重编译
• webhook 触发 保证每次提交有反馈
• post failure 通知 关闭反馈环
• CD 与 CDP 差别在阶段 8 是否人工

下一章我们进入 CI 实践：版本控制如何触发流水线，构建与测试如何设门禁。