CI/CD 基础回顾：持续集成与持续部署

做灰度回滚，说白了就是跟 CI/CD 打交道。如果你连持续集成和持续部署的底子都没打牢，后面谈分层支持那就是空中楼阁。我带团队这么多年，见过太多人把 CI 和 CD 混为一谈，结果回滚的时候手忙脚乱。

持续集成 (CI) 到底在干什么？

持续集成，就是让代码在合并到主干之前，能自动编译、测试、打包。我习惯用一个比喻：你写文章，写完一段就让别人帮你读一遍，发现问题马上改。而不是写了十页再通读，那样改起来成本太高。

CI 的核心价值就两点：

• 尽早发现问题 — 代码一提交就触发构建和测试，bug 半小时内就能暴露。
• 保证主干稳定 — 通过门禁机制，不合格的代码压根进不了主干。

持续部署 (CD) 不只是“自动发布”

持续部署分两种：Continuous Delivery 和 Continuous Deployment。前者是“随时可以发布到生产”，需要人工按个按钮；后者是“自动发布到生产”，代码一过门禁，直接上线。

说实话，我在金融项目里很少用全自动 CD，风险太高。但我们做灰度发布时，CI 层面先做分层，CD 层面再做分批推送——这套组合拳非常有效。

# 一个简化的 CD Pipeline 配置示例（Jenkinsfile）
pipeline {
    agent any
    stages {
        stage('Build & Unit Test') {
            steps {
                sh 'make build'
                sh 'make test'
            }
        }
        stage('Containerize') {
            steps {
                sh 'docker build -t myapp:${BUILD_TAG} .'
            }
        }
        stage('Deploy to Staging') {
            steps {
                sh 'kubectl apply -f k8s/staging.yaml'
            }
        }
        stage('Smoke Test') {
            steps {
                sh 'curl -f http://staging.myapp.com/health'
            }
        }
        stage('Deploy to Canary') {
            when { branch 'main' }
            steps {
                // 灰度部署逻辑
                sh 'kubectl apply -f k8s/canary.yaml'
            }
        }
        stage('Deploy to Production') {
            when { branch 'main' }
            input '确认发布到生产？'
            steps {
                sh 'kubectl apply -f k8s/prod.yaml'
            }
        }
    }
}

Pipeline 核心要素

Pipeline 就是 CI/CD 的骨架。不管用哪个工具，核心要素都跑不出下面这五样：

有一次我接手一个项目，Pipeline 里十几个阶段全写在一个文件里，没有分层。灰度回滚时想只回滚某个微服务，结果整个流水线都重跑了一遍，耗时两小时。后来我把它拆成了三层：基础构建层、灰度验证层、生产部署层。每个层独立触发，互不阻塞。

常用 CI 工具对比

市面上的工具多得眼花缭乱，其实挑对了能用好多年。我简单列一下用过的几个主流工具：

你想想看，灰度回滚这件事，如果没有分层清晰的 CI 支持，回滚就成了“全量回滚”或者“手动回滚”。CI 在灰度场景下的角色，就是提供可复现的构建、可追溯的制品、可控制的部署。这三样缺一不可。