Patterns for Local Development Nirvana

Our Journey

At PreviousNext, we've been on a decade-long journey towards local development environment nirvana.

From artisanally-crafted snowflake workstation configurations to consistent prepackaged bundles, it's safe to say we've accumulated a wealth of learnings over the years.

I recently spoke at the annual DrupalSouth conference, describing this journey and what we discovered along the way.

Learnings

The time to 200 metric

The time to 200 metric is a (completely made up for the conference talk) method to measure how long it takes for a developer to go from code checkout to running application.

Our recommendations to improve this metric are:

• Package as much as possible into your base images
• Eliminate manual steps
• Trim excess database data

Container image composition

Early on in our journey, we packed a lot of services and languages into one container image.

As time went on, we found that we were unable to upgrade these services and languages without affecting other projects/teams.

By breaking down monolithic images into separate, discrete components/services, we can now fine-tune our local development environment's configuration without adopting all the changes that would come with a single monolithic image.

For example, we can pick and choose our Nginx, PHP, Node, and MySQL versions on a per-service basis.

Localhost

It’s extremely important to have default values that you can rely on for local Drupal development, one of those is "localhost".

This is an excerpt taken from a blog post I wrote in 2017(!).

While time has passed, the content in this blog hasn't. Check out the pros and cons of using localhost networking for your local development environment.

Configuration (settings.php)

How many times have you had to debug an issue only to find that you have a bespoke settings.php configuration file on your local, which is different from another developer's because you missed a manual step in the README.md.

We solved this issue by moving to a sane, consistent "defaults with a fallback" solution.

For more information, see our Skpr blog post about architecting the Skpr configuration system.

Database images

One big item holding us back from "time to 200 metric" nirvana was due to the time it took to import a database.

Enter MySQL Toolkit (mtk), a toolkit for exporting, sanitizing and packaging MySQL databases.

By exporting, sanitizing, and packaging our databases, we automated these steps and drastically reduced developer spin-up time.

For more information, see our PreviousNext blog post about containerised databases for devs.

Performance testing

Setting up performance testing tooling can take quite a large effort. This includes, for example, setting up subscriptions, configuring tools etc.

Performance testing tooling should be available and ready to use right out of the box, especially when debugging production performance issues on a local environment under duress.

We recently shipped our prepackaged local development images with SPX in an effort to fix this.

Watch the video

Recorded at DrupalSouth 2024 in Sydney, my session is a deep dive into our journey towards local dev environment nirvana.