Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?

Name the cost first

The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" and "testing started". That number, multiplied by six teams, is what the current arrangement costs — and it is usually large enough to fund the fix several times over.

The structural answer: ephemeral environments

Create an environment per change, from the same definitions as production, and destroy it on merge. No sharing, therefore no queue; nothing lives long enough to drift.

What makes this hard is rarely the compute:

• Data. Real data cannot be copied in. Synthetic or masked data must be provisionable in minutes, which is its own piece of work and is the usual reason this stalls.
• Dependencies. Systems that cannot be spun up — a mainframe, a partner sandbox — need virtualising, with stubs derived from recorded interactions and re-verified on a schedule.
• Cost. An environment per open pull request across six teams is a visible bill unless destruction is automatic and enforced by a deadline rather than by discipline.

The most common half-implementation is creating them and never destroying them, which buys the cost of ephemerality with the drift of persistence.

The intermediate step if that is too far

Split the shared environment into per-team slices with separate namespaces and data, which removes the cross-team contention even if it does not remove drift. Less good, much cheaper, and it can be done in a sprint.

The question worth asking anyway

What does this environment prove that the one below it cannot? Six teams queueing for something whose distinct purpose nobody can state is a common finding, and the answer is occasionally that it can simply be deleted — with contract testing and a production-shaped staging environment covering what it was believed to be doing.