Drupal recents security updates resulted in many hours of work for different professionals involved in maintenance of Drupal websites from developers to operations teams.
New Drupal 8 release cycle is also requiring organisations to spend more time guaranteeing that their websites are following last minor core release so their sites are updated and ready to receive new features and security updates.
Nevertheless, even with the increasing required effort, we still don’t have an easy way to support automatic updates in Drupal core but options start to appear.
In this session I will talk about different possible alternatives that can minimize the effort to automatically update Drupal while still maintaining best practices in all the required phases.
5. Who am I
• ~ 10 years of Drupal
• Technical Architect - Freelancer
• Hernani.pt – twitter.com/hernanibf
• DDD Organization
6. The life of a website
Specification Design/Architec
ture
Development Go-LiveUAT Maintenance /
Support
(Through the eyes of someone delivering it)
~ MonthsSometimes it looks like years….
7. The life of a website
Project
Phase
Maintenance /
Support
(Through the eyes of someone who actually pays for it)
~ Months ~ Years
8. Problem
• We cannot leave websites on autopilot
• Updates require time and resources
• Developers
• Different environments
• Testing
• Deployment processes working
• Low effort put on web site maintenance processes
9.
10. Challenges
• Things can break when updating
• Drupal is used/installed in many configuration scenarios by totally different types of users
• One environment/many environments, one server / multiple web nodes, cheap hosting..
• Source code should be reviewed before deployments
• Security concerns
• Software should not overwrite itself automatically
• A central updater can introduce vulnerabilities (https://www.wordfence.com/blog/2016/11/hacking-27-
web-via-wordpress-auto-update/)
11. Drupal 8
Our brave new world:
• More dependencies, more components change over releases. Larger attack
vector regarding security.
• Core is evolving faster so there is a need for more frequent larger updates.
• Staying behind new releases means it is harder to update (there are more
updates / steps to go through).
12. Personas
• 1- Deploy and Ignore: Once the site has the functionality needed, there's little maintenance or updating.
Doesn't subscribe to PSAs.
• 2 - Site owner who care once a year: Deploy and ignore w/ an exception once a year
• 3 - Diligent but with Simple Needs: Typically applies updates within a week of release, possibly longer
for non-security updates. Follows up on PSAs by directly updating the live site.
• 4 - The Sophisticate: Needs to apply at least one build step (for CSS, Composer, etc.). Runs QA in a
pre-production environment. May deploy to a multi-head cluster.
Source: https://www.drupal.org/project/ideas/issues/2940731
15. Or maybe not.
According to Driesnote in Vienna, September 2017
• 59% of all Drupal users update by downloading modules from drupal.org
• 24% of all Drupal 8 users update using drush
• 22% of all Drupal 8 users update using composer
16. Options
• Require smaller number of updates and smaller updates
• Make update process easier
• Not breaking functionality
• Not evolving human effort
• Integrated with normal development/deployment workflow
• Automatic Updates !
17. What’s typically involved in an
update?
• Build (Composer install / Composer update)
• Review the changes on the build
• Deploy to an environment
• Test (Ideally automatically)
• Deploy to production
• Communicate all the way through.. !
Or maybe not…
18. Things get easier when...
•A CI Pipeline exists
•Multiple environments are available and are up to date
•Automated tests exists and have good coverage
•Security updates are detected ASAP
•Developers can review changes before being applied
19. My personal experience
• I have been responsible for maintaining 4 D8 websites over the last 6 months as a hobby
• Two in Acquia Cloud
• Using github / Acquia pipelines
• Drupal.pt and lisbon2018.drupaldays.org (https://github.com/drupalportugal/drupal-dev-days-2018)
• Two in self-hosting
• Bitbucket / Bitbucket pipelines / Deployer (https://deployer.org/)
• Few minutes per site including build time to have production updated
20. Simple update process
• Assuming your code is versioned in a Git repository
• Change composer if required
• Run composer install/update
• Commit build artifact. Deploy to a testing environment.
• Test
• Merge the testing branch to master
• Deploy to live
21. Update strategy
Dev Branch
Composer.json
Custom code
CI Pipeline file
Build Branch
All code that will
be deployed
Commit
CI
Build
Staging
Environment
Deploys
Tested/Approved
Final
Build
Artifact
Production
Environment
Merge to Master or
Create a tag or
…
23. Other options to solve the same
problem?
• How does Wordpress update core?
• Supports automatic updates since October 2013
• Runs on cron using api.wordpress.org
• Core/Plugins/Themes/Translations supported
• By default minor releases and translation files
• Webserver writes new PHP files
24. Similar option in Drupal?
• Overwrite code similar to what WP does
• Not great for many organizations
• Security implications
• Many hosting providers don’t support it
Would still cover a large percentage of Drupal websites and mostly the simpler ones which owners don’t
care too much.
If not using composer, easily done with the likes of a cronjob:
$ drush upc --security-only --y
25. Automatic Updates initiative
• Announced in Vienna by Dries
• Use cases and roadmap being discussed
• Several options on the table
• Evolved
• Improve Drupal Core's relationship with Composer
• The A/B vendor directory and bootloader concept
• Code signing and ensuring integrity
https://www.drupal.org/project/ideas/issues/2940731
