Keep Your Local Development Environments Separate

Submitted by admin.greatens.com on Fri, 05/04/2018 - 01:17

One of the things I love about my job is that HS2 Solutions employees are encouraged to experiment with pet projects. Usually a pet project is to experiment with a new technology and other times a pet project is to build a tool or system that makes my job easier. Recently, my pet project has been both.

About a year ago, I started looking at Vagrant and the more I have used it, the more I find it invaluable. With Vagrant, a developer can create a virtual development environment on her computer without changing anything on the host computer. In order to build a virtual development environment, Vagrant is used in conjunction with virtual machine software like Virtual Box or VMWare.

Creating a a virtual development environment on a development machine is valuable for a number of reasons. At the top of the list is that the developer can setup multiple environments at the same time. So, if the developer is working on multiple projects at the same time (I know project managers, this never happens.) and the development environment for those projects needs to be different (e.g. the programming language version is different), then the developer has to remember how to tweak those environments as needed. This assumes, of course, that the developer even knows that there is a difference. Next, the developer can setup an environment that is as similar to production as possible. There will always be differences for very large sites (e.g. not using a load balancer in the development environment), but the majority of variables can be locked in place. As a bonus, if you want to change one of those variables (e.g. upgrading the version of the programming language). One developer can do that on their instance of Vagrant and if the experiment goes amiss, the developer just rebuilds her environment from a previous version of the Vagrantfile and all is back to normal. In addition, you can also build multiple computer environments. So, if you use a web server, a database server, a caching server, and a reverse-proxy server, you can mimic that environment on your laptop. No more getting surprised when moving a system to a staging or testing environment. Next, once someone defines the environment in a Vagrantfile, anyone can have the environment setup on her computer quickly. This is very useful if you have people that are not comfortable setting up the technologies (e.g. Linux, Apache) that are used in your production environment. (Trust me, your DevOps team will thank you.) Finally, because it takes much less time to setup and it is easy to change back to a different environment, you can easily move someone onto a different project for a day to help out in a pinch.

Vagrant can be used in a very simple way or it can be used in very complex ways. You can build a single computer environment or you can build a multiple computer environment. And in a multiple computer environment, each computer can use a different guest operating system. Again, you can mimic, as closely as you want to, your production environment. The networking can be very simple (e.g. just using port-forwarding to forward a port on the host to the guest) to having a bridged network so that anyone on your network can reach the virtual environment. The host computer can also have synchronized folders with the guest environment, so files can be changed in either place. I use this because I have an IDE I like on my MacBookPro, but I sometimes like to edit files with vi on the Linux system.

All in all, I am very happy I discovered Vagrant and I continue to marvel at all I can do with it. In future blog posts, I plan to write up how to create a multiple computer environment that mimics the environment many people use for a moderately complex Drupal environment.

 

Tags