virtualization

I've been supporting Drupal VM (a local Drupal CMS development environment) for Windows, Mac, and Linux for the past couple years, and have been using Vagrant and virtual machines for almost all my development (mostly PHP, but also some Python and Node.js at the moment) for the past four years. One theme that comes up quite frequently when dealing with VMs, open source software stacks (especially Drupal/LAMP), and development, is how much extra effort there is to make things work well on Windows.

Problem: tool-builders use Linux or macOS

The big problem, I see, is that almost all the tool-builders for OSS web software run either macOS or a flavor of Linux, and many don't even have access to a Windows PC (outside of maybe an odd VM for testing sites in Internet Explorer or Edge, if they're a designer/front-end developer). My evidence is anecdotal, but go to any OSS conference/meetup and you'll likely see the same.

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

• Should be simple and easy to set up
• Should be fast by default
• Should be flexible:
  • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
  • Should allow configuration of the PHP version.
  • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
  • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
  • Shouldn't have hardcoded defaults
• Should be complete:
  • Should work without requiring a bunch of extra plugins or 3rd party tools
  • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
• Should be Free and Open Source
• Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
• Should work on Windows, Mac, and Linux with minimal or no adjustment
• Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

[Edit: I'm not using rsync shared folders (a new feature in 1.5+) instead of SMB/NFS - please see this post for more info: rsync in Vagrant 1.5 improves file performance and Windows usage].

[Edit 2: Some people have reported success using the vagrant-winnfsd plugin to use NFS in Windows.]

I've been using Vagrant to provision local development and testing VMs for a couple years, and on my Mac, NFS shared folders (which are supported natively by VirtualBox) work great; they're many, many times faster than native shared folders. To set up an NFS share in your Vagrantfile, just make sure the nfs-utils package is installed on the managed VM, and add the following:

Note: See JJG-Ansible-Windows to see how you can get the is_windows variable.

Besides business applications, one of the main reasons to run a copy of Windows in a Virtual Machine (using either VMWare Fusion or Parallels Desktop) on your Mac is to test software and websites. I recently ran into a problem, though, when I wanted to test some PHP-based websites that were running on my Mac under MAMP (stands for Mac Apache, MySQL and PHP).

The problem is this: Even if you have the Windows set up with bridged networking, you will not be able to see the websites running on your Mac if you type in the Mac's IP address. This problem can be solved pretty easily, though, if you simply tell Windows exactly where Internet Explorer needs to look, by editing the 'hosts' file (which tells Windows where to look for specific IP addresses).