opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

daily-email: add 2023-08-01

Browse source 
Maintaining a module used on 35,000 Drupal websites
This commit is contained in:
Oliver Davies 2023-08-01 23:06:19 +01:00
parent 0b83c2454e
commit 74c3ca1c40
1 changed files with 40 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
src/content/daily-email/2023-08-01.md Normal file
View file

@ -0,0 +1,40 @@
---
title: >
Maintaining a module used on 35,000 Drupal websites
pubDate: 2023-08-01
permalink: >
archive/2023/08/01/maintaining-a-module-used-on-35000-drupal-websites
tags:
- drupal
- open-source
---
Note: The numbers within this post are taken from my [Test-Driven Drupal talk](https://www.oliverdavies.uk/talks/tdd-test-driven-drupal), in which I also talk about this.
My first commit to the 7.x-1.x branch of the Override Node Options module was in March 2012. According to Drupal.org, the module was used on 9,212 websites then.
As well as the 7.x-1.x branch, there's the 8.x-2.x branch which supports Drupal 9 and 10, and previously Drupal 8.
The most recent statistics show the module is currently used on 34,981 websites and is consistently around 35,000.
## What does that mean?
The module is considered feature complete, but I'm not ruling out any new additions.
The main thing is ensuring that any changes don't break 35,000 websites!
I do this by relying on the module's automated test suite and ensuring that tests are added for any features or bugs and that the tests are passing before any new release.
## This has worked well
A few years ago, I committed a feature request to both versions. While it didn't include additional tests, I verified the existing functionality worked after resolving a large merge conflict by ensuring the original tests passed.
More recently, a colleague and I refactored the module and split each override into its own class, making adding and maintaining overrides easier.
Because the tests were still passing, we knew our refactor was successful and not causing regressions.
## Here's the thing
Having automated tests and ensuring they're always passing has allowed me to add features and refactor code that I wouldn't have done or had the confidence to do otherwise.
It's great to have a popular module, but on the other hand, I don't want to break 35,000 websites which makes the tests invaluable.