使用eb deploy时，Elastic Beanstalk多环境分支Git配置管理最佳实践

Great question—this is a super common scenario when working with Elastic Beanstalk and multi-branch Git repos, and there are a few solid approaches to match your branch-to-environment workflow while keeping configs properly isolated. Let’s walk through the most practical options tailored to your setup:

1. Deploy Script + Branch-Based Config Switching #

Since you already have env.config (prod) and env_dev.config (dev) ignored in Git but available locally, a simple deployment script can automate swapping the right config before sending code to EB.

Steps: #

• Keep your .gitignore as-is (ignore both config files)
• Create a bash script (e.g., deploy.sh) in your repo root:

  #!/bin/bash
  # Grab current Git branch
  CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
  EB_CONFIG_DIR="./.ebextensions"
  
  # Validate branch and copy matching config
  if [ "$CURRENT_BRANCH" = "prod" ]; then
    cp env.config "$EB_CONFIG_DIR/env.config"
    echo "Switched to prod config for deployment"
  elif [ "$CURRENT_BRANCH" = "dev" ]; then
    cp env_dev.config "$EB_CONFIG_DIR/env.config"
    echo "Switched to dev config for deployment"
  else
    echo "Error: Unsupported branch $CURRENT_BRANCH. Use prod or dev."
    exit 1
  fi
  
  # Deploy to the specified EB environment
  eb deploy "$1"
  
  # Optional: Clean up the copied config to avoid local clutter
  rm "$EB_CONFIG_DIR/env.config"
  

• Make the script executable: chmod +x deploy.sh
• Deploy with:
  • For prod: ./deploy.sh your-prod-eb-env
  • For dev: ./deploy.sh your-dev-eb-env

Pros & Cons: #

• ✅ No changes to Git version control needed
• ✅ Clear 1:1 mapping between branches and configs
• ❌ Requires team members to use the script (not raw eb deploy)
• ❌ Local config files must exist for each environment

2. EB Configuration Layers (Centralized Variable Management) #

If you prefer to keep environment variables out of local files entirely, use EB’s built-in Configuration Layers to separate configs from code.

Steps: #

• Log into the EB Console and create two configuration layers:
  • prod-config-layer: Add all your production environment variables here
  • dev-config-layer: Add all your development environment variables here
• Attach each layer to its corresponding EB environment:
  • Link prod-config-layer to your prod EB environment
  • Link dev-config-layer to your dev EB environment
• You can now delete or archive your local env.config/env_dev.config files—EB will automatically apply the layer’s variables during deployment
• Deploy directly with:
  • git checkout prod && eb deploy your-prod-eb-env
  • git checkout dev && eb deploy your-dev-eb-env

Pros & Cons: #

• ✅ No local config files to maintain
• ✅ Variables are centralized and managed via EB (great for compliance/access control)
• ❌ Changes to variables require going through the EB Console (can’t version-control alongside code)
• ❌ Less visibility into variable values in your repo

3. Version-Controlled Configs with Branch Differentiation #

If you want your environment configs to live alongside your code in Git, you can track env.config in version control and keep branch-specific versions.

Steps: #

• Remove env.config from your .gitignore
• On the prod branch:
  • Ensure env.config has your production variables
  • Commit it to Git: git add env.config && git commit -m "Add prod environment config"
• On the dev branch:
  • Overwrite env.config with your development variables
  • Commit it to Git: git add env.config && git commit -m "Add dev environment config"
• Critical: To avoid overwriting configs when merging branches (e.g., dev → prod), use Git’s merge strategy to preserve the target branch’s config:

  # When merging dev into prod, keep prod's env.config
  git merge -X ours dev
  

• Deploy directly by checking out the branch and running eb deploy:
  • git checkout prod && eb deploy your-prod-eb-env
  • git checkout dev && eb deploy your-dev-eb-env

Pros & Cons: #

• ✅ Configs are version-controlled alongside code (easy to track changes)
• ✅ No extra scripts or EB setup needed
• ❌ Merge conflicts can occur if configs are modified in both branches
• ❌ Configs are visible in Git (not ideal for sensitive secrets—use EB Secrets Manager alongside this if needed)

4. Git Pre-Push Hooks for Auto-Config Swapping #

For a hands-off approach without scripts, use Git’s pre-push hook to automatically swap config files before EB receives your code.

Steps: #

• In your repo’s .git/hooks directory, create a file named pre-push (no file extension) with this content:

  #!/bin/bash
  CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
  EB_CONFIG_DIR="./.ebextensions"
  
  if [ "$CURRENT_BRANCH" = "prod" ]; then
    cp env.config "$EB_CONFIG_DIR/env.config"
    git add "$EB_CONFIG_DIR/env.config"
    echo "Auto-swapped to prod config for deployment"
  elif [ "$CURRENT_BRANCH" = "dev" ]; then
    cp env_dev.config "$EB_CONFIG_DIR/env.config"
    git add "$EB_CONFIG_DIR/env.config"
    echo "Auto-swapped to dev config for deployment"
  fi
  
  exit 0
  

• Make the hook executable: chmod +x .git/hooks/pre-push
• Deploy as normal:
  • git checkout prod && eb deploy your-prod-eb-env
  • git checkout dev && eb deploy your-dev-eb-env

Pros & Cons: #

• ✅ No extra commands needed—works with raw eb deploy
• ✅ Automatic config switching on deploy
• ❌ Hooks are local to your machine—team members need to copy the hook to their repos
• ❌ The temporary config file is added to your Git index (you may want a post-deploy hook to revert it)

Which Should You Choose? #

• Pick Option 1 if you want to keep configs local and avoid version control
• Pick Option 2 if you prefer centralized, console-managed variables
• Pick Option 3 if you want configs versioned with your code
• Pick Option 4 if you want a hands-off, script-free local workflow

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