第十二篇：《完整交付流水线案例：从代码提交到生产部署》

本系列的前十一篇文章已经覆盖了 CI/CD 的各个知识点从工具选型、Pipeline 编写、多环境部署、质量门禁到制品管理。本篇将它们全部串联起来构建一个从代码提交到生产部署的完整端到端案例。以 Spring Boot 应用为例涵盖代码检查 → 单元测试 → 镜像构建 → 安全扫描 → 多环境部署 → 监控告警的全流程并对比 Jenkins、GitLab CI、GitHub Actions 三种实现方案。一、案例全景1.1 业务场景假设我们是一个电商团队开发了一个订单服务Order Service需要将其部署到生产环境用户通过 https://order.example.com 访问服务需要支持高可用多副本代码变更后能够自动部署到测试环境人工审批后部署到生产环境1.2 技术栈1.3 流水线 Stagestext代码提交 → Lint → 单元测试 → 镜像构建 → 安全扫描 → 部署到开发环境 → 部署到预发布环境 → 人工审批 → 部署到生产环境二、Dockerfile多阶段构建dockerfile阶段1构建使用完整 JDKFROM maven:3.8.4-openjdk-17 AS builderWORKDIR /appCOPY pom.xml .RUN mvn dependency:go-offlineCOPY src ./srcRUN mvn clean package -DskipTests阶段2运行使用精简 JREFROM openjdk:17-jre-slimWORKDIR /appCOPY --frombuilder /app/target/*.jar app.jarEXPOSE 8080ENTRYPOINT [“java”, “-jar”, “/app/app.jar”]多阶段构建将编译环境和运行环境分离最终镜像只包含 JRE 和 JAR 包体积从数百 MB 降至数十 MB。三、Helm ChartKubernetes 部署模板3.1 values.yaml默认配置replicaCount:2image:repository:harbor.example.com/order-servicetag:latestpullPolicy:IfNotPresentservice:type:ClusterIPport:8080ingress:enabled:truehost:order.example.comresources:limits:cpu:500mmemory:512Mirequests:cpu:250mmemory:256MilivenessProbe:httpGet:path:/actuator/healthport:8080initialDelaySeconds:30periodSeconds:10readinessProbe:httpGet:path:/actuator/healthport:8080initialDelaySeconds:10periodSeconds:53.2 环境差异化配置textchart/├── values.yaml # 默认配置├── values/│ ├── dev.yaml # 开发环境1副本小规格│ ├── staging.yaml # 预发布环境2副本中等规格│ └── production.yaml # 生产环境3副本大规格四、GitLab CI 完整流水线# .gitlab-ci.ymlstages:-lint-test-build-scan-deploy-dev-deploy-staging-deploy-prodvariables:MAVEN_OPTS:-Dmaven.repo.local.m2/repositoryIMAGE_NAME:harbor.example.com/order-serviceIMAGE_TAG:$CI_COMMIT_SHORT_SHAcache:paths:-.m2/repository/# 1. 代码质量检查 lint:stage:lintimage:maven:3.8.4-openjdk-17script:-mvn checkstyle:checkallow_failure:true# 2. 单元测试 覆盖率 test:stage:testimage:maven:3.8.4-openjdk-17script:-mvn test jacoco:reportartifacts:reports:junit:target/surefire-reports/*.xmlpaths:-target/surefire-reports/-target/site/jacoco/# 3. 构建镜像 build:stage:buildimage:docker:latestservices:-docker:dindscript:-docker build--cache-from $IMAGE_NAME:latest-t $IMAGE_NAME:$IMAGE_TAG .-docker push $IMAGE_NAME:$IMAGE_TAG-docker tag $IMAGE_NAME:$IMAGE_TAG $IMAGE_NAME:latest-docker push $IMAGE_NAME:latestonly:-main-develop# 4. 安全扫描 scan:stage:scanimage:aquasec/trivy:latestscript:-trivy image--severity HIGH,CRITICAL--exit-code 1 $IMAGE_NAME:$IMAGE_TAGonly:-main# 5. 部署到开发环境develop 分支自动 deploy-dev:stage:deploy-devimage:alpine/helm:3.14before_script:-mkdir-p $HOME/.kube-echo $KUBECONFIG_DEV|base64-d$HOME/.kube/configscript:-helm upgrade--install order-service ./chart \-f chart/values/dev.yaml \--set image.tag$IMAGE_TAG \--namespace dev \--atomicenvironment:name:devurl:https://dev.order.example.comonly:-develop# 6. 部署到预发布main 分支自动 deploy-staging:stage:deploy-stagingimage:alpine/helm:3.14before_script:-mkdir-p $HOME/.kube-echo $KUBECONFIG_STAGING|base64-d$HOME/.kube/configscript:-helm upgrade--install order-service ./chart \-f chart/values/staging.yaml \--set image.tag$IMAGE_TAG \--namespace staging \--atomicenvironment:name:stagingurl:https://staging.order.example.comonly:-main# 7. 部署到生产环境手动审批 deploy-prod:stage:deploy-prodimage:alpine/helm:3.14before_script:-mkdir-p $HOME/.kube-echo $KUBECONFIG_PROD|base64-d$HOME/.kube/configscript:-helm upgrade--install order-service ./chart \-f chart/values/production.yaml \--set image.tag$IMAGE_TAG \--namespace production \--atomic \--timeout 10menvironment:name:productionurl:https://order.example.comonly:-mainwhen:manual# 人工审批五、三种工具实现对比六、回滚机制6.1 快速回滚GitLab# 查看部署历史helmhistoryorder-service-nproduction# 回滚到上一个版本helm rollback order-service-nproduction# 在 GitLab UI 中一键回滚# Operations → Environments → production → 点击回滚按钮6.2 自动化回滚Helm --atomic在部署命令中使用 --atomic 参数如果部署失败Helm 会自动回滚到上一个版本helm upgrade--installorder-service ./chart\-fchart/values/production.yaml\--atomic\--timeout10m七、常见陷阱与解决方案八、小结完整流水线代码检查 → 单元测试 → 镜像构建 → 安全扫描 → 开发环境 → 预发布环境 → 生产环境人工审批核心原则一次构建、到处部署、不可变镜像、环境隔离回滚机制Helm --atomic 自动回滚 GitLab/GitHub 环境历史手动回滚工具选择GitLab CI一体化、GitHub ActionsGitHub 生态、Jenkins灵活定制各有适用场景