Simplify Environment Variable Management with GitHub Environments

In CI/CD workflows, managing environment variables often involves using GitHub Secrets or Variables and implementing branching logic like ENV_DEV or ENV_PROD for different environments. However, GitHub's Environments feature allows for a much simpler approach, and I’d like to share how it improved our setup.

Traditional Approach: Conditional Logic for Each Environment

Previously, we handled environment-specific configurations by adding branching logic in the workflow file. While functional, this method became increasingly complex and difficult to maintain as the number of environments grew.

  build-and-push:
    runs-on: ubuntu-latest
    env: 
      REGION: ${{ vars.REGION }}
      IAM_ROLE_TO_ASSUME: ${{ vars.IAM_ROLE_TO_ASSUME }}

    steps:
      - name: Set environment variables
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/develop" ]]; then
            echo "ENV=${{ vars.ENV_DEV }}" >> $GITHUB_ENV
          elif [[ "${{ github.ref }}" == "refs/heads/staging" ]]; then
            echo "ENV=${{ vars.ENV_STG }}" >> $GITHUB_ENV
          else
            echo "ENV=${{ vars.ENV_PROD }}" >> $GITHUB_ENV
          fi

This approach worked, but as environments multiplied, so did the complexity of maintaining and debugging workflows.

The Simpler Approach: Leveraging GitHub Environments

With GitHub's Environments feature, you can eliminate branching logic and simplify your workflows significantly. Here’s how you can set it up:

1. Setting Up Environments

1. Create Environments Navigate to the Settings tab in your GitHub repository, then select Environments. Create an environment for each of your use cases, such as dev, stg, and prod.

1. Add Variables
   • For sensitive data (e.g., AWS credentials), use Environment secrets.
   • For non-sensitive data (e.g., an ENV identifier), use Environment variables.

2. Simplified Workflow with GitHub Environments

By using GitHub Environments, your workflow becomes much cleaner and easier to maintain. Here's an example:

  build-and-push:
    runs-on: ubuntu-latest

    # Assign the correct environment based on the branch
    environment: ${{ github.ref == 'refs/heads/develop' && 'dev' || github.ref == 'refs/heads/staging' && 'stg' || 'prod' }}

    env: 
      REGION: ${{ vars.REGION }}
      IAM_ROLE_TO_ASSUME: ${{ vars.IAM_ROLE_TO_ASSUME }}
      ENV: ${{ vars.ENV }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ${{ env.REGION }}
          role-to-assume: ${{ env.IAM_ROLE_TO_ASSUME }}
          role-session-name: GitHubActions
          role-duration-seconds: 3600

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build Docker Image
        run: docker build --build-arg ENV=${{ env.ENV }}

Key Benefits of Using GitHub Environments

• Reduced Complexity: No need for conditional logic in workflow files.
• Centralized Management: Environment-specific variables are managed directly in the GitHub UI.
• Improved Security: Secrets are scoped to specific environments, reducing risk.
• Scalability: Adding new environments is straightforward without impacting existing workflows.