Problem:

Creating local development environments is a time consuming process which adds overhead to most development projects.

Sharing environments between collaborators on a project is laborious, involving transferring VM images on portable hard drives, and following lists of manual configuration instructions.

Undesirable shortcuts are typically taken. E.g.: creating a local oracle installation is difficult, so developers will configure a locally-hosted application to use the dev DB infrastructure.

For smaller units of work such as support fixes, this overhead is completely unacceptable and troubleshooting work is generally done directly on infrastructure. This means that it can’t be carried out concurrently with other developments, and also does not work well with CI methods we’re adopting where only stable code can be committed.

Solution:

Use Vagrant to manage VMs for our applications.

The vagrant configuration script will be included with the application in version control.

This means that creating a local environment becomes a simple process:

• Check out the application
• Type “vagrant up” to start up the VM(s)

Including the vagrant script with the application means that changes to the environment are versioned in line with the application.

This approach gives us consistency across developers, and we can ensure the servers match the infrastructure as closely as possible.

A library of base VMs will be created, which can be used and extended by applications.

 Deliverables:

We will identify a current or upcoming development project and create a vagrant configuration for its use. This will serve as a template/proof of concept for other applications.

We will create one or two base VM boxes. These will run CentOS and will strive to be representative of infrastructure. Depending on the project chosen, they could run:

• ColdFusion
• Tomcat
• Oracle
• PHP
• Python

We will create a wiki page with instructions/FAQ about using vagrant in this way.