Nine teams were taking turns on one staging environment

Description and use

Multiple teams shared a single staging environment, causing frequent failures and attribution issues. Switching to per‑pull‑request isolated environments reduced errors, sped up debugging, and cut costs to £300/month.

Problem

A single shared staging environment caused frequent failures and attribution problems when multiple teams deployed changes, leading to costly manual debugging and slow release cycles.

Outcome

Reduced staging failures, eliminated attribution ambiguity, cut manual debugging time, and lowered cost to £300/month while maintaining shared resources via locks.

Workflow

• Identify need for isolated environments
• Define environment in code (namespace, DB snapshot, stubs, hostname)
• Automate creation on PR creation
• Run soak tests for ~2 h
• Destroy environment on merge or after 12 h
• Use pipeline locks for shared resources

Evidence

We spent most of a morning investigating a staging failure in checkout…

Source

A namespace, a database restored from a sanitised nightly snapshot…

Source