Hello,
So a constant headache at my current employer is that we (the devs) all share a common development 'test' environment. The current process is as follows:
- Dev works on a piece of functionality on their working copy of the project branch
- When they are confident it works, test the change in the shared development environment
- Check it in
So several obvious issues arise here:
- Since a lot of overlap occurs between projects, there is often contention for resources
- Since the changes are all manually put out there by a developer, the environment can be in a very inconsistent state (i.e. some services broken, others either newer or older than expected)
- When a developer is testing a service, they can often start and stop the service several times - when your work has a dependency on that service, you sit twiddling your thumbs awaiting them to resolve the issue
I am trying to put together an argument to provide each project (trying for each dev would be shooting for the moon) with their own dev environment. I am looking for what arguments I can make that will make sense to my manager (semi-technical, mostly business, bottom line focused). Here are my current arguments:
- Delivered functionality against a known version of dependencies - makes deployment up the line easier
- Less competition for resources as the project teams are small enough (4-5 devs) that intra team communication is sufficient to allocate resources
- More development testing should catch more defects that would otherwise need to be found in QA
- Should drive out configuration details that are still hard coded
These are good, but I don't think I have hit a home run yet. If you want to make the opposite argument and provide me with some means of making my current environment a better place, I am open to that (though skeptical).
Thanks.