DevToolHub

Continuous Deployment (CD) is one of the most powerful use cases for GitHub Actions. However, deploying directly to production without checks can be risky. That’s why teams often use multiple environments, staging checks, and approval gates to deploy safely and reliably.

This article is part of our complete Git and GitHub Actions workflow guide.

This guide explains how to set up environments in GitHub Actions, add manual approvals, and use best practices for deployment.

🔹 Defining Multiple Environments in GitHub

GitHub provides environments to manage deployments. Each environment can:

• Store its own secrets (like API keys or tokens).
• Require manual approvals before deployment.
• Provide audit logs for tracking.

Example: Staging and Production

name: Deploy App

on:
  push:
    branches:
      - main

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v3
      - run: echo "Deploying to staging..."

  deploy-production:
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production
    steps:
      - uses: actions/checkout@v3
      - run: echo "Deploying to production..."

Here, staging deploys first. Only after success does production run.

Example: Development, QA, Staging, and Production

Larger teams often use more than two environments. For example:

• Development → For feature testing.
• QA (Quality Assurance) → For internal testers.
• Staging → For pre-production validation.
• Production → For end users.

jobs:
  deploy-dev:
    runs-on: ubuntu-latest
    environment: development
    steps:
      - run: echo "Deploying to Development"

  deploy-qa:
    runs-on: ubuntu-latest
    needs: deploy-dev
    environment: qa
    steps:
      - run: echo "Deploying to QA"

  deploy-staging:
    runs-on: ubuntu-latest
    needs: deploy-qa
    environment: staging
    steps:
      - run: echo "Deploying to Staging"

  deploy-production:
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production
    steps:
      - run: echo "Deploying to Production"

This ensures code passes through multiple layers of validation before production.

Example: Branch-Based Deployments

Another common pattern is deploying based on branches:

• Push to dev → Deploy to Development
• Push to qa → Deploy to QA
• Push to main → Deploy to Production

on:
  push:
    branches:
      - dev
      - qa
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        run: |
          if [[ "${GITHUB_REF##*/}" == "dev" ]]; then
            echo "Deploying to Development"
          elif [[ "${GITHUB_REF##*/}" == "qa" ]]; then
            echo "Deploying to QA"
          elif [[ "${GITHUB_REF##*/}" == "main" ]]; then
            echo "Deploying to Production"
          fi

This strategy gives developers flexibility without manual changes in the workflow file.

🔹 Adding Manual Approvals

GitHub allows you to add approval gates for sensitive environments like production.

Steps:

1. Go to Repository Settings → Environments → Production.
2. Add required reviewers.
3. Save changes.

Now, deployments to production will pause until someone approves them.

🔹 Using Secrets per Environment

Each environment can hold different secrets, such as:

• DEV_API_KEY for development
• QA_API_KEY for QA
• STAGING_API_KEY for staging
• PRODUCTION_API_KEY for production

Example usage:

- name: Deploy with secret
  run: echo "Using ${{ secrets.PRODUCTION_API_KEY }}"

This keeps sensitive data safe and specific to each environment.

🔹 Deployment Strategies

Depending on your needs, you can use different strategies:

1. Sequential Environments

Code flows from Development → QA → Staging → Production.

2. Manual Approvals for Production

Deployment pauses until someone reviews and approves it.

3. Branch-Based Deployments

Each branch corresponds to an environment (Dev, QA, Staging, Prod).

4. Blue-Green Deployment (Advanced)

Two production environments run side by side. Traffic switches gradually from the old version to the new one.

🔹 Best Practices

✅ Use separate environments for each stage.
✅ Protect production with manual approvals.
✅ Store secrets in environment settings, not in code.
✅ Monitor deployments with GitHub logs or external tools.
✅ Document your environment flow so the whole team understands it.

✅ Key Takeaways

• GitHub Actions environments help you deploy safely and consistently.
• Use multiple environments like Dev, QA, Staging, and Production.
• Protect production with approvals and separate secrets.
• Choose deployment strategies that fit your project’s needs.

By combining environments, approvals, and best practices, your team can deliver software faster without sacrificing safety.

Frequently Asked Questions

You Might Also Like

• 👉 Getting Started with GitHub Actions: Your First CI/CD Pipeline
• 👉 Understanding GitHub Actions Workflow Files (YAML Explained in Detail)
• 👉 GitHub Actions for Testing: Run Unit Tests Automatically
• 👉 GitHub Actions for Deployment: Automating App Releases
• 👉 GitHub Actions Secrets and Security Best Practices
• 👉 GitHub Actions Caching and Performance Optimization