 So, yeah, I know how annoying it is for the audience to rock up for a session, and, you know, we're, what, seven minutes in, and I'm still stuffing around with the AV, but it looked like it was working our way. I thought it was only people on Linux, desktops presenting you had issues with AV. Yeah, yeah. So, yeah, well, I could just jump to the end to the rate my session, and you can all just rate the session and we can be done with it. Well, even though this is truncated, you can see the key piece of this slide. So I can, I can do this bit of the presentation while we wait. So I'm Dave Hall. I'm a Drupal developer who's been stuffing around with Drupal since the days of 4.6. I also do a Fabative Sys Admin work, and so, and I've been trying to automate myself out of a job for about a decade, but I haven't been successful at that. I could go on more about myself, but, you know, you're here to learn about automation rather than about me. And if the AV was working, I would start to show you that. But I've also got a couple of legal disclaimers, and I know how much people love presentations where the presenter just reads off the slides. So, so that's what I've got to do for the next couple of slides. So this presentation allegedly contains material, which the Jim Henson company, Disney, Disney, anyone here from Disney? Oh, good. Sesame Workshop and others may be able to claim copyright over. These small pieces of allegedly copied material are used in this non-commercial educational presentation for the purpose of review and or comic relief. This is protected by fair use and or fair dealing provisions under Irish, European and or US copyright law. Before issuing a DMCA takedown notice or other claim of copyright infringement, please search for the Streisand effect. And now this is the one that my clients need me to keep in here. The material used in this presentation may or may not include software services and or methodologies used by my clients, even if my clients are using such things at this very second, they may not continue to do so into the future. My and or their use of anything shown in this presentation should not be considered an endorsement. My clients, family and dog disowned my views, opinions or words expressed by me or any other participant in this presentation. If you attempt to implement anything shown during this presentation, you're on your own. Don't try to sue me. I'm a man of straw. So today I'm going to be talking about Ev Ops. It's this great new thing that is sweeping the world. It's like a new iteration on DevOps. Like it's way more efficient. If you're doing DevOps, you're so 2015. So that there's a few things that I need to talk about because this is a DevOps presentation. No, that's not Dick Olson. He's not here this week. That's chef and puppet. So we got that one out the way. We've got Google, like Google has a one big repo. They have all this automation in place. It's fantastic. Etsy have their code as craft. You know, they have some really good stuff. Netflix, they've got the chaos monkey. They can just, you know, shut down bits of their infrastructure and see if stuff keeps on running. Facebook does all kinds of crazy stuff. They even wrote their own. Well, they've written multiple PHP compilers. Maybe it'll be a case third time lucky for them, though. Airbnb, another startup. They must be doing some great DevOps stuff and GitHub. GitHub does a whole bunch of DevOps stuff and they support a whole bunch of DevOps things. Now, GitHub is the only company in that quick run through. I did that I'm going to mention again during my presentation today. There's a lot of people who they look at Google. They look at Etsy. They look at Netflix and they're like, oh, wow, that's so cool. But the company I work for is like five people or something. How are we ever going to implement something like chaos monkey? And so my presentation today is to try to give you some ideas about how to start small with automation. And I'll start to talk about how I automate. So computers don't make it stakes. The AV do, so. Or as I prefer to say, computers don't make it stakes, developers do. So like there's always issues with developers making mistakes. Like as great as we all think we are, we're pretty flawed. Steve McConnell, who wrote code complete, estimates that developers make dash to 50 defects. Er, yeah, minus 50 defects are 100 lines of code. And he's actually changed his name. He's V. McConnell now. He's got into this evop sufficiency thing as well. So so, you know, here's one of our developers at work. Now, a lot of small companies, they they have beaker writing code. And then it's also beaker's job to do deployments and stuff like that. I don't think that that's the best idea. Like, I actually think that this is a better approach. IBM machines can do the work so that people have time to think. Machines should do the work. That's what their best at. People should do the thinking. That's what their best at. Machines should work. People should think. Machines should work. People should think. Machines should work. People should think. Machines should work any more. I'm too busy thinking. So. So now you know where the title for my talk came from. This is an IBM promotional video from the 1960s for their word processing systems. It was actually made by Henson Associates, which went on to become the Jim Henson Company. So there's lots of Henson references in my presentation today. If you're not into the Muppets in Sesame Street, the door's over there. So let's think about about what what we can do in terms of automation and like, well, we'll pick something small to start off with. We're going to have a recon a recommit who formerly known as a pre-commit hook. So all of us, I think, have worked with developers who have let's say not written the highest quality code that is possible. So I tend to think of them as like the Oscar developers. All of my own, I love them because they're trash. And Oscar developers puts all that trash into their code and it's badly formatted and everything else. So by having a simple recommit who we can we can be checking our code before it actually gets committed, because once code is being committed, it's harder to fix. And the higher up the the further it goes through the delivery pipeline, the harder it is to actually get rid of it, because we all know as soon as the business person sees it and it's working, it's like, great, that's going into production. So if we can deal with issues early, that's a lot better. So yeah, I'm going to give up on trying to talk through this code sample because there's a few compiler issues with the the current environment it's running in. But basically, we'll do a link check, PHP link check to make sure that the code will actually compile because one of the things I see quite often with developers who are less experienced with Git is that they get a merge conflict in a file. They go through, they find the first merge conflict, they fix that one up and then commit the code and there's like six others in the file. And then like, you know, the environment's blowing up and they only merge right before they're about to push. So they fix that one, they push the code and you're stuck with the mess. So that stops that part of it. And then we also so if it fails the link check, you can't kind of see because it's kind of here that it will actually bail out. If that part passes, then we run PHP code sniffer with the Drupal coding standards. Just so we've got consistently formatted code. Now, this is where stuff gets interesting. Oh, it's not going to truncate too much of the video. So fingers crossed, we'll actually be able to see how this pre-commit hook works. So we can see here that we've got the pre-commit hook in our Git hooks pre-commit and it's set to be, well, you can't say that's set to be executable. And we can see here that the code matches what I showed you before, roughly. And we've got a single commit in our repo at the moment. Now, this is the form API example from the examples repo on d.o. And so I've added my changes. And now I'm going to try to commit them. You know, code from Drupal.org, it should pass, but it doesn't. So here we've got a whole bunch of problems that PHP code sniffer has found with this code. So how do we fix that? There's a great tool called HCBF. We've just renamed it today. It was formerly known as PHPCBF. And now you probably PHPCBF is great for lazy developers. It's for people who can't be, well, actually, no, this G programming. So it's it's Ip de art of a matter. It actually stands for PHP code, beautifier and formatter, which I would love something to beautify and format my slides properly. If anyone's got any suggestions, let me know. So what we do, we can run PHPCBF to clean up most of the errors in this code so you're not having developers sitting there reformatting code all the time, like, you know, you'd think if they can figure the RDE properly, this wouldn't be an issue, but you'd be surprised. So now we'll we'll run this. So we run PHPCBF. We tell it the standard that we're going to use with the Drupal coding standards. I made sure in my demo videos that there was a few typos. So it's just like a real life demo. Now we've run PHP code sniffer. We've still got a couple of errors that we need to fix up manually. But rather than having the 30 or 40 errors we had before, we've got to that a human actually has to read the text and clean up. So, you know, wouldn't be a real demo without a bit of live coding here. So we'll we'll do some coding, just double check the file name to get it right. And, yeah, you know, live coding demo with truncated codes even better than, yeah, it's awesome. I think we should have a whole track for it in Baltimore. Hope DA is watching the video so they can make a note of that suggestion. So now we will fix up this stock block, save that. Well, we'll check that file. Now I've still got one more that we'll fix up. Which will just take us a second. Of course, we've got to look up what the file name is. Get that. We fix it up. It's quite a quick fix this one. Oh, yeah, that's right. This is where I just hacked it to get it to pass the tests. I think we've all done that from time to time. So we'll we'll just hack in a comment here. I had to think about what to put in here. So there we go. Check that test thrown. There we go. Put that in. We've got the single line comment. Everyone's happy. So now we can run the code sniffer on this one to confirm that it's good. And now we'll we'll push those will be able to commit those changes. So rather than so at the cleaned up files, so here we cleaned up two for six files and we only had to manually update a couple of lines. So super exciting. Someone doing a commit on a projector. All right, so now we've actually got that that code was able to be committed and we didn't end up with garbage in our repository again. So the next automation I'm going to show you is Artabase Annotization. So also known as database sanitization. There's some people who work with Drupal in highly regulated industries like financial services, pharmaceuticals, like there's a bunch of them. And also in Europe, you've got all the privacy regulations where you've got people's data being captured in your Drupal site. You don't want to be just giving that wholesale to your developers. Start going, oh, this person inquired about this thing or someone bought some product. So what we like to do is we have a hat bot which we need to go back. So we have a chat bot that fires a web hook that calls our task runner. The task runner copies the database to a dedicated environment, runs Drush SQL sanitize on it to scrub the database and you can implement your own Drush sanitize hooks to drop data or put random data in the database, truncate tables, whatever you want. That's just SQL commands. And then we're going to copy the sanitize database dump into an S3 bucket and then send the link back to Slack. So we actually can download the sanitize database dump. So here we go. Well, we'll run our command. So slash DB, we'll give it the name of the the site that we want and the environment. And so this is run off to iron.io, which we're using as our task runner. Iron.io basically provides a hosted Docker instance that will run commands and look at how fast it runs when you speed the video up. That's awesome. I wish I'd do this during the day. But, you know, this is going to run for seven or eight minutes. While it's doing that, I'll just quickly run you through the UI. So it shows us the basics of our request because our payload is a form rather than JSON. It doesn't render the payload down the bottom. So now this is running for us. We're going to watch it run for seven or eight minutes. M-N-N-N-N-A. M-N-N-N-N-N-N-N-N-N-A. M-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N. So who's in. M-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N-N. We can have seven or eight minutes of this. If you like. No. No. OK. Maybe we won't OK. So now this is finished running. Took about 12 minutes this time. It's given us a log of the Python script that ran to generate this for us. There is a copy of this script available at the end of the talk, so don't leave early. And now we've got the link to download it. So we download the link, download the dump, open it up, and give it a second, and super exciting, an SQL dump file, but this one's actually been scrubbed of all sensitive data. So the user column, all the usernames is just user and whatever the UID is, and the email addresses is just user UID at example.com or whatever. So you can still use that database dump, but the sensitive information's been removed. So the next demo I've got is deployment notifications, also known as deployment notifications. So when you have a deployment, you may want to notify another system that deployments happen. So for example, New Relic is really good for keeping track of the metrics for your site, but one of the issues with New Relic is that sometimes you go in there and there's been a recent deployment. And if that information is recorded in another system, you're kind of trying to find out why the site has had a spike in load, for example, and that's because all the cases are being rebuilt, not because there's an increase in traffic or something like that. So being able to record the deployments in New Relic allows you to see that data in the same place. So I've got a quick little demo of how that works on Pantheon. So if we give it a sec, advance the slide and it should work. Here we go. So what we've got here is we'll tell Pantheon to deploy the changes. And so we hit the button and it does the deployment. And look at how fast Pantheon deploys these days. Their recent improvements, it's just really impressive. So now we've deployed the changes. Our site still works because we just upgraded for a patch level release of Drupal. Everything's changed on our site. If we had the HAT test, we'd be able to confirm that. And now we refresh our charts. And we can see down the side here, it's showing us the automation. In a couple of minutes, it'll give us a nice gray bar in the chart so we can actually see along with the rest of the metrics when that deployment occurred. So it's just a little thing that helps you understand a bit more about what's going on with your site. For those of you who do have access to a new relic, I recommend going into new relic on a regular basis, probably daily, and just understand what the graphs look like for your site. I've seen too many people who go into new relic when there's a problem and they just look for the peaks in the graph. And they assume that the peaks is where the problem is. Maybe it's a batch process that's running at 2 AM every day that we know is going to generate a lot of load and take a long time. But if you know your graphs and understand that data, then you're able to drill into where the real problems are when issues arise. So this is just the webhook I was going to try to give a quick run through of this, but given our awesome AV, we'll just skip it. Now repo deployment, this is so cool. It was going to be two repo deployments, but economically we've got to cut things back a bit. There is actually a shortcut in this. The process is that you have two repositories. In this case, we've got one on GitHub and one on platform SH. And don't tell anyone here from platform SH, good, I can tell you a secret. Don't buy the extra seats on platform SH. Just use GitHub and only have one user on platform SH. So they might ask for their little spaceman back off me now. So we commit our changes, we push the changes to GitHub. We'd normally submit a pull request and we'd run the tests against a pull request. But I did a copy of the video and it was really boring watching someone actually review a pull request and merge it. So I'm just making the changes straight on master to make it a bit faster and a bit more interesting. The tests will still run and then there's a deployment step in there. So once it passes, it commits to the platform SH repo and platform SH has got their auto deployment stuff. It'll import the configuration changes and stuff. So let's have a look at that. So here's my Drupalcon demo site, which is running on platform SH. And I'm using CircleCI because I didn't want to pay traverts. So this video playing, yes, here we go. So once again, live coding, well, recorded coding with typos, of course. So now we'll edit the site title because that's become like the hello world for Drupal 8 demos because it's so easy. So we'll change it from Drupalcon demo to Drupalcon Dublin demo so I'm not recycling it from another event. And I can tell you this was done this morning so it hasn't been used before. So now we've updated our site title and we're going to push that. And we'll see here that it's going to GitHub. That because we've got our work done, that makes us very happy. Oh boy! Don't look at me boy! Who feels like that after you commit some really good code? All right. So now we're going to watch this run in CircleCI. And CircleCI, it's amazingly fast, as we can see here. It's just flying through, setting up the environment, composer install so fast. And now it's running our tests. And I cheated a bit, it's only giving us a couple of tests here. But it's always great when the tests do pass. And then it's doing our deployment onto PlatformSH for us. And so it takes a little bit for that to run again through the magic of TV, it only takes seconds. And so now that has deployed our changes over onto PlatformSH. And we can see up the top here that our tests passed. And generally this is me when my tests pass. Oh I'm missing one of my things. Damn. Okay. There was meant to be the two-headed monster being surprised there. I don't know why that didn't play. But it seems to be a day for it. So now we'll have a look here at our update actually landing. There we go. So it's gone from Drupalcon to Drupalcon Dublin. If you blinked you probably missed it. You're wonderful. See? So that's how you should feel when your code lands in production. So before I wrap up I want to encourage all of you to a write. So with a lot of this stuff it's not like I've talked to people who they want to have like this awesome CI setup. They want to get into continuous delivery, continuous deployment and they find it overwhelming because there's just so much that they think they need to get done. But with code we iterate on our code. We make small changes, we improve it over time, we make things better. And so we should adopt the same approach with our automation. So pick some of the small things from my examples today. There is actually going to be code available online. We'll get to that slide in a minute. And you'll be able to do this stuff. And there's loads of resources online. So just start with small things and iterate. And once you get that iteration right you end up building things slowly and you end up with an interconnected system to manage everything and it looks like this. Which is pretty impressive once you get to that point. No, no, Dark Crystal. Also by Henson. Yeah. I've watched so many hours of Jim Henson footage to prepare this talk. So yeah, thanks everyone. I've enjoyed the session. So... What was that? That was very strange. It was very weird. It was kind of amusing. Yes, it was rather funny. It was incredibly funny. I loved it. Yeah, I loved it. Wonderful. Thank you. Now for those of you who didn't like my talk, I suggest you go watch Meet the Fables. You'll probably enjoy it. And if you did enjoy it, please go fill out the survey again. If you didn't enjoy it, just go watch Meet the Fables. So has anyone got any questions for me? And bugger, it's cut off my URL. OK, so while I'm answering questions, go follow me on Twitter. If you want to learn more about me, go to oopldeveloper.com.half&a. It should be .au. And the resources from today's session are available at that very easy to remember URL. It was a lot shorter than the gist URL. There's a couple of... Sorry? Yeah, I will. The one of the two repo deployment, there's a couple of tokens that I need to strip out and just throw that up. But that will be up later today. But everything else I've run through is available online. So any questions? Did you explain? Maybe I missed it, but the pre-commit hook. One of the key things in there is it only checks changed files, which means it's really fast. And yeah, I have used a version of that. There's one on GitHub that's like a PHP pre-commit hook that's similar, and that saved me many times I work projects from pushing broken code. Yeah, I did actually forget to mention that, that it does check only the files that have changed. So if you've got a project that's an absolute mess, you can use the pre-commit hook to just clean up file by file as you go. So over time, you're improving the quality of the code base. Two questions, one is... You're only allowed one, I'm sorry. Okay, then there are reasons that you didn't demo the Aki Cloud? Yeah. Yes, what is the reason? Because I used all three of the big hosting companies in my demo because I think that I should be fair to all of them. So I used Aki because I've written a library to interact with the cloud API, which makes it easy to copy the database from one environment to another for the sanitization. I use PlatformSH because their automation stuff is brilliant. It makes it so easy to have composer-based workflows and all of that stuff out of the box. And Pantheon's good because of the new relic is included free, so that's why I used all three of them. Good, can I take another one? Yeah, all right. Okay. Your first one was so good. So there is not a silver bullet here, but I mean, the set of tools that you just showed, do you think that for a big corporation, in an enterprise world, it works? I think it does. Some of the code I demoed here was copy and pasted from a large enterprise client of mine with some alterations and their support in me doing that. But the general thing with large organizations running Drupal is that they need to be able to manage many Drupal sites in a consistent way. So having automation is key to making that happen. Yep, thank you. Cool, yeah, up at the mic. Get some exercise. I was hoping you were actually just gonna ask you. You can close your rings by getting up and looking. Yeah, yes. The Acquia library you mentioned, do you open source that or is it private? Yeah, no, it's open source. And it's got full test coverage and it's on GitHub. So yeah, Patch is welcome if you've got suggestions for it. Thanks. Yep, no worries. Actually, and sorry for the screen, I'll try to fix it. Oh, so it's all your fault? No, it's absolutely my fault. Everybody, if you didn't like the screen, blame this guy. He's from Acquia. Yeah, yeah, he's from Acquia. Yeah. So it's a very good thing that we're trying to clean up the things before actually we commit, which leads us to one of the things that we're trying to do also in Acquia, which is trying to have the developers not interfere too much with the downtime that we're going to have. It's a little bit the presentation I'm going to give afterwards, also in this room. And I hope the screen is fixed. But this really helps, this is really helpful because then all the problems that you have, like when they commit stuff and they don't check it and goes live and the site is down, it doesn't actually interfere, it doesn't create more alerts, more toil and stuff that we want to remove on SRE. So this, you already mentioned, it's open source, everybody can use it and it works, we can just modify it and it works on other providers. Is that correct? Yep, that's exactly right. And in the resources links I've provided, I've also linked to how I'm running this server side on Travis CI for one of my Drupal modules. So you can't actually merge a pull request into that module without it passing on Travis. Any more questions? Okay, well, thank you all for coming. And yeah, I hope you enjoyed learning about Evox. And go back to work and talk to management about the need for Evox.