 Oh, hey everyone. My name is Onni. I'm working as DevOps engineer in Wunder Finland in this company, which has the carrot logo over here. Surprise, surprise, we are also hiring. Today we are talking about automatic updates and the downsides of disabling them and how in ideal world would you update your WordPress sites? Okay, let's start. So here we have some information about what we have currently. So automatic updates are included in WordPress core. They are enabled by default and they will bring new security updates and new features. Basically everything good, so you should not disable that. They are great, like perfect, like really, really good thing. Everyone just talks that that's like the main, one main reason why WordPress is secure, but I'm asking you to disable it. In order to safely implement upgrades, you should disable the default updating system. And there's, of course, this is a clickbait title for this talk. We will actually concentrate on building pipelines for WordPress. So why would anyone want to disable updates? Have you ever heard of WordPress site, which was broken by automatic updates? Anyone? Yeah, me neither. That's false news. But realistically, now it's easier to understand. People are afraid that their sites really get broken and they don't want to wake up in the Sunday morning just to fix their WordPress site. But let's take a step back now and see some statistics from Suguri. Suguri is a security company focused on CMSs like WordPress. And they say that from 2016, 11,000 infected websites they analyzed, 56% of them were infected and 56% of them were still out of date. So if you don't update, you will usually get hacked. And the best part is that they said, this is good when compared to the percentage of infected sites with the out-of-date software found in the YUMLA, Magendo, or Drupal. But really, 56% is a lot. So we should try to update our sites immediately when possible. Okay? And really, but no one wants to wake up in the middle of the night or have this client calling really angrily. Okay, my site is down. It's just blank screen. Please do something. So what should we do instead of just disabling them? And I have this warning that the next slides are focused for the technical audience. So bear with me the ones who don't know your way in command line. You should create a testing pipeline. And this is actually really old news for anything other than WordPress. Everyone is doing that. Everyone. They have tests. They have build pipelines, and they will just deploy if the test will pass. So this is something that I would want to bring for the WordPress community. The steps to create a pipeline. First, you should store all of your source code in Git. Probably you want to use something of these three names over here. GitHub, GitLab, or BitBugget. Because they are easy to use. They are cheap. And basically, everyone is using them. You can't go wrong with those. And I have no affiliation, you know, any of those, except GitHub provides me this student discount of five euros per month. The next step is to disable the building updates. Because you don't want your site to automatically update when it's in production. You would want to do the testing and the update process elsewhere. So just disable them. And then use Composer for managing all of the versions of your plugins, themes, core, and other libraries that you have. I think many of you already do. And with Composer, you will have this small JSON file, which will tell all of the used packages and components that your site uses. And you can set limits that, okay, I want to use only 4.5.0, or you can use that, okay, like, it can be the same or greater than, which is basically what you usually want to do, because you want to update everything with the Composer. And now you can just use this one-liner to update all of your plugins and your core and your teams, everything. It's really easy. And this step, this was the hardest part for me, to not really manually still test everything, okay, like, is it working? Okay, I can push it to production. And the same thing all over again, there was this one point where I forgot to update one site and it actually got hacked. So please, if you disable the updates, please continue with the rest of these steps because this is really bad practice if you don't update your site. The step number five is implementing tests. And here, you can really keep this simple. You don't have to apply all of these random tools that I'm saying over here, but you should do some tests. For example, if my front page is just white blank screen of debt, please don't deploy this to production. And to really have these easy steps which will at least help you not to deploy broken code, which is easily tested, okay, does my login work? Does my front page work? You can actually implement any kind of tests, like, is this accessible enough in some metrics or does the page load fast enough? And I only want to deploy it to production if everything works. And the next step is using a CI. I think Travis is many of you might be familiar with Travis. You can also use Jenkins or drone. CI drone is the robot logo over there. I didn't find any logo with the text on it. And Travis is actually free to use for open source project. But usually, your client work is not open sourced. So the price for a closed source is quite expensive, but still not that much. With these tools, you can automatically run your tests and your compulsory install, all of the steps included in external service. Like, many people, all of the people have testing machines, but some people are clever enough that they also have external production machine that you don't actually test in your production. So using CI can help you with that. Okay? And also use your CI, give your CI access to your production or your staging servers that it can deploy the newest code into production when the tests will pass. And if the tests won't pass, just implement something like a slack hook that it will tell your team that, okay, this site, the tests are failing. Can you please check this up in local development? And you can really keep it simple. For example, just use scp or arsenic and copy your files into production. But you can go in like different levels and have your own like docker set up or something else as well. And basically those last steps were about traditional CI. Whenever there's a change in your Git repository, those changes will trigger new builds. And if the tests will pass, they will go to production or they will build some binaries or anything that your end result might be looking like. But the last one is because we are using Composer for all of the packages. We want to trigger new Composer versions into our version control so we can know that, okay, my site was updated last Wednesday or few hours ago. And you can keep track that, okay, like when this was actually updated. And this one, there is nothing like really clean for this step. But I'm proposing just to use a simple cron job which will fetch your newest source card and will update all of the Composer components and then just push it back into that, for example, GitHub in this example. So now you would have a cron job which triggers every 15 minutes and we'll just update all of the packages. And if the test will pass, it will go to production. Of course, we don't live in ideal world. Your site will still get broken from time to time. And in that, if that happens, you should just implement more tests, okay? For example, my order page was broken that you couldn't click on this button over there because of this WordPress update. You should just create a test that, okay, is my order button working after the tests. And now you don't go into this regression and have the same failures again, again, again. And I think at the bare minimum, you would just need to have some check that is my front page working. If it's working, please deploy the production. That's enough. And the summary, we have a cron job that triggers new changes to the kit. Then the code is built by Composer and tested by your testing framework in the CI. And then the CI deploys the new versions to production. And yay, automatically you will have new versions which are tested in external location than your production servers. Okay, so what we did was to replace the default automatic updates with better process. Thanks for listening.