Arguments against a shared development environment

Question

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:

1. Dev works on a piece of functionality on their working copy of the project branch
2. When they are confident it works, test the change in the shared development environment
3. Check it in

So several obvious issues arise here:

1. Since a lot of overlap occurs between projects, there is often contention for resources
2. 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)
3. 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.

Answer 1

The main problem I can see here is that you have no way of creating a consistent, reproducable release by having people push into the shared dev environment.

Generally speaking, you would all be running local development environments and committing your changes into a central code repository. You would then build your releases from that central repository.

That way you will know exactly what version you have released into your QA environment and you will be able to consistently reproduce that version and apply it to other environments.

This also lends itself nicely to having an automated build process which means that the build happens exactly the same way everytime so that you're not relying on manual steps to ensure a build happens which will reduce inneficiencies around people "breaking builds" when they forget to deploy manually.