Hey everyone! I've been encountering a common challenge with coordinating shared dev and test environments among teams. It seems that when developers, testers, or even salespeople share the same setups, conflicts arise often. For instance, one person might deploy a new version while another is testing a bug fix, or multiple developers might test features simultaneously on the same environment. We even tried using a spreadsheet or Wiki to book time for testing, but sometimes team members forget to check it. Just recently, I was set to present a feature to a customer, but someone had overwritten my deployment. Although we could add more environments or allocate one for each developer, that would be costly and require more upkeep. How do you all handle this situation?
5 Answers
We implemented tagging on our data objects so that users can't access data meant for someone else. It doesn't solve every problem, like when someone deploys broken code, but it helps keep things organized and avoids a mix-up during testing.
One trick is to make it super easy to create and delete environments. Also, encourage developers to do as much testing on their local machines as possible to limit the time spent using shared resources. If you have a lot of developers and apps, you might want to have at least a few environments like dev, QA, and production, especially for sales.
It sounds like you're dealing with some classic resource contention issues where the number of users exceeds the number of environments. One solution is to increase the number of environments, which you’ve already considered. You could also try a locking mechanism, like your spreadsheet, to manage reservations better. Here are some additional ideas:
- Consider ephemeral environments that are automatically spun up and torn down as needed.
- Feature flags can help test changes without needing to redeploy.
- Boost automation and code reviews in your CI/CD pipeline to lessen the load on shared environments.
- Using ChatOps tools might improve how you manage access to these environments.
If you have strong local machines, setting up a local dev stack (like Docker) can be a game changer. We have a demo stack for sales, a staging area for QA, and a separate dev environment. Most developers prefer using the local setup as it saves time and reduces reliance on shared environments.
Honestly, I've found Google Calendar to be a bit of a flop for this purpose. People just don't stick to it, which defeats the whole point of scheduling resources.
Agreed! Ephemeral environments are awesome. When a new feature branch is created, automatically spin up a fresh environment, and tear it down when the branch is deleted. This way, you avoid clutter and only have live environments when needed.