Environment strategy in the broader sense
Beyond the GitHub feature
Modules 2 through 4 covered the GitHub Actions Environment feature — a precise technical object, with its own secrets and protection rules. But "having environments" is a deployment-strategy decision that exists independently of this specific tool. Three patterns show up in most projects:
Dev / staging / production
The most classic pattern: an environment to develop and iterate quickly (high tolerance for mistakes), a staging environment that should resemble production as closely as possible (to catch issues before they reach real users), and production itself. The most common mapping ties a branch to each environment (develop → staging, main → production), but this mapping doesn't guarantee the environments stay identical — see drift, already introduced in module 4.
Ephemeral environments per pull request
Rather than 2-3 fixed environments, some teams deploy a temporary instance per pull request, torn down when the PR closes. This very site is a concrete, verifiable example: every pull request on this repo automatically generates a dedicated Netlify preview URL (visible in the PR's CI checks), with no GitHub Environment feature involved at all — the hosting platform manages that lifecycle, not GitHub Actions.
Advantage: every change is testable in isolation, without waiting its turn on a shared staging environment. Drawback: coordination gets more complex if several previews need to interact (a shared database, for instance), and cost can be higher if each preview consumes real resources.
Managing secrets across environments
Whether environments are managed through GitHub's feature or a third-party platform, the same risk comes back: secret sprawl. Every additional environment is one more place an API key, database password, or token has to exist — and one more place to forget during a rotation after a leak. Two practices limit this risk, regardless of the tool used:
- Scope to the minimum necessary: a development environment should never have access to real production keys, "just in case."
- Document where each secret lives: without an inventory, nobody can be sure, during a rotation, whether a forgotten copy remains in a test environment.
Where the GitHub feature stops
GitHub's Environment feature (modules 2-4) answers the governance need (who can trigger what, with which secrets) well when the deployment itself is driven by a GitHub Actions workflow. It doesn't replace a full deployment strategy: it has no opinion on whether you should have 2 or 5 environments, on where they run (owned infrastructure, a managed platform), or on how to detect drift between them. Those decisions still need to be made independently — that's the point of the next module.
What you just did
You stepped back from the previous modules' technical feature to see the strategy patterns that exist with or without it, and the cross-cutting risk of secret sprawl. The last module turns everything above into an actionable decision grid.
Check your understanding
Is an automatically-created preview/ephemeral environment for each pull request (e.g. by a hosting platform) necessarily a GitHub Environment as covered in module 2?
Why is "configuration drift" (already seen in module 4) a particular risk in a rigid branch-to-environment mapping (e.g. always `develop` → staging, always `main` → production)?
What is a specific risk of managing secrets across multiple environments (dev, staging, prod, and possibly ephemeral previews)?
Want to hear about the next modules?
The Academy stays free and open-access, no sign-up required. If you'd just like to be notified by email when a new module ships, here you go — no obligation, unsubscribe anytime with one click.