Operations Lead
Patterns for Local Development Nirvana
Come with us on a journey to local development environment nirvana. Along the way, you'll gather a list of actionable learnings to improve the dev experience.
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.
Related Articles
Case study: Building a Cloud Native Platform
VIDEO: Come on a journey with us into the past. Discover the lessons we’ve learned along the way as the Skpr hosting platform has grown and evolved.
An Introduction to Load Testing with k6
Why is load testing important, and how can you use the k6 tool to perform improved load testing?
Getting Started with Skpr
Skpr provides a compelling command line workflow for developers.
In this blog post we will be demonstrating Skpr by going through the fundamental commands: package, deploy and config.