在 Git 中如何管理不同版本协议的脚本,并保证回滚一键完成

解读

性能测试脚本往往随业务接口、压测平台、协议标准(HTTP/1.1、HTTP/2、gRPC、Dubbo、MQ 等)快速演进。国内项目节奏快、灰度窗口短,一旦线上指标异常,需要在分钟级内回滚到“上一稳定脚本版本”并重新发压。面试官真正关心的是:

  1. 能否用 Git 把“协议版本”与“脚本版本”一一对应,避免“脚本对、协议错”的隐性错压;
  2. 回滚动作必须“一键”且“无人为决策”,即任何值班同学凌晨两点都能执行;
  3. 回滚后,Jenkins/流水线能立即拿到正确脚本、依赖包、参数文件,直接起压,不再人工改配置。

因此,回答要围绕“分支模型 + Tag 规范 + 自动化钩子 + 回滚脚本”展开,让面试官听到“可落地、可度量、可应急”的方案。

知识点

  1. Git Flow 的简化版:主干 master、功能 feature、热修 hotfix、发布 release 四元分支;
  2. Tag 命名规范:prod/{协议版本}-{脚本版本}-{YYYYMMDD}-{buildNo},例如 prod/http2-v3.2.1-20240625-001;
  3. 钩子脚本:.git/hooks/post-checkout 触发校验,保证 checkout 后协议 Jar 与脚本匹配;
  4. 回滚脚本 rollback.sh:基于 Tag 计算上一个稳定 Tag,git checkout 并自动打包、推送到 Nexus/Artifactory,再触发 Jenkins 参数化构建;
  5. 参数外置:使用 conf/performance.env 文件存放并发数、RampUp、阈值,Git 只管理脚本模板,避免回滚时把“新指标”带回旧脚本;
  6. 国内常用平台集成:Jenkins + GitLab + SonarQube + Allure,回滚后 Allure 历史报告仍能对比;
  7. 合规要求:金融、运营商项目需留痕,回滚脚本必须记录操作人、原因、Ticket 号,写入 Git 提交信息并推送到审计仓库。

答案

我采用“三件套”方案:规范、Tag、脚本。

  1. 规范
    目录按协议维度拆分:
    /scripts/http2/order-create.jmx
    /scripts/dubbo/user-service.jmx
    /lib/http2/jmeter-plugins-grpc-1.3.jar
    /lib/dubbo/dubbo-jmeter-2.7.jar
    每个协议目录下放置 protocol.version 文件,内容仅一行,如 2.7.15,用于钩子校验。

  2. Tag
    只在 master 分支打 Tag,命名模板 prod/{协议}-{脚本}-{日期}-{序号}。
    流水线构建成功后自动打 Tag,并同步到 Nexus 生成 /perf/script/{Tag}.tar.gz,保证二进制与 Git 快照一致。

  3. 一键回滚脚本 rollback.sh
    放在项目根目录,核心逻辑 10 行:

    #!/usr/bin/env bash
    set -e
    LAST_TAG=$(git tag -l "prod/*" --sort=-version:refname | sed -n '2p')  
    git checkout $LAST_TAG
    mvn -pl lib clean package -q
    tar -czf /tmp/${LAST_TAG}.tar.gz scripts/ lib/ conf/
    curl -u ${NEXUS_USER}:${NEXUS_PASS} --upload-file /tmp/${LAST_TAG}.tar.gz \
         https://nexus.xxx.com/repository/perf-script/${LAST_TAG}.tar.gz
    java -jar jenkins-cli.jar -s https://jenkins.xxx.com/ build perf_pipeline \
         -p SCRIPT_TAR=${LAST_TAG}.tar.gz -p CAUSE="Rollback-${LAST_TAG}"
    

    权限收敛:脚本只能由值班账号通过堡垒机调用,调用时强制写入 Jira Ticket 号,提交信息格式为
    git commit --allow-empty -m "Rollback to LASTTAGby{LAST_TAG} by {USER} due to ${TICKET}"

  4. 效果
    最近一次线上告警,我们在 2 分钟内完成回滚,Jenkins 构建号 #327 直接复用旧脚本,TPS 恢复至 6800,错误率从 5% 降到 0.3%,满足 SLA≤1% 要求。回滚记录自动同步到审计 Git 仓库,合规检查零缺陷。

拓展思考

  1. 多协议混压场景:如果一次压测同时触发 HTTP/2 与 Dubbo,Tag 命名可升级为 prod/mixed-{http2-v3.2.1}-{dubbo-v2.7.15}-{date}-{buildNo},回滚脚本需支持“部分协议回滚”还是“全量回滚”可配置。
  2. 大文件问题:JMeter 的 2G CSV 数据文件若入 Git 会拖慢 clone,可改用 Git LFS,并在 rollback.sh 里加入 git lfs pull,保证数据版本一致。
  3. 灰度回滚:对于金融核心系统,可先把 10% 流量切换到旧脚本 Tag,观测 5 分钟无异常再全量切换,脚本只需在 Jenkins 参数里增加 WEIGHT=10 即可。
  4. 自动化度量:回滚后把 Grafana 面板当前 QPS、RT、CPU 截图通过企业微信机器人发到值班群,实现“回滚即报告”,减少人工确认时间。