TopicTrick Logo
Topictrick
GitHubDevOps

GitHub Environments: Deployment Rules

TT
TopicTrick Team
•
GitHub Environments: Deployment Rules
← Back to GitHub Mastery

GitHub Environments: Deployment Rules

"A mistake in Staging is a learning moment. A mistake in Production is a business crisis. Environments are the wall between them."

In your junior years, you might have one "AWS_KEY" that gives you power over everything.

  • The Problem: If you run a test, you might accidentally delete the production database.
  • The Solution: GitHub Environments.

Environments allow you to have a secret named DB_PASSWORD that has one value for "Staging" and a COMPLETELY DIFFERENT value for "Production." You can also hire a "Guard" (Protective Rule) that prevents the code from moving until a human signs off. This 1,500+ word guide explores the "Safety Gate" methodology.

1. Environment Secrets: The Isolation Layer

In GitHub Settings -> Environments, you create two rooms: Staging and Production.

  • Inside Production, you save the "Real" database keys.
  • Inside Staging, you save the "Test" database keys.
  • The Power: Your YAML code stays the same! You just tell the job which environment it is currently in.
yaml




2. Protection Rule 1: Required Reviewers


This is the #1 tool for enterprise safety.


    

  • You can tell GitHub: "Only deploy to Production if 'Alice' or 'Bob' clicks the Approve button."
    • 

  • Alice gets an email. She checks the "Staging" site. She sees it's good.
    • 

  • She hits "Approve" inside the GitHub Actions tab.
The Benefit: Zero accidental deployments at 4:00 AM on a Friday.
    • 





3. Protection Rule 2: Wait Timer


Sometimes you want to deploy to "Canary" servers, wait 30 minutes to see if any users complain, and ONLY THEN deploy to the rest of the world.


    

  • You set a "Wait Timer" of 30 minutes on the environment.
    • 

  • The pipeline literally "Pauses" for 30 minutes. If no one hits the "Cancel" button, it proceeds automatically.
    • 





4. Environment Variables (Not just Secrets)


Not everything is a secret. You might have a WEBSITE_URL that is different in staging.


    

  • Environments support Variables.
    • 

  • You can access them using ${{ vars.WEBSITE_URL }}.
    • 

  • This allows you to build "Dynamic" links in your Slack notifications based on where the code was just deployed.
    • 





5. Deployment History: Who shipped what?


GitHub provides a dedicated "Deployments" tab for each environment.


    

  • It shows a timeline: "v1.2.3 was deployed by Bob 5 hours ago (Success)."
    • 

  • It shows the Active version vs the Old versions.
    • 

  • The Use Case: If the site crashes, you go to this tab to see exactly which commit caused the problem.
    • 





Summary: The Environment Checklist


    

  1. Strict Isolation: Never share keys between Staging and Production.
    2. 

  2. Reviewers: Always require at least 1 senior person to approve Production deployments.
    3. 

  3. Deployment Branch: Restrict the Production environment so it ONLY accepts code from the main branch.
    4. 

  4. Timer: Use a 15-minute wait timer for "Canary" rollouts.
    5. 

  5. Audit: Check the deployment history once a month to find "Slow" delivery patterns.
    6. 



Environments are the "Guardians" of your production server. By mastering the isolation of secrets and the discipline of manual approvals, you gain the ability to ship software with 100% confidence and zero stress. You graduate from "Pushing code" to "Architecting Safe Rollouts."




Part of the GitHub Mastery Course — engineering the gates.