This was my presentation for WordCamp Helsinki 2017. It's about the default automatic updater in WordPress and how that can be enhanced using CI instead.
Why it's dangerous to turn off automatic updates and here's how to do it
1. Why it’s dangerous to turn o automatic updates and
here’s how to do it
Presented by Onni Hakala
1 / 27
2. Automatic
Updates in
WordPress
WordPress includes a feature for automatic updates. This
is built-in feature and it's enabled by default.
This delivers crucial security updates, bug fixes and new
features for everyone.
WordPress core developers test all changes carefully
before they are released.
2 / 27
9. Why We
Should
Update
Some statistics from 2016
Out of the 11k+ infected websites we analyzed, 56% of the
total WP infected websites, were still out of date.
This is good, when compared to the percentage of infected
sites with out of date software found in the Joomla! (84%),
Magento (96%), and Drupal (81%) platforms.[1]
[1] sucuri.net/website-security/website-hacked-report
9 / 27
10. But nobody wants to put out res all day
People are still afraid that the updates will break things
10 / 27
11. So how should this be implemented?
Warning: next slides are focused for the technical audience.
11 / 27
12. Create a testing pipeline
This is a process which takes care of deployments
12 / 27
13. Steps to
create
pipeline
1: Store your source code in Git
Create a new Git repository for your project and put all of the
source code including plugins and themes there.
Github, Gitlab and Bitbucket are easy to setup.
13 / 27
14. Steps to
create
pipeline
2: Disable built-in updates
I admit this is scary.
You can do it by adding this line into
wp-config.php:
<?php
// Disable all automatic updates
define( 'AUTOMATIC_UPDATER_DISABLED', true );
14 / 27
16. Steps to
create
pipeline
Composer allows you to track versions of plugins, themes
and core
Here's an example composer.json with WordPress and Jetpack:
{
"require": {
"php": ">=7.0",
"johnpbloch/wordpress": ">=4.5.0",
"wpackagist-plugin/jetpack": ">=4.7.3"
}
}
16 / 27
17. Steps to
create
pipeline
Now you can update all the things with a single command
After this you will have latest versions ready for deployment
to the production
$ composer update
17 / 27
18. Steps to
create
pipeline
4: Stop manually testing your updates
This one is quite hard and you need to build tools which can
detect if the site is not working correctly.
For me this was the hardest step to take and it took long time
to gain enough trust in the systems.
18 / 27
19. Steps to
create
pipeline
5: Implement tests for your site
Pick any tool that feels good for you. You can start small and
build more tests later.
Here are some tools I have found useful:
19 / 27
20. Steps to
create
pipeline
6: Automate testing using CI
Continuous Integration Service (CI) can install and test the
updates 24/7.
Travis CI and Drone CI are my favorites:
20 / 27
21. Steps to
create
pipeline
7: Use Your CI to deploy new code to
production
This depends on your setup.
You could just transfer files with rsync from CI to your
production server and reload the web server.
I prefer using docker containers but that's a whole different
topic and let's not go there today.
21 / 27
22. Steps to
create
pipeline
8: Automatically commit new versions to the
source code
You want to know when updates happened and you want to
store all changes in the Git repository.
The changes in source code will trigger new test builds and
deployments in CI. You just need to make them happen
somehow.
22 / 27
23. Steps to
create
pipeline
This can be achieved using a simple cronjob
This script can be used to download and updates your source
code back to Git.
#!/bin/bash
# Download latest changes from central Git
$ git fetch origin
# Reset all changes to the master
$ git reset origin/master
# Update all components
$ composer update
# Commit changes
$ git commit -am "Updated all dependencies"
# Push them back to git
$ git push github master
23 / 27
24. Steps to
create
pipeline
9: Keep enhancing your tests
Your goal is to have good test coverage. Your site will still be
broken in ways you can't imagine.
Trial & Error is good approach for this.
At the bare minimum you should add tests for all features
which have been broken by updates so that they won't be
failing again.
24 / 27
