Environment strategy
Purpose: Design the environment set, and the rules for how code and content flow between them.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Tech leads | Environment owners |
| All engineers | Daily "which environment" questions |
The standard set
| Env | Purpose | Topology | Content |
|---|---|---|---|
| local | Development | author (+publish opt.) | Seed + fixtures |
| dev | Integration of merged work | author+publish (+disp ideally) | Seed + synthetic |
| stage/UAT | Release validation, load tests, author training | Production-shaped, dispatcher included | Refreshed prod copy |
| prod | Live | Full reference architecture | The real thing |
The non-negotiable: stage mirrors prod's shape (dispatcher, publish count ≥2, same SP level, same configs modulo endpoints). Every environment-difference is a class of bug you cannot catch before prod.
Flow rules
CODE: local → dev → stage → prod (one direction, via pipeline only)
CONTENT: prod → stage/dev (one direction, DOWN, via refresh jobs)
CONFIG: with code (ui.config per run mode)- Code never skips environments; content never flows up (a content package "just this once" up to prod is how UAT junk goes live).
- Content refresh down: scheduled (e.g. monthly to stage), with PII scrubbing/masking if prod content includes personal data (PII handling) and secrets/users excluded.
- Every environment gets real TLS and SSO (test IdP) — auth differences hide integration bugs.
- Non-prod must be non-indexable and access-controlled; a leaked staging URL with prod content copy is a data incident.
Environment identity in the platform
Run modes name the environment (dev, stage, prod); configs bind to them; visible environment banners on author UIs (a small overlay) prevent the classic "edited the wrong environment" incident.