Most developers support a plethora of projects. Setting up development machines with the tools and components necessary to work on all of these projects is problematic. Especially when development environments aren’t even close to the production environments they’re hosted in.
Partitioning the tools for each project into virtual machines and automatically creating virtual environments can give organizations a significant edge.
Gone are the days of:
- Wondering what is necessary to work on a project.
- Trial and error to setup development machines.
- Interrupting others to help you out.
- Relying on out-dated instructions to set things up.
- Conflicting tools and bogged down development machine resources.
Replaced by:
- Know what software is necessary for a project, software versions and configuration.
- A history of why, when, who and how this software was incorporated by versioning the definition of environments.
- Eliminate surprises by developing in an environment much more like production.
- Safely creating and testing scripts to automate the setup of environments.
- Reduced time to get a project up and running.
- Happier customers, due to less problems in production.
Last week, I spoke about this at the Omaha .NET User’s Group. In the first half of the talk, I enumerate many reasons why this is valuable and then walk through an example of building a MongoDB development environment with Vagrant to use in an ASP.NET MVC application.