drupal vm

Update 2017-02-14: BLT now includes a much simpler method of upgrading the VM (provided you only override VM settings in files separate from the box/config.yml file):

# Delete the entire VM and remove config.
blt vm:nuke

# Rebuild the VM with the latest recommended version and config.
blt vm

Limiting the amount of surprises you get when developing a large-scale Drupal project is always a good thing. And to that end, Acquia's BLT (Build and Launch Tools) wisely chooses to leave Drupal VM alone when updating BLT itself. Updates to Drupal VM can and should be done independently of install profile and development and deployment tooling.

Seven months after Drupal VM 3 introduced PHP 7.0 and Ubuntu 16.04 as the default, as well as more stable team-based development environment tooling, Drupal VM 4 is here!

Thanks especially to the efforts of Oskar Schöldström and Thom Toogood, who helped push through some of the more tricky fixes for this release!

The PostgreSQL logo. Same family as PHP's mascot!

For the past few years, I've been intending to kick the tires of PostgreSQL, an open source RDBMS (Relational DataBase Management System) that's often used in place of MySQL, MariaDB, Oracle, MS SQL, or other SQL-compliant servers. Drupal 7 worked with PostgreSQL, but official support was a bit lacking. For Drupal 8, daily automated test builds are finally being run on MySQL, SQLite, and PostgreSQL, so many of the more annoying bugs that caused non-MySQL database engines to fail have finally been fixed!

It's helpful to be able to enforce a minimum required Ansible version in Ansible playbooks. Ansible Roles have long been able to specify a minimum Ansible version—but only for Ansible Galaxy and ansible-galaxy-related dependency management.

I've found more and more that users who installed Ansible further in the past (in the 1.7.x or 1.8.x era) are now using some of my newer projects that require Ansible 2.0 (there are so many nice new shiny things!), and they're running into errors like:

The problem, as it turns out, is that these users are running a version < 2.0, but it's not very obvious based on that error message!

I'm excited to announce that I'll be speaking at AnsibleFest San Francisco 2016, on July 28th, giving a session titled Ansible Roles - for Fun and Profit!

Image from AnsibleFest London, earlier in the year.

AnsibleFest is the major bi-annual Ansible conference, full of case studies, sessions and announcements. I'm excited to finally be able to attend, as I've been an avid user of Ansible since 2013, even to the point of writing one of the most popular introductory books on Ansible, Ansible for DevOps.

2016-10-04 Update: Microsoft finally allows long paths, provided you are running the latest version of Windows 10; you have to opt-in by editing a group policy for now—maybe by 2050 or so this will be the default, once all the old legacy Windows apps are finally dead!

For some reason, Windows doesn't play well with deep folder hierarchies. Often, when building Drupal projects inside VMs with synced directories, I end up with folders with 10+ levels of hierarchy, and when I try to delete the directory within windows, I get the error "Source path too long" (or "File path too long"). This happens a lot with npm, composer, or other package/dependency managers, and I'm amazed there's no easy workaround... but I figured I'd document what I do here, because I've had to look up the process too many times.

1 - Download robocopy

First, download and install the Windows Server 2003 Resource Kit Tools, which includes a CLI utility, robocopy.

Drupal VM is one of the most flexible and powerful local development environments for Drupal, but one the main goals of the project is to build a fully-functional Drupal 8 site quickly and easily without doing much setup work. The ideal would be to install Vagrant, clone or download the project, then run vagrant up. A few minutes later, you'd have a Drupal 8 site ready for hacking on!

In the past, you always had to do a couple extra steps in between, configuring a drupal.make.yml file and a config.yml file. Recently, thanks in huge part to Oskar Schöldström's herculean efforts, we achieved that ideal by switching from defaulting to a Drush make-based workflow to a Composer-based workflow (this will come in the 3.1.0 release, very soon!). But it wasn't without trial and tribulation!

Drupal VM 3.0.0 "The Light Sailer" was just released, and you can grab it from the Drupal VM website now. We spent a lot of time during DrupalCon New Orleans sprinting on Drupal VM, fixing bugs, and updating ALL THE THINGS to make sure this release solves a lot of pain points for individuals and teams who need a great local development environment.

Let's get right into why this is the best release of Drupal VM EVER!

The fastest and most modern environment

Drupal VM now defaults to Ubuntu 16.04 (which was just released in late April), running MySQL 5.7 and PHP 7. This means you're getting the fastest, most reliable, and most modern development environment for your Drupal 8 projects.

As Drupal VM has passed 500 stars on GitHub, and is becoming a fairly mature environment for local development environment—especially for teams of Drupal developers who want to maintain consistency and flexibility when developing many sites, I've been working to get more stable releases, better documentation, and a more focused feature set.

Also, in the past few months, as interest has surged, I've even had the opportunity to talk about all things Drupal VM on the DrupalEasy podcast! Check out DrupalEasy Podcast 172 - The Coup (Jeff Geerling - Drupal VM), which was just posted a few days ago.

And to keep the conversation flowing, I'm going to be moderating a BoF on Drupal VM at DrupalCon New Orleans, Drupal VM and local Drupal development for teams.

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.