Environments & Parity: Dev, Staging, Production

Software runs in several separate places on its way to users, called environments. The usual three are a developer's machine (dev), a rehearsal environment that mimics the real thing (staging), and the live one where real users are (production). Keeping these similar — parity — is what prevents the dreaded "but it worked in staging".

The point of multiple environments is to test changes safely, away from real users and real data, before anything is allowed near the live system.

Think of a dress rehearsal on the actual stage before opening night: same set, same lighting, same cues — but no audience yet. Staging is that rehearsal; production is opening night.

The Environments

The three common environments each have a role. Dev is where a developer builds and tries things on their own machine. Staging is a shared environment built to closely resemble production, where changes are rehearsed and tested with no real users. Production is the real thing — the live system real people use, with real data on the line. A change typically travels dev → staging → production.

Why Separate Them

The reason to separate environments is safety. You can break things freely in dev, try a risky change in staging without anyone noticing, and only let it touch production once you're confident. If everything happened in production, every experiment would risk real users' data and trust. Separate environments give you safe places to be wrong before it counts.

Parity

Parity means keeping the environments as alike as possible — same kind of database, same configuration shape, same versions. The closer staging is to production, the fewer nasty surprises at release, because something that works in a realistic staging environment is far more likely to work in production. The classic failure is low parity: a change passes in a staging that's subtly different, then breaks in the real world.

Config, Not Code

A key principle (and a preview of the twelve-factor app): the same artifact runs in every environment — what changes between them is configuration, not code. The database address, the secret keys, the feature switches — those differ per environment and are supplied as config. The code itself stays identical, which is exactly what makes "what you tested is what you ship" possible.

The Cadence team tries every change in staging first, with test users and test data, in an environment built to mirror production. Only after reminders behaves correctly there does the same artifact get promoted to production — where real users' streaks are on the line. The code is identical across both; only the configuration (which database, which keys) differs. Staging catches the surprises before real users ever meet them.