Environments: Dev, Staging, Production
When Maya finishes a change to Pageturn, you might picture it going straight from her laptop to the readers. If that were true, every mistake she ever made would land directly in front of real users. Teams avoid that by never letting a change make the jump in one leap.
Instead a change travels through a series of environments — separate, complete copies of the app, each kept for a different purpose. A problem gets a chance to surface in a safe copy before it can reach anyone real. The three classic environments, in order, are development, staging, and production.
Development: where it's made
Development — usually shortened to "dev" — is the environment where code is written and first tried out. This is Maya's world: her own copy of Pageturn, often running right on her laptop, where she can add a feature, see if it works, and break things freely.
Because no real reader touches the dev environment, mistakes here are cheap. A crash in dev is just a normal part of building. That freedom to fail safely is exactly what makes dev the right place for unfinished, experimental work.
Staging: the dress rehearsal
Staging sits between dev and the real thing. It is a near-identical copy of production — same kind of server, same settings, same data shape — kept for one purpose: a final, realistic test of a change before any reader sees it.
The whole value of staging is in that word "identical." If a change works in staging, you have strong reason to believe it'll work for real, because staging is as close to production as a non-live copy can get. It's the dress rehearsal on the actual stage, before the audience is let in.
Production: the real thing
Production — "prod" — is the live app. It's the Pageturn that real readers open, with their real accounts and the books they've actually logged. This is Sam's world: the one environment where downtime or a bad change is felt by real people.
Everything about production is treated more carefully because of that. The other environments exist precisely so that production stays calm — they absorb the mistakes, so the place where users live sees as few of them as possible.
Promoting a change
A change earns its way forward one environment at a time, a move called promotion. Maya builds it in dev; once it works there, it's promoted to staging for a realistic check; once it passes there, it's promoted to production for readers. Each step is a checkpoint the change has to clear.
This mirrors putting on a play. Rehearsals are dev — rough, stop-and-start, mistakes expected. The full dress rehearsal on the real stage is staging. Opening night with a paying audience is production. You don't skip from a first read-through straight to opening night, and a change doesn't skip from a laptop straight to readers.
- "There's only one copy of the app." There are several — dev, staging, and production are separate, complete copies, each kept for a different stage of a change's journey.
- "Staging and production are interchangeable." Staging is a rehearsal copy with no real users; production is the live one readers actually use. They look alike on purpose, but only one is real.
- "Testing in production is the normal plan." It's a last resort, not the plan. The whole point of dev and staging is to catch problems before production, not in it.
- "A change can jump straight from dev to production." It's promoted in order — dev, then staging, then production — proving itself at each stop rather than leaping the line.
- "Push it to staging" and "it's in prod" are everyday phrases on real teams; now you know exactly what each one means.
- Environments are the reason frequent releases can be safe — each change is proven in a copy before it reaches anyone real.
- Production is the environment you'll watch most closely; this sets up Chapter 9, where monitoring keeps an eye on the live app.
- The dev-to-prod path is the spine of every deployment pipeline you'll meet in the Git, Docker, and Kubernetes deep courses.
Knowledge Check
What is the main purpose of the staging environment?
- A near-identical copy of production for a final test before real users
- The place where developers first write, run, and experiment freely with brand-new code
- The live app where real readers log the books they've read
- A backup location where old versions of the app are stored
Why does a change move through the environments in order instead of jumping straight to production?
- So problems are caught in a safe copy before they can reach real users
- Because deploying directly to production is technically much slower than to the others
- Because each environment runs a different part of the app's features
- So that every change can finally be tested directly on real users
Which environment do real users actually interact with?
- Production
- Development
- Staging
- All three at the same time
You got correct