Copies of the whole system

Think of it when you test something and must know where the test really ran, or a test could reach real users or real money.

In everyday life

A flight school trains pilots in a simulator and flies passengers in a real plane. A simulator that is secretly wired to a real plane’s controls is no longer a safe place to practice.

One case

A developer tests a new “cancel every booking on a date” button for a hotel booking site on their laptop. Last week they pointed the laptop at the production database to chase a bug, and they never switched it back. The test cancels 312 real bookings for Saturday, and the support team spends the weekend apologizing.

The laptop copy pointed at the real data
The case, cell by cell1 cell = 1 environment
Database it should use
localstageprod
Database it used
prodstageprod
Real bookings cancelled
312
One leftover setting made a test on a laptop act on real customers.

Every case

Teams run the same code in several places so that they can try things where mistakes are cheap. A mistake on a laptop costs little; a mistake in production reaches real people and real money. That protection works only if each copy is really separate: its own database, its own keys, its own email sender. One setting that points the wrong way turns a safe test into a real action.

The word

Engineers call this

environmentsSeparate copies of the whole system for different jobs: your laptop for building, a stagingA copy of the system set up like production, used to try a change before real users see it. copy for testing, and productionThe copy of the system that real users use, with real data. Engineers often call it prod. for real users. Each copy has its own settings and its own data.

Give each environment its own data and keys, and make it obvious which one you are in. Try a change in a copy before production, and never give a test copy production keys.

Where this idea leads

Skills that encode it

  • create-verification-skill pstackWhen the safe path is a dry-run or test mode, verify what it actually skips by observing, not by trusting its name.
  • full-send tstackUnattended work may run the tests it needs, but touching production or deleting data still waits for the user.
  • principle-never-block-on-the-human pstackIrreversible actions, such as deleting production data or sending external messages, still require confirmation.