For decades, software delivery has carried a quiet burden: the weight of multiple environments. Dev. Test. UAT. Pre-Prod. Finally, Production. Each with its own quirks, dependencies, and inevitable drift.
It made sense once, when change was slow, infrastructure expensive, and delivery cycles measured in quarters. Each environment was a checkpoint. A way to create distance between developers and production. A way to prove safety through ceremony. But in 2025, the world looks different. Infrastructure is cheap and elastic. Cloud-native tooling can spin up a new environment in minutes. Deployment cycles are measured in hours, not quarters. And customer expectations? They demand speed, personalisation, and responsiveness.
In this world, the environment bloat is less a safeguard and more a bottleneck. Instead of flow, it creates handoffs. Instead of confidence, it creates inconsistency. And instead of speed, it gives us excuses for delay.
The traditional Dev → Test → UAT → Pre-Prod → Prod chain carries hidden costs that organisations often underestimate:
- Lag: Each environment is another queue. Developers wait for approvals, for data refreshes, for “UAT windows” that only open once a week. Time slips away not because the code is complex, but because the environment is busy.
- Drift: No two environments are truly identical. Configurations differ, data subsets differ, integrations behave differently. “It worked in Dev but broke in UAT” isn’t bad luck—it’s drift playing out in slow motion.
- Overhead: Maintaining multiple environments is expensive. Each one needs infrastructure, patching, monitoring, and people to care for it. And when environments diverge, we end up testing ghosts of production, not production itself.
The net effect? We slow delivery in the name of safety, while ironically increasing the chances of surprises when code finally hits Production.
We’re playing a game of staged theatre, pretending that if the actors deliver their lines well enough in rehearsal (Dev, Test, UAT), the live show (Production) will go perfectly. Anyone who has shipped software knows the truth: Production is the only real stage.
It’s important to understand why this system existed in the first place. Legacy environments were born in an era where:
- Hardware was scarce: Getting a new server meant procurement cycles, vendor negotiations, and capital expense. Naturally, teams shared limited resources across environments.
- Change was risky: Quarterly or annual release cycles packed thousands of changes into a single deployment. Big bang releases demanded heavy gatekeeping to reduce the blast radius.
- Testing was manual: Dedicated UAT phases existed to marshal armies of testers through scripts, ensuring nothing obvious slipped through.
These were reasonable responses—for that era. But what was once a guardrail has now calcified into ritual. We carry forward the structure of multiple environments long after the reasons for them have disappeared.
Modern Flow Patterns
We don’t need four or five heavyweight stages anymore. Alternatives exist that align better with modern delivery—leaner, faster, safer.
1. Ephemeral Environments
Instead of static Dev/Test/UAT servers that live for months or years, we can create ephemeral environments on demand.
- How it works: For every branch, pull request, or feature, spin up a production-like environment automatically. It has the right dependencies, data shape, and integrations.
- Why it’s better: Testing happens in context, not on a shared, drifting environment. Developers see exactly how their change behaves in a near-production setup. When the feature is merged, the environment is discarded—no drift, no overhead.
- Impact: Waiting disappears. Conflict over “who broke UAT” disappears. Environments become cattle, not pets.
2. Feature Toggles
Even with better environments, we still need control in Production. This is where feature toggles (or flags) matter.
- How it works: Deploy code continuously, but hide features behind toggles. Switch them on for internal users, beta testers, or a fraction of customers. Switch them off instantly if something goes wrong.
- Why it’s better: Deployment and release become decoupled. We stop tying new code to big-bang “release weekends.” Instead, features roll out progressively, with flexibility baked in.
- Impact: Risk drops dramatically. Teams can ship daily without fear, because features can be controlled at runtime.
3. Progressive Delivery
Ephemeral environments and toggles set the stage. Progressive delivery completes the picture.
- How it works: Roll out new code gradually in Production itself—via canary releases, blue-green deployments, or percentage rollouts. Observe metrics, error rates, and user behaviour in real time before going wider.
- Why it’s better: You’re validating with real traffic, real data, and real conditions—not hoping a stale UAT database will reveal the same issues.
- Impact: Surprises still happen—but they’re contained. Instead of breaking all users, you impact 1% first, fix, and expand safely.
Together, these practices turn delivery from a rigid chain of gates into a tight loop: build → validate → release.
This shift isn’t just about environments—it’s about how you stitch the flow together. And here, pipelines and automation are the backbone.
- CI/CD Pipelines: Code moves seamlessly from commit to build to deployment, with tests, security scans, and checks baked in. No manual handoffs.
- Automated Provisioning: Ephemeral environments spin up with a single commit, using infrastructure-as-code. No tickets to infra teams, no waiting for “environment availability.”
- Toggle Management: Feature flags are tracked, versioned, and auditable. Toggling isn’t tribal knowledge—it’s governed and observable.
- Progressive Rollout Control: Pipelines don’t just deploy, they orchestrate rollouts. Canary to 1%, then 10%, then 100%—all with guardrails and rollback baked in.
The irony? By killing environment bloat, we don’t lose safety—we gain it. Faster feedback. Lower risk per change. Less dependency on fragile, long-lived test beds.
The industry has outgrown the idea that safety lies in more gates and more environments. That mindset confuses ceremony with certainty.
Real safety today comes from:
- Automation: Every test, check, and rollout step repeatable, consistent, and codified.
- Speed: Smaller, frequent changes are less risky than giant, infrequent releases.
- Observability: You don’t need a UAT sign-off when you can measure live performance, errors, and user behaviour in real time.
- Resilience: Systems designed to fail gracefully, with rollbacks and toggles ensuring that no single change can cause a meltdown.
This isn’t about cutting corners. It’s about recognising that the old idea of safety—more environments, more approvals—creates the very fragility it’s supposed to prevent.
Moving away from environment bloat isn’t only technical—it’s cultural. Leaders, managers, and teams need to unlearn habits like:
- Believing that every gate reduces risk.
- Equating a UAT sign-off with confidence.
- Treating environments as assets to hoard instead of tools to automate.
- Thinking “it’s always been this way” is justification enough.
The real challenge isn’t the tooling. It’s the mental model. The organisations that win will be the ones that trust automation, embrace progressive delivery, and stop clinging to outdated rituals.
The industry has changed. Customers demand speed. Teams demand flow. Infrastructure makes environments disposable, not precious. Yet too many organisations remain chained to the ghosts of Dev, Test, UAT, and Pre-Prod. It’s time to kill the environment bloat. Not recklessly, but deliberately—replacing it with ephemeral environments, feature toggles, progressive delivery, and automated pipelines.
Because the truth is simple: the only environment that really matters is Production. Everything else is scaffolding. The question is whether we’re willing to let go of the scaffolding and build systems that can stand on their own. The sooner we shed the environment bloat, the faster we can move—and the more confidently we can deliver.
C
Comments
Post a Comment