Spring Boot微服务CI/CD：测试环境部署后如何推进至生产环境？

Great question! When setting up CI/CD for Spring Boot microservices with SVN, Kubernetes, and Jenkins, the key here is ensuring you deploy the exact same build artifact to both test and production—rebuilding would introduce unnecessary risk of inconsistencies. Let's break down your options clearly:

1. Use Jenkins Pipeline (Jenkinsfile) with Staged Deployment + Manual Approval (Most Common) #

This is the industry standard because it enforces a clear workflow, keeps your artifact consistent, and adds a safety gate for production deployments. You'll define stages in your Jenkinsfile that:

• Build your Spring Boot app once, push the Docker image to a registry with a unique tag (like SVN commit ID, Jenkins build number, or semantic version)
• Deploy that exact image to test
• Run your automated tests
• Wait for human approval before deploying to production
• Deploy the same tagged image to production

Here's a simplified example of what that looks like:

pipeline {
    agent any
    environment {
        SVN_URL = "svn://your-repo-url/microservice"
        IMAGE_REGISTRY = "your-internal-registry.com"
        SERVICE_NAME = "spring-boot-service"
    }
    stages {
        stage('Checkout from SVN') {
            steps {
                sh "svn checkout ${SVN_URL} ./src"
            }
        }
        stage('Build & Push Image') {
            steps {
                dir('./src') {
                    sh "./mvnw clean package -DskipTests"
                    // Use Jenkins build ID as the image tag for uniqueness
                    sh "docker build -t ${IMAGE_REGISTRY}/${SERVICE_NAME}:${BUILD_ID} ."
                    sh "docker push ${IMAGE_REGISTRY}/${SERVICE_NAME}:${BUILD_ID}"
                }
            }
        }
        stage('Deploy to Test Environment') {
            steps {
                // Point to your test K8s config, override image tag with our build ID
                sh "kubectl --context test-cluster apply -f k8s/test/deployment.yaml \
                    --set spec.template.spec.containers[0].image=${IMAGE_REGISTRY}/${SERVICE_NAME}:${BUILD_ID}"
            }
        }
        stage('Run Automated Tests') {
            steps {
                dir('./src') {
                    sh "./mvnw test"
                    // Optional: Add integration tests against the test environment
                    sh "./run-integration-tests.sh"
                }
            }
        }
        stage('Production Deployment Approval') {
            steps {
                // Require a team lead/admin to approve before moving to production
                input message: "Tests passed! Approve production deployment?", 
                    submitter: "dev-lead,ops-team"
            }
        }
        stage('Deploy to Production') {
            steps {
                // Use the EXACT same image tag for production
                sh "kubectl --context prod-cluster apply -f k8s/prod/deployment.yaml \
                    --set spec.template.spec.containers[0].image=${IMAGE_REGISTRY}/${SERVICE_NAME}:${BUILD_ID}"
            }
        }
    }
}

2. Reuse a Single Shell Script with Environment Parameters #

You don't need separate scripts for test and production—instead, write a single script that accepts environment and image tag as arguments. This keeps maintenance simple while allowing you to target different environments.

Example shell script (deploy-to-k8s.sh):

#!/bin/bash
set -euo pipefail

IMAGE_TAG=$1
TARGET_ENV=$2

# Validate environment input
if [[ ! "$TARGET_ENV" =~ ^(test|prod)$ ]]; then
    echo "Error: Invalid environment. Use 'test' or 'prod'."
    exit 1
fi

# Switch K8s context and deploy
case $TARGET_ENV in
    test)
        kubectl config use-context test-cluster
        K8S_DEPLOYMENT_FILE="k8s/test/deployment.yaml"
        ;;
    prod)
        kubectl config use-context prod-cluster
        K8S_DEPLOYMENT_FILE="k8s/prod/deployment.yaml"
        ;;
esac

# Deploy the specified image tag
kubectl apply -f "$K8S_DEPLOYMENT_FILE" \
    --set spec.template.spec.containers[0].image="your-internal-registry.com/spring-boot-service:$IMAGE_TAG"

Then call this script from your Jenkins Pipeline:

// After building and pushing the image...
stage('Deploy to Test') {
    steps {
        sh "./deploy-to-k8s.sh ${BUILD_ID} test"
    }
}

// After tests pass and approval is given...
stage('Deploy to Prod') {
    steps {
        sh "./deploy-to-k8s.sh ${BUILD_ID} prod"
    }
}

Key Best Practices to Follow #

• Never rebuild for production: Always use the exact same image/tag that passed testing—rebuilding could pull new dependencies or introduce untested code changes.
• Separate K8s configurations: Keep test and production Kubernetes manifests (deployment.yaml, configmaps, secrets) in separate directories to avoid mixing sensitive production config with test.
• Use K8s contexts: Configure Jenkins with separate Kubernetes contexts for test and production to ensure you're targeting the right cluster.
• Audit trails: Jenkins will log all deployment steps, and the manual approval step creates a clear audit trail for production changes.

内容的提问来源于stack exchange，提问作者Mr.DevEng