Staging & production boundaries
Name the deployment environment
Lesson 13 of 20 · 12 min · Module 5: Environments and release identity
An environment name connects a job to a deliberate release boundary.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Distinguish the environment responsibilities
- Attach the job to that boundary
The idea
A workflow combines an event boundary, job dependencies, and ordered steps. Conditions and prerequisite outcomes determine which jobs can run.
01Distinguish the environment responsibilities
Staging provides a place to inspect a candidate. Production serves users and needs an explicit operational boundary and accountable ownership.
02Attach the job to that boundary
The environment setting names the target. Real GitHub environment protection and required reviewers are configured separately from merely naming it.
03Do not invent approval evidence
The lab records that the job targets production. It does not contact GitHub or pretend a real reviewer approved a change.
Your turn
What the checks look for
- Supports an explicit manual trigger
- Records a production deployment
Take this with you
Separate environment identity from the controls that protect it.
Go a little further
Write the production approval policy you would configure outside the workflow.