Hey everyone! I'd like to discuss a challenge that seems pretty common among dev teams. We often run into issues when multiple people use the same development or testing environments. Here are some typical scenarios: a developer might deploy a new version while someone else is in the middle of testing a bug fix, or another developer cleans up an environment just before a big presentation to stakeholders. It gets even trickier when two devs are testing integrations with the same IoT device, potentially messing up each other's tests.
We've tried using a spreadsheet or a wiki to book environments, but it hasn't worked perfectly—sometimes devs forget to check if the space is already booked. Recently, I ran into trouble when I couldn't present a feature to a customer because someone else overwrote my deployment. Sure, we could scale up and create more environments for each dev or team, but that would be costly and require extra maintenance. How do other teams handle this without running into conflicts?
4 Answers
We use optional tagging attributes for data objects, which helps manage access. For example, application users can’t interact with data tagged for someone else. Although it doesn’t fully solve the issue of someone deploying broken code, it prevents others from accessing it. Everyone should be quick to find and revert major issues, right?
It sounds like you're experiencing classic resource contention—when you have more users than available environments. You've already pointed out a couple of solutions: either increase your environments or improve the booking process. Here are some suggestions to mitigate the pain:
- Consider using ephemeral feature environments that are automatically created and destroyed according to the testing lifecycle.
- Feature flags can allow testing changes without requiring redeployments.
- Boost your automation practices to lessen the reliance on shared environments.
- If possible, enforce source control rules to restrict what's deployable to specific environments.
- Tools like ChatOps can help manage and queue access to shared environments effectively.
I think making environments easy and cheap to create is key. If developers can primarily test their changes locally, it minimizes the need for shared environments. If you've got a lot of developers, I’d recommend at least four dedicated environments: dev, staging, pre-production (for sales), and production. This way, everyone can work more independently without stepping on each other’s toes.
Having robust local machines can solve a lot of these headaches. I built a local dev stack using docker-compose and K3S. It allows everyone to work independently. We also maintain a few dedicated stacks: a demo for sales, a staging for QA, and a shared dev environment. Most of the work happens locally, reducing congestion on the shared platforms.
Absolutely, ephemeral environments work wonders! Whenever a new feature branch is created, an environment can be spun up. Once work on that branch is completed, it can just be torn down. This also helps prevent environment creep, since unused environments can be auto-destroyed after a set period of inactivity.