Preface
If you have written software on a desktop computer and attempted to deploy your code to another computer (a server), you have already encountered the challenges presented when deploying software. Developers and administrators frequently struggle with errors and defects, when development environments are different from the eventual production machines. There can be a number of differences introduced when the environments are different at the operating system level. Development with desktop operating systems (such as Windows or OS X) can introduce many issues when deploying to production environments that run a Unix (or Linux) environment.
The introduction of desktop hypervisor software allowed developers to develop and test software using virtual machines. A virtual machine is essentially a system within a system, wherein developers working on a desktop operating system can develop and deploy with a copy of the operating system and environment that closely mimics the eventual production environment. When desktop hypervisors became available, development teams found that they could share development environments by sharing the files used by the hypervisors to store the state of virtual machines. In many cases, sharing a virtual machine involved passing around copies of files on a portable hard drive or a shared network folder.
A few years ago, I encountered this specific example when working on a project that involved adding new features to software that ran on an environment, which we could not support with our modern desktop hardware. As many projects reveal, technical debt was introduced to the application by using some very specific features of the Java Development Kit (version 1.5), an environment that was impossible to work on with a 64-bit OS X machine. This machine had dual problems of being a 64-bit machine and it also lacked native support for Java 1.5 XML libraries. The solution to this problem was the creation of a single virtual machine that was shared between developers, passing around a copy of the machine created by a team lead and using it locally to compile and test our modifications.
As time passed by, changes to the environment became an issue, as we began struggling with the differences between not only the development and production environments, but also between our individual development environments as changes were made, making sure that each developer was working on the latest version of the virtual machine on that portable hard drive, which soon had a few different versions itself.
Eventually, the problem of maintaining development environments was large enough to begin looking for new solutions. Configuration management approaches helped us to start defining our environment in code, but we still had issues with sharing and maintaining our base environment. We found immediate use of an open source project called Vagrant, which was gaining some traction.
Vagrant (http://vagrantup.com) is a tool that allows you to define a virtual environment with code. A single file allows you to define a basic environment for a virtual machine as well as a series of provisioning actions that prepare the environment for use. Vagrant works by running code (Vagrantfiles) on top of packaged operating system images called boxes. The Vagrant code and box files can be versioned and distributed using automated tooling. This allows you to share virtual machines, which is not much different than the process of software development that uses source control.
Using Vagrant boxes and provisioning controlled by Vagrantfiles not only simplified the process of distributing virtual machines (and updates to virtual machines), but it also made the virtual machines we were working with inexpensive in terms of effort to rebuild. The amazing thing that we found was that Vagrant not only made it simple to distribute virtual machines, but also gave developers more freedom to experiment and make deeper modifications to the code without losing time due to changes in the development environment that could not be rolled back. This flexibility and a simplified on-boarding process for new developers made it much simpler for the team to spend more time doing software development (and tackling that technical debt!), rather than attempting to fix and find problems due to environments.
I've found Vagrant to be an invaluable tool in my work. I hope that this book can be a valuable resource for you in getting started with Vagrant, or perhaps, using Vagrant in new and different ways.
