Vagrant: Up and Running

Foreword

Jeff Sussna

Founder and Principal, Ingineering.IT

Every so often, you encounter software that immediately strikes you with its combination of clarity, simplicity, power, and usefulness. You simultaneously say “wow!” and “why didn’t I think of that?” But you couldn’t have thought of it. It needs an author who can conceive and implement that particular vision, not just appreciate it. Vagrant is that kind of software, and Mitchell Hashimoto is that kind of author.

Software as a service dramatically lowers the cost of change for its users. As a result, they come to expect near-instantaneous responsiveness from software vendors. The ability to continuously deliver new features is taking its place alongside the features themselves as a competitive advantage. Service providers face the conundrum of needing to accelerate velocity without sacrificing quality. Vagrant provides a critical contribution to solving that problem.

Agility experts often talk about John Boyd’s OODA (Observe-Orient-Decide-Act) Loop. An Air Force pilot, Boyd developed the OODA Loop concept to describe the process of reacting to an enemy during airborne battle. Victory came from “getting inside your enemy’s OODA Loop”—in other words, being able to react, respond, and change more quickly than your enemy.

Approaching software delivery as a form of battle requiring fast reflexes conjures up visions of fear, tension, and sweat. But fear and tension lead to mistakes (aka bugs). How do you get inside your competition’s OODA Loop without working 24 hours a day or permanently raising your blood pressure? The answer lies in automation.

Automation lets you wring unnecessary manual effort, along with opportunities for mistakes, out of the process. It also allows you to move faster without worrying about getting things wrong or leaving things out. Consistent automation throughout the software lifecycle further reduces chances of mistakes due to variation. If you test your software against exactly the same system configuration that’s running in production, you’re more likely to catch the right bugs, and less likely to waste time fixing the wrong ones.

Vagrant brings configuration automation all the way down to the developer’s desktop. With it, you can package the same operating system that runs in production—along with the same configuration automation scripts—in a form that’s easily shared among developers. Instead of spending the first two days on the job installing software, a new development team member can spin up a production-identical environment on their laptop simply by typing vagrant init then vagrant up.

With Vagrant, a new developer can get started delivering value in an hour instead of a day. All the developers on the team can update their environments with a new software version in minutes, instead of hours, simply by typing vagrant provision. Then they can all get back to valuable work, secure in the knowledge they’re all building against the same version as production and as each other. In other words, they can go faster, without fear.

I like to think of Vagrant as the Git of development clouds. Centralized development and test environments create bottlenecks. Vagrant lets developers work at their own pace and in their own environment, while keeping all the environments synchronized with each other. Flexibility joined with consistency is the best and sanest way to tighten a team’s OODA Loop.

Finally, in addition to writing great software, Mitchell has always done a good job of writing documentation. The Getting Started tutorial on the Vagrant website is a great way to…well, get started. This book continues the tradition of helpful Vagrant documentation. It’s useful for beginners and experts alike. It does a great job of balancing basic concepts with behind-the-scenes technical details. Even experienced Vagrant users will learn some new tricks. Just as Vagrant belongs in your Continuous Delivery toolkit, so too Vagrant: Up and Running belongs on your bookshelf.