Published on April 25th, 2014
Estimated Reading Time is 3 mins
I was first introduced to the concept of virtual development boxes during summer 2012 when Stephen Lewis presented at EECI in Leiden.
I hadn’t really give it any more thought until we started using it as part of the development process for Paul McCartney.
McCartney’s site is a Drupal instance and there are 3 of us building the site - 2 PHP developers with myself on front-end duties.
Having cloned our repo from Bitbucket (other Git hosting services are available), we then run the vagrant up command. This starts to build the development box on our local machines. We’re using Puppet for provisioning and this sets the virtual host, PHP version, the PHP modules/extensions that are being used, MySQL version, root password for MySQL, Sass + Compass (as well as any other gems we use for Sass).
It means that if any new developer were to join the team, they don’t need to go download all of those things to get to work. They just download VirtualBox & Vagrant, clone the repo, run
vagrant up and update their local host file to point to the virtualhost.
That process take 5 mins for a developer to get a working copy of the site — our particular setup also migrates content from the current live site down to our particular instance.
One of the really cool things with the new version of Vagrant is Share — it allows you to give anyone, anywhere access to your development instance without needing to configure firewalls or any of that nonsense.
vagrant login which logs you into Vagrant Cloud (free for now) and then
vagrant share which does the magic and gives you a unique URL.
This has so many benefits:
Easy SSH sharing is incredibly useful if you want to give access to a colleague for troubleshooting ops issues. Additionally, it enables pair programming with a Vagrant environment, if you want! Vagrant Docs
This won’t replace an actual staging environment for clients but it’s incredibly useful if you need quick feedback on a client site and don’t want to do a screenshare.