如何通过GitLab流水线强制代码先经低环境再发布生产？

一、阻止跳过dev/qa直接合并到release分支 #

1. 完善分支合并规则校验 #

在流水线中增加分支合法性校验，确保只有符合GitFlow的分支才能发起MR合并。直接在verify-merge作业的脚本中内嵌校验逻辑：

• 合并到dev的源分支必须以feature/开头
• 合并到qa的源分支只能是dev
• 合并到release的源分支只能是qa

2. 结合GitLab分支保护增强管控 #

给dev、qa、release分支开启分支保护：

• 强制合并必须通过MR
• 开启「只有当流水线成功时才允许合并」
• 给release分支设置至少2次审批要求（匹配现有流程）

二、解决MR创建时跳过feature分支流水线的问题 #

之前的漏洞在于MR流水线仅执行verify-merge，未包含build和测试环节，导致审批者可忽略feature分支的流水线结果合并代码。解决方法如下：

1. 让MR流水线包含完整的build/测试环节 #

修改build-default的规则，使其在MR事件触发时也运行；同时调整workflow允许MR事件触发流水线，确保MR流水线会执行代码构建和测试。

2. 调整流水线阶段顺序 #

把verify-merge放在build阶段之前，先校验分支合法性，再执行代码构建，避免无效资源浪费。

完整的流水线YAML配置 #

default:  
  tags:
    - my-gitlab-runner
stages:
 - verify:merge
 - build:default
 - deploy:dev
 - deploy:qa
 - deploy:prod 

workflow:
  rules:    
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "web"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

verify-merge:
  stage: verify:merge
  script:    
    - |
      SOURCE_BRANCH="$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"
      TARGET_BRANCH="$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"

      case "$TARGET_BRANCH" in
        dev)
          if [[ ! "$SOURCE_BRANCH" =~ ^feature/ ]]; then
            echo "错误：仅允许feature/*分支合并到dev"
            exit 1
          fi
          ;;
        qa)
          if [[ "$SOURCE_BRANCH" != "dev" ]]; then
            echo "错误：仅允许dev分支合并到qa"
            exit 1
          fi
          ;;
        release)
          if [[ "$SOURCE_BRANCH" != "qa" ]]; then
            echo "错误：仅允许qa分支合并到release"
            exit 1
          fi
          ;;
        *)
          echo "目标分支无需校验"
          ;;
      esac
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

build-default:
  image: "myimage"
  stage: build:default
  script:        
    - npm install
    - npm i -g @nestjs/cli    
    - npm run build
    # 建议添加单元测试脚本：npm run test
  artifacts:
    paths:
      - "build_output.zip"
    expire_in: 6 hrs  
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

deploy-dev:
  image: "myimage"
  stage: deploy:dev
  environment: 
    name: dev
    url: "https://dev.mydomain.com"
  script:    
    - deploy/scripts/deploy-dev.sh    
  rules: 
    - if: $CI_COMMIT_REF_NAME == "dev"  

deploy-qa:
  image: "myimage"
  stage: deploy:qa
  environment: 
    name: qa
    url: "https://qa.mydomain.com"
  script:    
    - deploy/scripts/deploy-qa.sh    
  rules: 
    - if: $CI_COMMIT_REF_NAME == "qa"  

deploy-prod:
  image: "myimage"
  stage: deploy:prod
  environment: 
    name: prod
    url: "https://prod.mydomain.com"
  script:    
    - deploy/scripts/deploy-prod.sh
  when: manual    
  rules: 
    - if: $CI_COMMIT_REF_NAME == "release"  

额外配置建议 #

1. 环境权限管控：给deploy-prod作业设置权限，仅允许指定角色（如维护者）触发手动部署
2. 测试环节补充：在build-default中添加单元测试、代码检查等步骤，确保代码质量达标后才能进入后续环节

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