Last week Drupalcon North America was held in Seattle, where Dries opened the conference with the traditional "Driesnote". In the presentation, Dries talked about automated updates for Drupal, a thing I am very passionate about myself. He then went on to say:
I hope that in Drupalcon Amsterdam...in six months… I will be able to stand on stage and actually give some sort of demo. That would be my goal. So obviously… I would need your help with that… but that would be fantastic.
This triggered a thought: with the tools we have today, and as composer support is fairly decent, we can actually demo this somewhat utopic goal now. Which is why I made a video of just that. So without further ado: here is the demo!
Automatic updates and the future
This demo demonstrates tools that are available now. Instead of only focusing on those tools (and promoting violinist.io), I want to expand on the subject of automated updates in Drupal, and its future.
Like for Dries, automatic updates is an important issue to me. Not only because I promote running automated composer updates with violinist.io, but because having these features will make Drupal more viable for hobbyists and beginners. Which in turn is something that can help us reach more users, and increase our diversity. Consequently, having automated updates is important for the “non-professional” group of Drupal users.
In the presentation, Dries also points out some important positive effects of having automated updates. First, it will help securing your site (or your client's site) when time-critical security updates are released. Second, it will make it easier for organizations and agencies to maintain websites. This means that having automated updates is important for the “professional” group of Drupal users as well.
This brings us to the next segment, which mostly applies to agencies and organizations using Drupal professionally. Two issues are often raised about having automated updates. First, that moving and/or overwriting the files of your codebase is a security risk. Second, that updating files on your live server can be a no-go. Maybe you have a version control system in place. Or perhaps you have a continuous integration/deployment pipeline. Or, you have setups that deploy their codebase to multiple front-servers. The two issues are valid concerns, but usually they are less of a concern to "non-professional" users. This implies that having automated updates is important for the “professional” AND “non-professional”, but the preferred implementation for these two groups might conflict.
In my personal opinion, we can support both. Let me explain how.
My suggestion is that we can have a system in place that is pluggable in all parts. This means that the "non-professional" can use plugins that are useful for updating via the file system, and hopefully set-and-forget the automatic updates for their site. It also means that the "professional", the one with the pipeline and version control, could have entirely different plugins for updates. To get back to the video above, a pre-flight check (which is how we determine if we can update) can mean checking for pull requests for the available update, and checking that the tests pass. The plugin for updating could simply merge the pull request, since automated deploys are run for the master branch. Now, different teams have different requirements, but this means that you could use a Pantheon or Platform.sh plugin for automated updates. Or, maybe you have a custom plugin for your team that you use across projects.
I believe this feature can help automation for "professional" teams of all sizes, and make the very same system usable for "non-professionals" that want to set-and-forget. This is also why I believe having automated updates in core, is in no way in conflict with doing automated updates like in the video above. It will only complement the toolbox we currently have!
If you want to read more about the Automatic Updates initiative, there is more info here. It is an exciting future, and we can all help out in making the future more user-friendly and secure. I know I will!
Do you want to comment?
This article uses github for commenting. To comment, you can visit https://github.com/eiriksm/eiriksm.dev-comments/issues/13.