A developer’s workflow
While there is not a standard workflow for a developer that fits all projects and all personal tastes, it is a very common practice to use at least three distinct environments when working on a project. A local , a staging and a production environment. The local environment is usually the developer’s own machine. The staging area is used for user acceptance tests, and finally, if everything works as expected, the changes/fixes/new features are deployed to the production server. It all sounds pretty straight forward.
Where things can get complicated
In the aforementioned flow, a developer will have to build a local environment in his machine. That is , they would have to install all the necessary components themselves. A typical stack would be PHP, MySQL and Apache. For that reason, ready to use packages , like XAMPP or MAMP have been made available to developers. These distributions have been around for years and have been heavily used for local development purposes.
However, web applications have become more complex. There are more technologies and packages involved. Languages, databases and even web servers vary greatly. A developer has to install, configure and maintain all these locally. It is obvious that this can become a hard task. And if we take into consideration the fact that usually there is a team of developers working on a project, keeping all the local machines synced can be a real pain.
We mentioned earlier that a basic workflow would include three environments : local , staging and production. Let’s assume that we just developed some new functionality locally. We tested it on our machine and works like a charm . We deployed the code only to find out that it doesn’t work on staging or production . What gives? This is not a rare situation. Most of the times the problem is caused because our local testing environment is different to the production environment. Perhaps we are using another PHP version. So , it becomes apparent that our local environment must mirror as much as possible our production environments. In addition to that, our different projects might require different services and configurations. Project A might run in PHP 5.5 while project B runs in PHP 7.0. It is obvious that mirroring these different requirements locally can become impossible.
Vagrant to the rescue
So , what is Vagrant? It is a tool that lets us create virtual environments , tailor-made to our needs. We can spin up, suspend and destroy these environments easily. We can even specify the RAM or the CPUs of the machine. The description and the configuration of the virtual machine is stored in a Vagrantfile. Using this file , any member of the team can spin up an identical machine locally.
Taken from the Vagrant website documentation :
“If you are a developer, Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment, without sacrificing any of the tools you are used to working with (editors, browsers, debuggers, etc.). Once you or someone else creates a single Vagrantfile, you just need to vagrant up and everything is installed and configured for you to work.”
I will not get into technical details on how to set up a new Vagrant machine. Vagrant website (https://www.vagrantup.com/) has extensive documentation on the subject. And there is a huge online community that can help you get started. There are also a good online GUI to help you generate a Vagrant file (https://puphpet.com/)