Jenkins脚本如何实现A/B测试策略

本文目录导读：

1. 核心思路：在Jenkins Pipeline中引入“流量分组”逻辑
2. 完全随机分配（适用于CI/CD自动触发）
3. 混合模式：灰度发布与A/B测试结合（更高级）
4. 数据收集与日志关联（重要）
5. 注意事项
6. 总结：简单 vs 复杂场景选择

在Jenkins中实现A/B测试策略，通常有两种主要模式：

1. 构建时动态选择（Pipeline内部分支）：在同一个Jenkins Job中，根据参数或随机数，在流水线内将流量路由到不同的构建逻辑（A版本 vs B版本）。
2. 部署时路由选择（环境/配置分离）：先构建并部署A和B两个版本到不同的服务实例或Kubernetes组，然后通过负载均衡器（如Nginx、Istio）根据Header/Cookie分流。

以下重点介绍第一种模式（Pipeline脚本实现）,因为这是最直接由Jenkins控制的自动化策略。

核心思路：在Jenkins Pipeline中引入“流量分组”逻辑

参数化构建（推荐用于手动触发）

在 Jenkinsfile 中定义 choice 或 boolean 参数,让用户或上游系统决定本次构建是A组还是B组。

pipeline {
    agent any
    parameters {
        choice(name: 'DEPLOY_VERSION', choices: ['A', 'B', 'RANDOM'], description: '选择部署版本')
        string(name: 'AB_TEST_HEADER', defaultValue: 'ab_test', description: '用于路由的请求头名称')
    }
    stages {
        stage('Checkout Source') {
            steps {
                checkout scm
            }
        }
        stage('Build & Deploy') {
            steps {
                script {
                    // 1. 确定版本
                    def version = params.DEPLOY_VERSION
                    if (version == 'RANDOM') {
                        version = (new Random().nextInt(2) == 0) ? 'A' : 'B'
                    }
                    // 2. 根据版本执行不同逻辑
                    if (version == 'A') {
                        echo "▶ 构建并部署版本 A（对照组）"
                        // 编译特定分支、使用特定配置文件、打不同Docker标签
                        sh "mvn clean package -P version-a"
                        sh "docker build -t myapp:${env.BUILD_TAG}-a ."
                        sh "kubectl set image deployment/myapp-v1 myapp=myapp:${env.BUILD_TAG}-a"
                    } else {
                        echo "▶ 构建并部署版本 B（实验组）"
                        sh "mvn clean package -P version-b"
                        sh "docker build -t myapp:${env.BUILD_TAG}-b ."
                        sh "kubectl set image deployment/myapp-v2 myapp=myapp:${env.BUILD_TAG}-b"
                    }
                    // 3. 记录本次部署的版本到某个存储（用于后续数据关联）
                    writeFile file: "deploy-${env.BUILD_NUMBER}.txt", text: version
                }
            }
        }
        stage('Verify') {
            steps {
                script {
                    def version = readFile("deploy-${env.BUILD_NUMBER}.txt").trim()
                    echo "当前线上版本: ${version}"
                    // 可以在这里调用API检查A/B两个Pod是否都在运行
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'deploy-*.txt'
        }
    }
}

完全随机分配（适用于CI/CD自动触发）

如果希望每次代码提交后自动随机分配版本（例如50%概率A，50%概率B）：

pipeline {
    agent any
    triggers {
        // 代码变更自动触发
        pollSCM('*/5 * * * *')
    }
    stages {
        stage('Randomize Version') {
            steps {
                script {
                    // 使用随机数种子，可以用BUILD_ID作为种子保证可重放
                    def seed = env.BUILD_NUMBER as long
                    def rand = new Random(seed)
                    env.VERSION = rand.nextBoolean() ? 'A' : 'B'
                    echo "本次构建分配版本: ${env.VERSION}"
                }
            }
        }
        stage('Deploy') {
            steps {
                script {
                    // 根据版本执行不同操作
                    if (env.VERSION == 'A') {
                        // 部署到命名空间 ns-a / pod标签 version=a
                        sh "kubectl apply -f k8s/a-deployment.yaml"
                    } else {
                        sh "kubectl apply -f k8s/b-deployment.yaml"
                    }
                }
            }
        }
        stage('Record') {
            steps {
                // 将版本记录到数据库或文件系统，便于后续分析
                sh "echo 'BUILD=${BUILD_NUMBER} VERSION=${VERSION}' >> ab_log.txt"
            }
        }
    }
}

混合模式：灰度发布与A/B测试结合（更高级）

如果希望Jenkins只负责部署A和B两个版本，而流量分配由基础设施层（如Kubernetes Service Mesh、Nginx）完成：

部署两个独立的Deployment：

# k8s/a-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp
    version: a
  name: myapp-v1
spec:
  replicas: 5
  template:
    metadata:
      labels:
        version: a
    spec:
      containers:
      - name: myapp
        image: myapp:${BUILD_TAG}-a
---
# k8s/b-deployment.yaml  
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp  
    version: b
  name: myapp-v2
spec:
  replicas: 5
  template:
    ...

Jenkins Pipeline只负责更新镜像：

stage('Update Canary') {
    steps {
        sh "kubectl set image deployment/myapp-v1 myapp=myapp:${BUILD_TAG}-a"
        sh "kubectl set image deployment/myapp-v2 myapp=myapp:${BUILD_TAG}-b"
    }
}

外部负载均衡（如Istio VirtualService）做权重路由：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - headers:
        ab-group:
          exact: "a"
    route:
    - destination:
        host: myapp-v1
  - route:
    - destination:
        host: myapp-v1
      weight: 50
    - destination:
        host: myapp-v2
      weight: 50

数据收集与日志关联（重要）

A/B测试的核心是数据对比,Jenkins需要确保构建的版本信息能被下游系统获取。

推荐做法：

• 在Docker镜像标签中加入版本信息（如 myapp:123-a）
• 应用启动时输出 app.version=a 到日志
• 部署时通过ConfigMap或环境变量注入 AB_VERSION=${VERSION}
• 将Jenkins的BUILD_NUMBER、VERSION、GIT_COMMIT 发送到InfluxDB或Elasticsearch

stage('Collect Metadata') {
    steps {
        script {
            def data = [
                build_number: env.BUILD_NUMBER,
                version: env.VERSION,
                git_commit: env.GIT_COMMIT,
                timestamp: new Date().format("yyyy-MM-dd'T'HH:mm:ss'Z'", TimeZone.getTimeZone('UTC'))
            ]
            // 写入共享文件或API
            sh "curl -X POST -H 'Content-Type: application/json' -d '${data}' http://metrics-collector/api/records"
        }
    }
}

注意事项

简单 vs 复杂场景选择

• 小型团队/快速实验：直接在Pipeline中用 Random + if-else 控制构建逻辑,部署到同一命名空间的不同Deployment。
• 生产级/大规模：Jenkins只负责打出两个版本的镜像并推送，流量分流完全交给Service Mesh（Istio/Linkerd）或Ingress Controller，通过权重（1:99 -> 50:50 -> 100:0）逐步放量。

如果需要更具体的代码片段（如Nginx分流配置、Spring Boot读取Header）,可以告诉我你的具体技术栈。