Vagrant is an awesome tool and works really well–for most applications. At WDS, a LOT of our peeps use Vagrant for their day-to-day activities, and chances are you’ve seen Brad Parbs‘ VV at some point, or may be using it right now. However, there comes a turning point in every developer’s life where he/she must evolve, or, in some cases, devolve. So here’s my story.
My Development Evolution
When you start developing, you’ll quickly realize you need to get some sort of development environment up. In the beginning, I was actually using direct FTP before I had heard of GIT or any sort of version control. I started out by using Dreamweaver for FTP and syntax highlighting, this is back when they were owned by Macromedia.
It wasn’t until about a year before WDS that I started using Sublime 2, and slowly evolved into using PHPStorm, which I now use daily. However, my coding application isn’t all that evolved. Upon starting with WDS I was actually using Xampp, since I’m a Windows guy. Xampp for me was my go-to development environment for the longest time considering its ease of setup (just download a zip file) and overall reliability.
The Vagrant Story
Coming from Xampp, Vagrant is a godsend, especially for us non-Linux folks using Windows. For the longest time, Vagrant fans preached to me; it’s SO MUCH BETTER they said, and indeed it was. With Xampp, I had to edit the vhosts file, create a database, and download and install WordPress by hand any time I wanted to create a new site.
For awhile it worked fine, but then came my never-ending thirst for knowledge. I thought, “Hmm, so what is this Vagrant?”
I decided on a whim to install it and give it a go. After about a two hour session with Parbs on getting set up, it was installed, and I was so happy. Now, I only needed to run one nifty little command vv create and I was up in just a few minutes.
About a year after installing and using Vagrant regularly for my day-to-day environments, I’m eternally grateful for the speed with which it sets up projects and its simplicity–no more juggling vHost files/settings or setting up SQL databases! Overall, I was happy in my ignorance regarding how to actually do most of this myself.
Vagrant’s Demise
Earlier this year, PHPStorm released an update that allowed project-level interpreters, as well as the ability to use PHPcs remotely, which is absolutely amazing! For my day-to-day, I actually set up Vagrant as a remote interpreter, set it to use the PHPcs installed there, and it pretty much worked as intended.
However, over time, with more projects, Vagrant started to slow down. Taking upwards of twenty to thirty minutes to either up or halt the VM is just absolutely absurd! If I wanted to take my laptop somewhere and work (in sunlight), I was forced to copy the required databases and files/Git to the laptop just to go somewhere. And believe me, some projects are gigabytes of data.
This presented a REAL problem for me. By nature, I’m not that mobile; I tend to work in front of my quad monitor setup daily from nine to five, and if life threw me a curve ball, I had to adapt or take a personal day. Having to ‘prep’ to leave sometimes would take hours depending on which project I was scheduled for. Failing to meet a deadline is absolutely unacceptable, regardless of the reason.
Project Overload
Vagrant is a box. We know this. It’s a virtual machine that is meant to operate as if you’re looking at a completely separate machine. The first and most obvious benefit to a Windows user like me is that I can comfortably develop for a Linux OS without having to install Linux. However, the amount of projects we work on daily at WDS varies; we have our slow days, and we have crunch time. Just like any other developer, I typically leave a site installed on Vagrant until our client is out of the support phase.
This is the problem, at any given time I have ten to twenty sites online at the same time, on one Vagrant box. The startup time for the box was just horrendous; I could literally go make a sandwich, drive to Starbucks, and back again, and it still wouldn’t be done. When Vagrant starts up, at least from my understanding, it has to go through a sort of ‘provisioning’ startup process. Reading all those configs, starting up the database, etc…the amount of time it took was just unreasonable.
Halting the virtual machine was even worse. Have you ever tried backing up 20GB of databases on 2GB of ram? If so, I’m sure you feel my pain. During shutdown, Vagrant has to backup the databases, which led me to simply leave it on for quite some time. However, the longer it was on, the more problems I had–MySQL out of memory, PHP freezing, and more. This just added to my development time.
Lack of Mobility
For me, as I said, mobility with a Vagrant install is limited. There are definitely options out there however, like “Moving VirtualBox and Vagrant to an external drive,” so it can be done if you’re okay with lugging around a hard-drive or thumb-drive. For me, that’s unacceptable; this is the age of the cloud, yeah? Having to take a hard-drive with me was not going to happen.
This led me to ‘backing up’ my SQL databases, project files (including .git files), and even in some cases the entire /uploads directory onto my little 16GB thumb drive. Copying over these things would take hours, especially if I had more than one project for that day. This, in turn, led to me having to pretty much prep hours ahead of time, and with three kids, that’s not much sleep time if I have to get up more than two hours early.
The Solution
A fully remote development environment.
For about two years I’ve owned a rack server from SoYouStart.com. It has mainly held my gaming servers and my personal websites. However, with a whopping 2TB of space, I was utilizing a mere fraction of what was available, so with the additions of the new PHPStorm features, I figured I’d try it out.
For security reasons, I obviously don’t keep the GIT credentials on my server. I’d really hate for it to get hacked or something and someone gain the ability to push/pull code changes, so I do ‘technically’ have all the code locally as well.
Having it setup in this manner allows me to keep the code and databases in one location for every project. This means if I need to just grab the laptop and go, now I can do that. I don’t have to worry about bringing a database and/or files to sync on my laptop–all I need to do a pull when I sit down.
Additionally, if I need to illustrate something to another developer or designer, or if something is broken on my local versus the client’s site, it’s easier to debug. Utilizing a remote server allows users the ability to actually view my development environment instead of limiting us to just a Skype screen-share.
And that’s why I stopped using Vagrant.
Have any of you had the same issues? Who else has tried a fully remote development environment?