Gitlab CI结合Git Flow：如何实现分支构建分离？

Based on your requirements for a complex web app using Git Flow, GitLab, and CI pipelines, here's a polished, production-ready configuration that reuses build logic across branches while separating deployment targets perfectly:

stages:
  - require
  - build
  - deploy

# Dependency installation - shared across all deployment-ready branches/tags
require:
  stage: require
  only:
    - develop
    - master
    - tags
  tags:
    - require
  script:
    - npm install

# Build stage - identical logic for develop, master, and release tags
build:
  stage: build
  only:
    - develop
    - master
    - tags
  script:
    - grunt
  artifacts:
    paths:
      - dist/  # Persist compiled build files for deployment jobs
    expire_in: 1 week  # Auto-clean old artifacts to save storage

# Deploy to testing environment - triggers only on develop branch
deploy_testing:
  stage: deploy
  only:
    - develop
  dependencies:
    - build  # Pull in the exact build artifacts from the build stage
  script:
    - echo "Starting deployment to testing server..."
    # Add your actual testing deployment commands here
    # Example: rsync -avz dist/ your-user@testing-server:/var/www/app/

# Deploy to pre-production environment - triggers only on master branch
deploy_master:
  stage: deploy
  only:
    - master
  dependencies:
    - build  # Reuse the same build output to avoid redundant builds
  script:
    - echo "Starting deployment to pre-production server..."
    # Add your actual pre-production deployment commands here
    # Example: scp -avz dist/ your-user@preprod-server:/var/www/app/

Key Details & Improvements: #

• Clear Pipeline Order: Added an explicit stages block to enforce the sequence of dependency installation → build → deployment.
• Reusable Build Artifacts: The build job stores its output as artifacts, so both deployment jobs use the exact same compiled code—no need to rebuild for each environment.
• Branch-Specific Deployment:
  • deploy_testing runs only when changes land on develop, aligning with your testing environment target.
  • deploy_master runs only on master, handling your pre-production deployments.
• Git Flow Compatibility: Included tags in the require and build stages to support Git Flow release tags, so tagged releases will also go through the same build process (you can extend this to add a production deployment job if needed later).

This setup stays true to Git Flow best practices: feature branches merge into develop for testing, then develop merges into master for pre-production, with the CI pipeline handling each step automatically.

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