Environments: Dev, Test & Prod

Software doesn’t live in one place. The same app runs in several environments — separate, self-contained copies of the system used for different stages of work. Each copy has its own database, its own settings, and often its own web address. The reason teams bother with all these copies is simple: you want somewhere to make mistakes that isn’t the version your customers are using. Changes are built in the lowest, safest copy and promoted up toward the live system, gaining scrutiny at every step.

The three environments you’ll hear about most

Dev (short for development) is where engineers build and break things. It’s the workshop. Code here is half-finished by design; the database might be full of fake “Test User” accounts and orders for a thousand rubber ducks. Nobody panics if dev goes down, because no real customer is affected. This freedom is the whole point — you can try a risky idea, watch it fail, and undo it before lunch.

Test (you’ll also hear QA or staging) is a deliberately prod-like copy. It exists to answer one question: “If we ran this change for real, would it work?” Quality-assurance folks and automated checks poke at the change, click through the flows a customer would, and try to break it on purpose. Staging mirrors production as closely as the team can afford — same versions, similar data shapes — precisely so surprises show up here instead of in front of users.

Prod (production) is the real, live system. Real customers, real money, real data. Because of that, every change to prod is careful, reviewed, and reversible. You don’t experiment in prod, and you don’t “just quickly fix” something by editing it directly. The mindset shifts from “let’s see what happens” to “let’s be sure before we touch it.”

“It works on dev but not in prod”

This is the single most common sentence in software, and the reason test environments exist at all. A feature behaves perfectly on a developer’s machine and then falls over the moment real users touch it. Why? The environments are never identical. Dev might have ten test records; prod has ten million. Dev might point at a fake payment service that always says “yes”; prod talks to a real bank that sometimes says “no.” A setting, a data volume, a network rule — any small difference between copies can produce a bug that only appears higher up the chain.

The bigger the gap between your environments, the more bugs hide in that gap. Good teams work to make test look as much like prod as possible.

That’s also why settings that differ “per environment” — which database to talk to, which email server to use — are stored separately for each copy, so the same code can run safely in all three.

Promoting code “up” the chain

Think of the environments as a staircase. Work starts at the bottom in dev, climbs to test once it’s stable enough to verify, and only reaches prod after it has proven itself. Moving a change from one step to the next is called promoting it. The key rule is one of direction:

Golden rule: changes flow up (dev to test to prod). The higher the environment, the more caution, testing, and approval it takes to get there.

You almost never go the other way. Each step up is a checkpoint: did the tests pass, did a human approve it, are we confident? If the answer is no, the change waits.

A concrete walkthrough

Say a developer adds a “download invoice” button. They build it in dev, clicking it a few times against fake invoices until it works. They promote it to test, where QA tries it with oddly-named files, missing invoices, and a slow connection — and finds a bug. The developer fixes it back in dev, promotes again, and this time test passes. Only then does the change reach prod, where real customers finally get their button. If something still goes wrong, the team can roll prod back to the previous version, because every promotion is a deliberate, reversible step.

Why it matters

For anyone working alongside engineers, environments explain a lot of otherwise puzzling answers. “It’s only on staging right now” means it’s built but not yet live. “We can’t reproduce it in test” means the bug may be tied to real prod data. “We’ll promote it Thursday” means the code is finished but waiting at a checkpoint. Understanding the dev to test to prod staircase tells you where a piece of work actually is and why nobody will “just change it in prod” to save time. That caution isn’t bureaucracy — it’s the thing standing between a small mistake and a very public one.

Spot it: which environment?

Read each situation and decide for yourself, then tap a card to flip it and check your answer.

Sort the environments

Drag each item into the bucket it belongs to — or tap an item, then tap a bucket. Hit Check placement when you’re done.