跳到主要内容

制品与部署交付

CI 的终点是"产生可部署的产物并交付到环境"。产物要可追踪（对应代码版本）、可复用（不依赖某个 Workspace）、可回滚（有历史版本）。

本篇目标：能正确归档和发布制品，完成镜像构建推送，用 kubectl / Helm 部署，并制定回滚策略。

1. Artifacts 归档​

stage('归档产物') {
    steps {
        archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
    }
}
手段用途说明
archiveArtifacts归档到 Master体积受磁盘限制，适合小产物、诊断包
制品仓库（Nexus/Artifactory）长期、大体积用 maven deploy / curl 上传
镜像仓库容器镜像见下文
文件服务器 / 对象存储安装包、离线包内网分发
不要只靠 archiveArtifacts 存大产物

archiveArtifacts 全堆在 Master 磁盘，构建一多就爆盘。安装包、镜像层应进制品/镜像仓库。归档到 Master 的只留必要诊断产物，并配置保留策略。

2. 构建并推送镜像​

stage('构建镜像') {
    steps {
        container('docker') {
            withCredentials([usernamePassword(
                credentialsId: 'harbor-registry-auth',
                usernameVariable: 'REG_USER',
                passwordVariable: 'REG_PASS'
            )]) {
                sh '''
                    docker login -u "$REG_USER" -p "$REG_PASS" registry.company.com
                    docker build -t registry.company.com/app/service:v${BUILD_NUMBER} .
                    docker push registry.company.com/app/service:v${BUILD_NUMBER}
                '''
            }
        }
    }
}

2.1 镜像 tag 策略​

策略优点注意
v${BUILD_NUMBER}构建号唯一、单调与代码版本没直接对应
Git 短 SHA与代码一一对应语义不直观
Git Tag（语义化）可读、可回滚需要人工打 Tag 触发
三者叠加兼顾追踪与可读多打几个 tag 成本低
// 推荐组合：SHA + 构建号，release 再打语义 tag
sh """
    docker tag registry/app:${GIT_COMMIT_SHORT} registry/app:latest
"""
镜像可追踪

生产发布的镜像 tag 应能回溯到代码。用 Git SHA 或 Tag 作为 tag 一部分（v1.2.3-a1b2c3d），排障时才能知道线上跑的是哪次提交。

3. 部署到 Kubernetes​

3.1 直接 kubectl​

stage('部署到生产') {
    when { branch 'main' }
    steps {
        withCredentials([file(credentialsId: 'kubeconfig-prod', variable: 'KUBECONFIG')]) {
            sh '''
                kubectl --kubeconfig "$KUBECONFIG" -n prod \
                  set image deployment/backend backend=registry/app:v${BUILD_NUMBER}
                kubectl --kubeconfig "$KUBECONFIG" -n prod \
                  rollout status deployment/backend --timeout=5m
            '''
        }
    }
}

3.2 用 Helm 升级​

sh '''
    helm upgrade --install backend ./deploy/helm/backend \
      -n prod \
      --set image.tag=v${BUILD_NUMBER} \
      --wait --timeout 10m
'''

3.3 更新 Git 让 Argo CD 同步（GitOps 模式）​

stage('更新 Git 镜像 tag') {
    steps {
        sh '''
            sed -i "s#tag: .*#tag: v${BUILD_NUMBER}#" config/overlays/prod/image.yaml
            git add config/overlays/prod/image.yaml
            git commit -m "release: backend v${BUILD_NUMBER}"
            git push
        '''
    }
}

Jenkins 只负责"更新声明"，Argo CD 检测到 Git 变更后自动同步（详见 Argo CD 章节）。这避免了 Jenkins 直连集群的权限面，也符合 GitOps 单一事实源。

4. 发布与回滚​

4.1 发布前检查​

  • 镜像已推送，tag 可追踪；
  • 清单来自 Git，kubectl diff 确认变更范围；
  • 探针、资源、PDB 已就绪（见 Kubernetes 手册）；
  • 确认回滚路径（镜像历史 tag 或 Git 回滚）。

4.2 回滚策略​

场景回滚方式
Deployment 版本异常kubectl rollout undo deployment/backend -n prod
镜像 tag 用错kubectl set image 换回上一个 tag
GitOps 模式回滚 Git 提交，Argo CD 自动同步回来
数据库不兼容不能靠回滚 Pod，需先设计迁移回滚
stage('失败自动回滚') {
    steps {
        script {
            try {
                sh 'kubectl rollout status deployment/backend -n prod --timeout=5m'
            } catch (e) {
                echo '部署超时，触发回滚'
                sh 'kubectl rollout undo deployment/backend -n prod'
                currentBuild.result = 'FAILURE'
                throw e
            }
        }
    }
}
回滚不等于恢复数据

rollout undo 只回滚 Pod 模板。数据库迁移、消息队列副作用、已发布的外部变更不会自动恢复。数据兼容性变更必须有独立的迁移方案，见 Kubernetes 手册"发布"章节。

5. 交付流水线最佳实践​

构建（Build）→ 测试（Test）→ 产物归档 → 镜像推送
  → 部署 dev → 部署 staging（门禁）→ 部署 prod（人工确认）
  → 全链路验证 → 通知
  • 每个环境之间设门禁：staging 验证通过才进 prod；
  • 产物一旦推送不可变，回滚用旧 tag，不覆盖同一 tag；
  • 记录每个环境当前版本的映射（Git tag + 镜像 tag），排障可查。

6. 练习与验收​

练习 A

  1. 在流水线中 archiveArtifacts 归档一个构建产物，构建后从页面下载验证
  2. 完成一次镜像构建 + 推送（可推私有仓库或本机 registry）
  3. 用 kubectl set image 部署到测试 Namespace 并 rollout status

练习 B

  1. 模拟一次发布失败，用 catchError + rollout undo 实现自动回滚
  2. （GitOps 模式）更新 Git 中镜像 tag，观察 Argo CD 自动同步
  3. 用语义 tag + 短 SHA 打镜像，验证可追溯

验收清单

  • 理解 Artifacts、制品仓库、镜像仓库、对象存储的分工
  • 会构建并推送镜像，tag 可追踪
  • 会用 kubectl / Helm / GitOps 三种方式部署
  • 理解发布前检查项与回滚策略
  • 知道回滚不能恢复数据库和外部副作用

下一篇：通知与协作集成。