Test Environments

Three environments, three jobs. Know which one you're pointed at before you click anything.

Environment matrix

Environment	URL	What it is	Who deploys to it
Local	localhost:3000 (main app)	You run the services yourself on your machine. Fully yours — nothing shared.	You, by starting the apps locally
Dev	https://develop.theinterviews.ai	Shared integration environment. Auto-deploys from the trunk branch (master) on every push.	CI, automatically on merge
Production	https://www.theinterviews.ai (session room: <SESSION_ROOM_URL> — ask a teammate)	The live site real candidates and recruiters use.	Explicit promotion only (see below)

What deploys where

The platform runs trunk-based delivery:

• Push to master → dev. Every merge to trunk auto-deploys to the dev environment. Dev always reflects the tip of trunk, so a ticket in QA/Testing is testable on dev as soon as its commit lands.
• Promotion → production. Production never deploys automatically from trunk. Promotion is an explicit step:
  • Backend services — a semver tag vX.Y.Z on the commit being promoted triggers the production deploy.
  • Frontends — a production branch pointer is moved to the commit being promoted; the production build follows that pointer.

Promotion happens once per epic, after the whole epic is built and tested on dev — never story-by-story to production. See the delivery model notes in QA Process.

Which environment for which testing

Feature QA → dev

All ticket verification happens on dev. The change auto-deployed there when it merged, the ticket's test instructions name the dev URL, and the E2E suite runs against it. If a ticket's instructions say "test on dev" and the behavior isn't there, check that the deploy finished before filing a bug.

Smoke and regression → production, after promotion

After an epic is promoted, run the smoke tier (read-only, free) and the relevant regression checks against production to confirm the promotion landed cleanly. Live AI interview runs against production cost real money and create real data — they are deliberate, manually triggered events, not routine checks.

Destructive testing → local only

Anything that mutates or deletes data beyond a normal user flow — bulk operations, error-path data states, schema experiments — happens only on your local stack, where the blast radius is your own machine.

The dev database is shared

warning

Dev is not a sandbox. The dev environment's database is shared by the whole team — treat dev data as real.

• No destructive data operations (no bulk deletes, no table-level changes, no "let me just clear this out").
• Don't repurpose or break accounts other people may depend on (including the automated test account the E2E suite uses).
• If a test scenario needs data torn down or reshaped, do it locally instead.