Environment parity
Keeping local, staging, and production alike where behavior depends on it, so passing in one environment predicts passing in the next.
What it is
Environment parity means development, staging, and production differ as little as practical in the things that change behavior: runtime and database versions, dependency lockfiles, config shape, backing services, and build process. Dev/prod parity is factor ten of the Twelve-Factor App, written by Adam Wiggins at Heroku in 2011, and it is there because a test environment is useful only when its result predicts production.
Reach for it when releases repeatedly fail with 'works on my machine', or when staging passes work that production rejects. Pin versions, build one artifact for every environment, provision infrastructure from the same templates, and validate that each environment supplies the same set of configuration keys.
Gotcha: parity does not mean copying production customer data or giving developers production credentials. Data volume, traffic, and third-party sandboxes will still differ. Use synthetic data and safe credentials, then make those deliberate gaps visible so nobody mistakes staging for a perfect rehearsal.
Ask AI for it
Audit this app for environment parity. Pin the Node version in .nvmrc and package.json engines, pin service image versions in Docker Compose to the same major versions production runs, and use the same lockfile and build command in local, CI, staging, and production. Define the configuration shape with a Zod schema, fail startup when a required key is missing, and add a CI check that compares key names across environment templates while allowing values and secrets to differ. Use synthetic seed data and sandbox API credentials outside production.