A more useful Vagrant
making Vagrant case sensitive
Raison d’être
If you’re developing on and deploying to different machines, you are probably familiar with the “It works on my machine!” scenario.Someone on the team pushes his latest working code to the repository only to be smited by colleagues for breaking the build. He immediately goes on the defence, stating that “it works for him”.
Often these predicaments are the result of the distinction between the developers’ machines and/or the machine their code is deployed to. For web projects I’ve found case sensitivity and the configuration of the webserver to be the biggest differentiators.
With most projects being deployed on case sensitive*nix platforms and developers using Mac OS X or Windows, both of which ignore case, this can lead to collisions in filenames when pushing or pulling to a git repo, or problems when auto-loading classes on the server.After years of using MAMP and mitagating these issues post-deployment, I was ready for a solution that would save me these mini-heartattacks.
Enter Vagrant.
The idea behind Vagrant is rather simple, it allows you to define a virtual machine’s state in a single file.You describe the setup of the guest OS and use provisioning scripts to install and configure the software required. A simple “vagrant up” command brings the virtual machine to life and prepares it for work.
This allows you to create a VM for each project which mimics the deployment server and runs your code during development. A shared folder allows you to work on said code in your favorite (host) OS and editor while achieving dev/prod parity.
Perfect, right?
Faux Pas
Unfortunately there’s a serious caveat. The code is stored on the developer’s physical machine (the host OS) not the VM (guest OS), the folder containing the source code is then shared with the VM where it is mapped to a webserver’s document root.
But because files are accessed through the host OS, the guest OS inside the VM will treat the files in the shared folder the same way the host does. Even if the VM is using a case sensitive filesystem.
This effectively nullifies using Vagrant to solve the above stated problem.(Though to be fair the issue lies with VirtualBox, not Vagrant but the end result is the same.)
La Solution
(The proposed solution is not full-proof: it won’t work on Windows and it makes automated setup of development environments, which is what Vagrant is all about, a lot harder than it should be. I’d love to hear of a better way, that would work across all OSes.)
A simple albeit not very elegant solution is to create a case sensitive disk image in the project folder.
After mounting the image, you move the code onto it. The folder with the souce code in the project directory is then replaced with an alias or symlink to the mounted image.
Files are now read from the case sensitive disk image and treated as such by the guest OS, closing the gap between development and deployment environment and making Vagrant an actual solution for the problem that lead me to use it in the first place.
You can find a few other proposed workarounds in this ServerFault post.
