I recently had a chance to present on Drupal 10 for Drupal4Gov. I thought it might be good to cover some of the highlights on the blog however, because there’s some important take aways. This post will cover the material, and if you’re interested in the recording I’ve embedded it and my slides at the end of the post!
What The What? Drupal 10 Already?!
So, let’s get something out of the way. Drupal 8 has been out for nearly six years now (it released in November of 2015). Drupal 9 has a much shorter turn around, but even it’s been out for a year and a half at this point. Drupal 10 is currently slated for release in June of 2022 (so at the time of writing, less than a year away).
Why are we talking about it now if it’s still so far away?
If you drill down into the current Drupal usage statistics, only about 10% of the community is running Drupal 9. If I combine and tally the numbers in the chart to get us a little broader picture, here’s the use for 7.x, 8.x, and 9.x:
Obviously the vast majority of reported installs in the community are still running Drupal 7 but that’s a different story. The much more concerning statistic that roughly 30% are still on Drupal 8 (when it goes end of life in just 2 months). Back to original question, why are we talking about Drupal 10 already? It’s because as a community we are very very behind on our updates and I want to break that cycle.
Breaking the Cycle
The Drupal community has a very steady (and well-defined) release cadence. On average, we do 2-3 releases a month of Drupal core. Sometimes it’s more than that (if there’s a critical security vulnerability) but if you look at the recent months of releases, it’s basically 2 a month (one for bug/features and one for security).
Question: How often do you update and deploy your website (through production)?
I’ve done a reasonable number of security audits and application reviews this year and in all cases the sites I was auditing were more than a month out of date on their updates. More than one was more than a year out of date. Not only does that mean they were exposed to some pretty beefy security vulnerabilities, but it means that the next time they do take time to do an update, it’s a much much bigger jump.
My recommendation is simple (on paper): plan to do a full update / deployment at least once a month. Theoretically, you should know everything involved in doing a deployment at your organization. This might include things like:
regression testing
downtime notification to users
change management review process (internally)
etc.
Whatever the time commitment required for you and your team to do the above, you should plan on doing it at least once a month. Even more ideally, you’d plan on doing it 2-3x a month! But I realize that is a lot and not all organizations can stomach it.
Consider these numbers:
if you had updated once per quarter over the last quarter, you would have 6 (or more) releases of Drupal 8/9 to deploy to your platform
if you had updated three times (monthly) over the last quarter, each would have only have been 2 releases
While you are doing more work as a team to release monthly, the level of effort to do each of those releases should be significantly smaller (and therefore easier). Believe it or not, the more often you update the easier it is to update!
Internal Alignment
Many of the organizations I’ve worked with over the years struggle not with the technical difficulty of keeping a site / platform up to date, but the political cost. If the development team is doing spending whatever amount of time every month doing a Drupal update and deployment, that is X amount of time they are doing whatever other support, bug fixes, content creation, feature development, training, etc. that the powers that be might expect them to be doing.
Combine this with the fact that many organizations downsize their partner support and/or development team funding once their sites go live, and you have a perfect storm. Granted, having a bunch of devs sitting around looking for things to do is also not good but building in enough air cover to ensure that the dev team can keep up with regular maintenance is critical.
Prioritize the updates. Right size your development team to keep up with the needs of your organization AND the ongoing maintenance. Not easy things, not technical problems to solve, but problems all the same that absolutely must be isolated and resolved.
Issuing a Challenge
Thinking about all these pieces, I have a final thought (and a challenge) for you: make a plan to upgrade to Drupal 10 early. Aim for a trial upgrade sometime in June of 2022. If you want to be really ambitious, aim to test out the alpha/beta versions in April/May of 2022! While you might not be able to actually push all the way to production, it’s worth the experience of trying the update. You’ll likely find incompatible modules, deprecated code, and more. But the earlier you start trying the clearer your path will be. And you never know, maybe you’ll have an unrestricted path and you can just wrap it up.
I hope you’ll take me up on this challenge… the community needs more people updating more quickly. The numbers we are seeing should be completely backwards. Not just a few people on Drupal 9 at this point in the D8 ecosystem, but the vast majority of people running D8/D9 should all be on D9!
If this challenge is giving you pause, or if you have concerns, then great! This post / this webinar are 100% targeted at you and organization. You have plenty of time (almost a year) to think about the blockers and start jumping on them. Obviously, with D8 going EOL in just a few weeks you should really do that ASAP anyways. But once you get onto D9… start planning ahead. Aim for D10 in June. Make the jump early, and then just keep jumping. It’s totally worth the effort.
Related Content
An overview of all the things I’ve been trying / testing to get ready for PHP 8.1.