5 Critical Strategies For Teams Using Virtual Environments

I have several upcoming guides for getting started with DrupalVM, DDev, Docksal, and Lando. But before I publish any of those, I wanted to take some time to talk through 5 critical strategies for team’s using virtual environments.

Why are these things so important?

I find myself working on VMs daily. But not necessarily the same project’s VM, and not even the same VM technology (I may be working with DrupalVM in the morning and Lando in the afternoon). On the one hand, this is great! A decade ago I would have really struggled with this, now I just suspend one and boot the other. No big deal. On the other, even though the technology makes it pretty seamless, there’s still a lot that can get “messed up” if you don’t do it right. So this post is all about how to manage multiple virtual environments within a team and make sure you don’t make a mess of it.

On to the list!

1. Match the Cloud

One of the main points I’ve made in recent posts about configuration management is that you want your development processes to telegraph production issues. Virtualization is much the same. All of your cloud environments, your continuous integration, and your local environment should all be running the same technologies (e.g. Apache vs. Nginx, IIS vs. Ubuntu, etc.). It’s critical when you are considering a VM for local development that you align with your web host as much as possible.

Your hosting provider should have some sort of documentation on what they’re running. For example, here’s Acquia’s.

Some key things to watch for:

• OS Version

• PHP Version

• MySQL Version

• Webserver

2. Commit the Config

There are two tasks associated with setting up a VM. There’s the initial configuration / provisioning process (that only one person really should have to do) and then there’s provisioning it to use it (once it’s been configured, which the rest of the team will have to do).

I strongly recommend having one person on the team (often the architect / lead developer) handle the VM configuration and then commit that configuration. That way, anyone who pulls the project code will have the VM config ready to go.

Most of the projects I’ve worked on require exactly 4 steps to get started as a developer:

1. git clone (to pull the code)

2. composer install (to install the dependencies)

3. <hand waves> VM provisioning (this could be lando start, vagrant up, etc.)

4. install drupal

This level of simplicity is only achieved because someone took the time to configure the vm AND commit that configuration so that everyone is using the exact same config.

3. Standardize Standardize Standardize

Which brings me to this point: everyone on the team should be running identical VM configuration. Again, we want to make sure that if I’m having an issue locally you should be able to see and reproduce that issue locally. Variation between the VMs is a real challenge to overcome.

For instance, I have a fatal error on a site locally. You do not. Is my issue because of code? Is it because my version of PHP is different than yours? We don’t want that second option to even play into the equation. By standardizing the config of the VM we drastically reduce the changes of something like PHP version biting us.

Note: I highly recommend that your team also try to standardize around host machines as well. We see significant challenge / overhead on projects where “most” of the team is on a Mac, but person is running Linux or Windows. This creates isolation, as this one person will not benefit from the rest of the team’s shared experiences. They may have issues that the rest of the team do not have.

In my experience, a Mac (with at least 16gb of memory) is the best bet. Windows can certainly be used for development, but it’s more challenging has much stricter requirements on what you need to do to get up and running (e.g. Professional version of OS, etc.).

4. Work Inside the Container

Once you have your fancy VM up and running, make sure you use it! Whenever / wherever possible, make sure you’re running commands inside the container.

Here’s a common issue: Composer and PHP version. Maybe your Macbook has PHP version 7.2 on it. But the project (and the VM) are developing using PHP 7.3. If you are running Composer commands from your host machine, composer is going to think that the project is using PHP 7.2. If you are running composer commands inside the VM, then Composer will think you’re using PHP 7.3.

TLDR run all the commands inside the VM to make sure this isn’t an issue!

5. Dedicated Maintenance

Finally, remember that VMs just like any other “computer” require some regular maintenance. Maybe you’ll have a PHP version update occurring during your project. Maybe you’ll start using a new technology (e.g. NPM) halfway during the project and you need to add a new dependency into the VM.

My recommendation here is to have one person on the team that is knowledgeable about the VM technology and configuration and have that person largely own the maintenance and development of the VM. This is hardly a full time job (so you don’t need this person to only do VM maintenance). Usually it’s a couple of hours at the beginning of a project, and then an hour here and there throughout. But limiting who does this should cut down on the number of people who “need to understand” all the things about the VM. And it will also (hopefully) cut down on confusion and problems.

Reminder: anytime the VM config changes, you have to re-provision the VM and so does everyone else on the team! Try to time VM updates so that the whole team doesn’t lose half an hour (or more) of productivity right at a critical time in a sprint.

In Conclusion

So that’s it! If you do these 5 things, you’ll be in a much more stable and consistent place as you work with virtual environments. Keep an eye out over the coming weeks for my guides to getting started with some of the common Drupal community environments (such as DrupalVM, DDev, Docksal, , and Lando).

Photo by Bruce Mars from StockSnap

Related Content