“It works on my machine.” And it does. So no more discussion is required.
“I have written the code. I have tested the code and the code works on my machine. What else do you want me to do?”
This type of conversation with a developer has happened the world over probably ever since there was more than one computer on which to test someone’s code. As we all know, all developers (and their working environments) are not made equal. Some can be running Windows, some OSX, some MAMP, some WAMP, some use Eclipse as their IDE and some vim (although I don’t know why) and of course, in each of these environments they will need to have any number of modules installed within their stack to ensure the application they are working on… works.
In the old days you would have a systems engineer to set up everyone’s computer the same, lock down those parts that developers shouldn’t reach and ensure that we all lived in a single, homogenised environment; free from the complexities of PHP modules versions CMD, the Windows Control Panel, COM+, shared DLLs, homebrew and yamping and so on. But these days you want a developer to be able to get the code from your version control, setup the database install some dummy data and go (away) and start coding. Safe in the knowledge that the code and application environment they use is the same as the one that all of your other developers are using so that you need only worry about the code that is being written and not the underlying infrastructure.
It’s analogous to the developer/client problem but more server related and less browser related. You know the kind of thing: the development team use state of the art, weapons grade OSX, quad core hyperdrive with Trackpad, a magical mouse, thunderbolts and lightening whilst the client is running their ten million pounds global business from a 15″ IBM Thinkpad, heavy enough to kill and slow enough to make an asthmatic ant believe they could run the London Marathon. Oh, and the Thinkpad runs Internet Explorer 7 and a Google Chrome installation causes it to convulse on the desk whilst complaining about fatal errors and had a little tiny fit of blue.
The issue here is one of consistency and being able to on-board a developer to a project without worrying that their machine will be missing some critical component. They can use which ever IDE they prefer and their project instance will just work.
One way to achieve this would be by using some kind of virtual machine (VirtualBOX, VMWare etc) but nobody wants the hassle of setting those up. So, what about using Vagrant? This is a piece of software that provides a wrapper for the virtualisation layer of an environment, essentially it takes control of setting up a virtual machine and with a few simple commands has you running a full LAMP stack and your application or website. Genius! Of course this isn’t necessarily a new thing, we all know about Docker and containerisation but the important point is that it works… every time (pretty much).
We here at Miromedia decided that using this approach to development our projects would make life some much easier and give us back control of our code via GitHub, without the problems of creating new dev sites on our live server and having to work via SFTP. The added bonus also being that I (or any developer) can now run and develop a project in the office on an iMac, at home on a Windows laptop or during a meeting on a MacBook Pro.
So now that we have implemented Vagrant into our development process it has become much, much easier to kick off a new project and get everyone up and running with exactly the server they need, create and install database data and then get coding.