Environments and Builds

"It works on my machine" is a running joke in software for a reason: the same app genuinely behaves differently depending on where it runs. Teams deal with this by keeping several complete copies of their product alive at once — and knowing which copy you're testing, and which version of the code is on it, is a daily, practical QA concern. Miss it, and you'll report bugs that don't exist and miss ones that do.

What an Environment Is

An environment is a complete, running copy of the product: the code, plus the data it works on, plus the settings that tell it how to behave, plus its connections to outside services. Same code in two environments can still mean different data, different settings, different connections — and therefore different behavior. That's not a flaw; it's the design. Each copy exists so that a different kind of work can happen safely.

Think of a theater. The same play exists in the rehearsal room and on opening night — same script, same actors. But the rehearsal room has work lights, taped-out props, and an audience of one director, while opening night has the real set, the real orchestra, and a thousand paying guests. You'd never rehearse a risky new scene for the first time in front of the paying crowd. Software teams feel exactly the same way.

The Classic Ladder

Most teams keep three rungs. Development (everyone says dev) is each developer's own workspace — messy, changing minute to minute, where Omar tries things. Staging (also called test or QA environment) is the team's shared rehearsal copy — built to resemble production as closely as practical, filled with fake data, and it's where most of your testing happens. Production (prod) is the real thing: real travelers, real bookings, real money. The word alone should raise your pulse slightly — anything you do in production happens to real customers.

Builds, Versions, and Deployment

Now the moving parts. A build is a packaged, runnable version of the code at one moment in time — think of it as a numbered snapshot: build 4.2.18 is a specific bundle that either contains Omar's Tuesday fix or doesn't. Deploying means installing a build into an environment. So the everyday sentence "the fix was deployed to staging in build 4.2.18" decodes as: this exact snapshot, containing the fix, is now running on the rehearsal copy.

Why testers care intensely: your test results are only meaningful relative to a build. Testing "the app" means nothing; testing "build 4.2.18 on staging" means everything. If you verify a fix on the wrong build — one from before the fix landed — you'll report the bug as still broken, the developer will insist it's fixed, and you'll both be right about different snapshots. Every experienced tester has lived that argument exactly once.

Why Environments Differ — and Why It Bites

Staging is built to resemble production, but the resemblance is never perfect. The data differs: staging has fake travelers and a handful of test properties; production has millions of real records with all the weirdness real life accumulates. The settings differ: features can be switched on in staging that are off in prod. And the outside connections differ — this one produces the most confusion, so here's the concrete version.

Fernway's payments run through Paylane. Real charges would be unacceptable in testing, so staging talks to Paylane's sandbox — a pretend version of the payment service that Paylane provides exactly for rehearsals: it accepts test cards and moves no real money. One Thursday, every payment on staging starts failing. Is checkout broken? You mention it to Omar; he checks — Paylane's sandbox itself is down for maintenance. Production, which talks to the real Paylane, is fine. Same Fernway code, different environment, different behavior — and the bug you almost reported wasn't a bug at all. The general lesson: "works on staging, breaks in prod" (and the reverse) is usually an environment difference, not a mystery, and the first debugging question is always "what's different between the two copies?"

The Two Questions That Start Every Investigation

All of this compresses into a habit you'll use daily from now on. Before investigating anything — a bug you found, a bug someone reported, a fix you're verifying — establish two facts first: which environment, and which build. A bug seen on staging build 4.2.18 might be already fixed in 4.2.19, absent in production, or caused by staging's sandbox connections. Until those two answers are pinned down, you don't yet know what you're looking at. Chapter 6 will bake both questions permanently into your bug report template; consider this their formal introduction.