Nine teams share three static UAT environments. About one release in four slips a week because an environment is broken or holds another team's half-finished data. Fidelity to production is good. Which investment fixes the delivery problem?
Show the full answer Hide the answer
The deciding property
The stated failures are contention and shared mutable state, not fidelity. "Broken" and "holds another team's data" are both consequences of nine teams writing to three environments. Parity dimensions - instance types, data volume, topology - decide which defect classes an environment can catch. They do nothing about an environment being occupied, and the question says fidelity is already good.
The second property is diagnostic: in a shared environment, a red result has nine candidate causes, so investigation cost per failure is high and trust falls until nobody treats a red UAT as information. An environment holding exactly one branch has one candidate cause.
Why on-demand wins here
Swiggy has published its version of this move: static UAT environments had become blockers because of instability, unavailability and data corruption, delaying releases, so the team built an ephemeral environment service where an environment is created for one branch and contains no other code changes. Two governance details in that account are the ones teams miss: each environment has a maximum time-to-live, and each team gets a budget of environment units. Without the first, ephemeral environments quietly become static ones; without the second, the estate grows until cost forces a reversal. They report supporting more than 150 parallel environments, with weekend infrastructure cost visibly below weekday cost - which is the real economic argument, because capacity now tracks demand instead of being provisioned for peak.
Why the other options fail
- A booking calendar. It converts contention into an explicit queue, which is honest and does not create capacity. Nine teams on three environments is already high utilisation, and waiting time climbs steeply as utilisation approaches saturation, so the calendar mostly makes the delay visible. Worth doing in a week while the real fix is built - not instead of it.
- Matching instance types and data volume. The textbook parity answer, and the right spend when escapes are performance regressions that staging cannot reproduce. Here it buys fidelity the team is not currently losing defects to, and it makes each environment more expensive, which makes having more of them harder.
- Nightly production replication. Makes the data realistic and leaves it shared and mutable, so the corruption problem returns by mid-morning. It also moves production personal data into a weaker environment, which converts a delivery problem into a privacy obligation.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Escapes are performance regressions | Invest in parity on one environment | per-branch copies are too small to reproduce capacity limits |
| An environment needs a licensed appliance or a 4 TB dataset | Virtualise the dependency and keep one good shared environment | per-branch provisioning cost exceeds the contention cost |
| Only two teams share the environments | Booking calendar | at low utilisation a queue is nearly free and the platform work is not justified |
| Tests need multi-team integration by design | Keep one shared integration environment for that suite only | the thing under test is the interaction between teams' changes |
When this is the wrong answer
When standing an environment up takes longer than the test it serves. If provisioning is 40 minutes and the UAT pass is 15, per-branch environments move the wait rather than removing it - fix provisioning time first, then move. The threshold to aim for is an environment in under ten minutes with its data; above that, the model stops feeling on-demand and teams start keeping theirs alive, which is how you end up with nine static environments instead of three.