“Automatic Updates for Drupal” was, is and will be a matter of debate. In this open discussion, we want to welcome everyone who wants to learn more about the current state of update processes within the Drupal Community, and especially about possible future scenarios in Drupal. We welcome everyone who’s interested in joining the discussion about auto update possibilities and bringing in critical reflections.

1. www.drupaleurope.org

2. Drupal + Technology
17/3/2018
TRACK SUPPORTED BY

3. Hernani Borges de Freitas
Technical Architect - Freelancer
@hernanibf
img
Joe Noll
CEO & Co-Founder of Drop Guard
@noljoh

4. Hackers automate but the Drupal Community
still downloads updates on drupal.org
Why we need to talk about Auto Updates
Hernani Borges de Freitag & Joe Noll

5. Today we’ll talk about
- Status Quo - Updating Drupal
- Auto update handling & processing
options

6. The life of a website
Developer’s view
Site Owner’s view
Specification
Design/
Architecture
Development UAT Launch
Maintenance
& Support
Project
Phase
Maintenance
& Support

7. Personas
Deploy & Ignore: Once the site has the needed functionality, there’s
little maintenance or updating. No PSA subscription.
Once a year: Site owner deploys and ignores updates - except once a
year.
Diligent but with Simple Needs: Typically applies updates within a
week, non-security updates will take possibly longer. Follows up on
PSAs by directly updating the live site.
The Sophisticated: Needs to apply at least one build step (for CSS,
Composer,...) Runs QA in a pre-production environment. May deploy to
a multi-head cluster.
* Source: https://www.drupal.org/project/ideas/issues/2940731 * PSA = Public Service Announcements (Security Advisories)

8. Drupal Community Update Behavior
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
* According to Driesnote in Vienna, September 2017

9. Hack Camp Bukarest: Security Focus
“Responsible disclosure, cross-project collaboration, and Drupal 8 security”
by xjm (Jess from the Drupal Security Team) -> Today at 16:00
SA-CORE-2018-004 (CVE-2018-7602): First automated attempts started after 4 hours
CVE-2018-7600: “over 115.000 unpatched websites”
two months after security release
Security Perspective

10. Who do we want be?
Deploy & Ignore
Once a year
Diligent but with Simple Needs
The Sophisticated

11. Recommendation
- Do highly critical updates (security risk 20 to 25)
UNDER 4 hours
- Do all other updates on reasonable time after core
release schedule

12. What’s typically involved in an update?
Build Review Deploy Test
Communicate throughout the process
Composer install /
Composer update
What changed To an non-productive
environment
Automatically/
Manually
To Production
Deploy

13. Multiple environments are available and are up to date.
Automated tests exists and have good coverage.
Security/Non-security updates are detected automatically ASAP.
Developers can review changes before being applied.
A CI Pipeline exists to control all this process.
How much can we automate?
Things get easier when
Automation exists

14. Options
Use a SaaS
Option
Update Drupal
Directly
Automate
Composer
Workflow

15. Automatic Update Initiative
Update Drupal
Directly
● Aim to have core support for automatic upadtes
● Automatic update initiative
○ https://www.drupal.org/project/ideas/issues
/2940731
○ Proposed Roadmap available
○ Two BOFs in DrupalEurope (Today and
tomorrow).
● Low end websites come first in the roadmap
● Composer support later
● Conceptually similar to strategy used in other
CMS but more robust.

16. I have been responsible for maintaining 4 D8 websites over the last 9 months as a hobby
Two in Acquia Cloud
Using github / Acquia pipelines
Drupal.pt and lisbon2018.drupaldays.org
Two in self-hosting
Bitbucket / Bitbucket pipelines / Deployer (https://deployer.org/)
Few minutes per site including build time to have production updated
Personal experience
Automate Composer Workflow

17. Assuming your code is versioned in a Git repository.
Dev branch contains only composer.json and custom code and pipelines steps
Composer artifacts can be tweaked when updating or version constraints might be enough.
A code push against dev branch, starts CI pipeline job which will generate a new full build (using
composer) and make it available to deploy (dev-build branch). This can be done with any CI like travis,
bitbucket pipelines, acquia pipelines, etc..
Build branch is deployed in testing environment
Website is tested in testing environment
Build branch is merged into master which gets deployed to production environment
Update strategy
Automate Composer Workflow

18. Update strategy
CI Pipeline
Dev Branch
Composer.json
Custom code
CI Pipeline file
Build Branch
All code that will be
deployed
CI
Staging
Environment
Deploys
Final
Build Artifact
Production
Environment
Build
Merge to Master or
Create a tag or
…
Push
Tested/Approved
Manual Automatic

19. Automating the last bit - Update runner
Contributed module - http://drupal.org/project/update_runner
Proof of concept module. Targeting an alpha release module soon! Contributions welcome.
Automatize the missing piece - detect updates and fire up push for an update job.
1
Update_runner detects available
updates using Core updater
module. Processor plugins
configured to react to them.
Available processor plugins are used
to push metadata file with the source
repository in dev branch.
Supports: Github/Bitbucket … more
2 3
A push to the dev branch starts the
whole build process described before.
Plugins can be written to act in very
different ways to the available updates.

20. Become a Drupal contributor
Friday from 9am
● First timers workshop
● Mentored contribution
● General contribution