如何基于GitLab工作流变量实现多环境部署？适配14.3.4版本

你提到的动态变量作为Job标签的特性，GitLab官方在14.7版本才正式上线稳定支持，你当前使用的14.3.4版本低于该版本，因此原生不支持该特性。判断同类GitLab CI特性适配版本的通用方法为：查看对应特性提案的里程碑（milestone）字段，标注的版本号即为该特性首次正式发布的最小支持版本，只要你使用的GitLab版本号大于等于该版本即可正常使用。

当前你已经配置了分环境的专属Runner标签、且流水线已按环境做了独立隔离，可选择以下任意方案实现需求：

• 方案1：独立Job分支匹配
  为开发、生产环境分别编写独立的部署Job，通过rules判断分支匹配规则，分别绑定对应环境的Runner标签即可，你原本的workflow规则可以保留，示例配置如下：

  workflow:
    rules:
      - if: '$CI_PIPELINE_SOURCE == "web"'
      - if: '$CI_PIPELINE_SOURCE == "parent_pipeline"'
      - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      - if: "$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS"
        when: never
      - if: '$CI_COMMIT_BRANCH =~ /^feature.*$/'
        variables:
          TARGET: dev
      - if: "$CI_COMMIT_BRANCH"
  
  # 开发环境部署Job
  deploy_dev:
    tags:
      - dev-runner # 替换为你的开发环境专属Runner标签
    script:
      - echo "执行开发环境部署逻辑"
      - ./deploy.sh $TARGET
    rules:
      - if: '$TARGET == "dev"'
  
  # 生产环境部署Job
  deploy_prod:
    tags:
      - prod-runner # 替换为你的生产环境专属Runner标签
    script:
      - echo "执行生产环境部署逻辑"
      - ./deploy.sh $TARGET
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"' # 替换为你的生产分支匹配规则
  

• 方案2：模板继承减少重复代码
  如果不同环境的部署逻辑重合度较高，可以将公共逻辑抽为隐藏模板，不同环境的Job继承模板后仅需要修改标签、变量和触发规则即可，大幅减少配置冗余：

  # 公共部署模板
  .deploy_base:
    script:
      - echo "通用环境检查步骤"
      - echo "拉取部署配置文件"
      - ./deploy.sh $TARGET
  
  deploy_dev:
    extends: .deploy_base
    tags:
      - dev-runner
    variables:
      TARGET: dev
    rules:
      - if: '$CI_COMMIT_BRANCH =~ /^feature.*$/'
  
  deploy_prod:
    extends: .deploy_base
    tags:
      - prod-runner
    variables:
      TARGET: prod
    rules:
      - if: '$CI_COMMIT_BRANCH == "main"'
  

• 方案3：父子流水线拆分
  如果后续需要扩展更多环境、部署逻辑复杂度较高，可以将不同环境的部署配置拆分为独立的子流水线文件，主流水线根据分支条件触发对应环境的子流水线，子流水线内部固定绑定对应环境的Runner标签即可，适合中大型项目的多环境管理。

内容的提问来源于stack exchange，提问作者lony