 Thanks for taking it back after lunch. I know it might be ready right now. But what are you doing? Do you have a couple cook announcements? If you have lost anything, we go to Lawson Town for registration. So you can check right there. And after we wrap up everything today, we'll be getting out to the Museum of Madness on the clock tonight. There is a fantastic party. We won't miss it. You will need your badge to get in. We go to the bar. We're in your ID. We'll be checking those. And he's going to share with us something very technical. We can't wait to learn all that. Hi everyone. I'm really happy back here. I was here in 2016. That's the t-shirt. I love San Diego. I'm Carl Alexander. I basically write a lot on WordPress technical topics. You can also find me on Twitter. And this is my website. And speaking of my website, one of the common things with me is I like technical topics. I like advanced technical topics. And often people are like, oh, I didn't understand anything you said after this point, Carl. And that's okay. I have several strategies that I use that make my talks a bit different to help you with that. So first of all, there's going to be question breaks throughout the talk so that you can ask any questions in case there's something that I talked early on that you didn't capture and you have more questions about. You can ask me then instead of waiting until the end. Or you can interrupt me too. That's completely fine. And there's also going to be a companion article that is going to be posted after this talk that you can read more if you want because it's a very large topic. So you can read more about it. The slides are going to be there. So, yeah. So I wanted to start by talking about growing pains. We all want to write high-quality WordPress code. I don't think anybody here wants to wake up in the morning. It's like, I really want to write a shitty code. You know? I want to write the worst code. I want to be really embarrassed about it when I look at it at the end of the day. Nobody wants to do that. And it's hard. It's actually really hard. It requires kind of consistent alertness, constant effort on your part to be like, okay, I guess I could do this really easy, gimmicky solution now where I could, you know, take a bit more time and do it a bit better. Well, that's for you. Now imagine doing that as a group of people. Who here works long? Who here works quick? And who's here on a team of three or more? Yeah. And who here started with one and is now with a group of people? Yeah. So, I've done that. And I remember when it was just me and it was easy to keep myself in check. Easy to just be like, oh, you're that person. You should do this better. But, you know, now there's like gimmicky and, you know, John and Jane working on it and they might not have the same standards as you. You might not agree on the same things. It gets a lot harder. And that's because you're no longer the only person pushing code. Like, you're a team. There's code changes coming in all the time, all the times of day. So you really need a way to standardize what you're doing, what you think your standards should be, your coding standards, what your testing standards should be. And that's kind of the goal with continuous integration. You want to ensure that your code quality stays consistent. And you want to minimize going back and fixing things that Timmy did or Jane did or, you know, but the other way around, Timmy sees your code. He's like, I want to help Carl do that. Like, that's awful. And he just comes back and cleans it up. So you want to prevent those things. So what it does is it automates these different kind of workflows. So let's talk a bit more about continuous integration. So what is it? It's actually part of a larger practice called continuous deployment. Who here is familiar with the idea of a continuous deployment? Okay, quite a few of you. So this is what continuous deployment looks like. So, I mean, it can be, this is a simplified version of it, but basically you build, you build your software, you test it, you deploy it to a staging site, you create acceptance testing, then you deploy it to an option, and then you do some spoke tests to see that you didn't break everything and the site's down. Well, continuous integration is really the first part of that. So we'll talk about why there's like one part of the hour of solid and one of them isn't, but it's these two to four processes are what really define continuous integration. So let's talk about those processes. The first one, sorry, the first one is what we call the build process, which really for WordPress code comes down to like, okay, I'm checking out code for my repository, you know, whether you have a team, a plugin, or just an entire WordPress site. If you, this is really what defines more building for WordPress, so who here uses like SaaS or yeah, so a lot of you. So pre-compiling, pre-processed CSS, JavaScript, all this stuff needs to be minified either or converted to CSS. So that's part of your build process. Then you have testing. So for testing, testing can mean a lot of different things to people. Holy wars have been fought over testing, testing which type of testing is best, which one you should do first, but really in this context, more often than not what we do is some unit tests, but really the most basic ones that you can run because you're really trying to catch errors and things like that. It also includes things like code quality checking, complexity checking, static code analysis, and things like that. Where things can differ a bit is this idea of deploying to a staging site and running acceptance testing. So who here is similar with acceptance testing? Okay, so a few of you. So acceptance testing is this idea that your site's almost live, so you have like data in it that's meant to simulate what's on the live site, and then you want to really test to see that the website is behaving the way it should in this kind of live data. So depending on how intense you do it, you can even copy your data from the production site to the testing site consistently. But the problem is that this is where things vary a lot for people because not everybody has a staging site. Who here has a staging server? Well actually there's quite a few of you. I'm really impressed because normally there's not a lot of hosting providers that come with staging sites. Who here uses something like Antion or WP Engine for the two that really stand out for running staging sites? So these two hosting providers have staging sites. They're getting more and more common because they're useful also for just demoing stuff to clients and things like that. So a lot of the hosting providers do it. But on top of that, not everybody does acceptance testing either. So that's where the kind of, you know, where continuous integration of the implementation changes from one person to the other. Now what do you need to do continuous integration? Because continuous integration can exist on its own. It's not like just a piece of software and you install it and you're like, okay, I'm done. It actually relies on other processes and tools to do this job. So the biggest one, it seems, you know, I'm a bit obvious here to mention it, but you do need a version control system. So you need Git, you need SPN, or Material, or if you're in any industry, Perforce, whatever it is, you need one. Because you need your system to check out code, get it, run it, test it. And speaking of testing, you also need an automated test suite. Because if there's no tests to run, then there's a lot less to do and there's nothing to catch. There's no errors to catch and, you know, to yell at the other developer, hey, you broke something. So you need a testing suite to do that. And then this is more optional, but code quality tools, super useful. There's Code Sniffer and PHP and there's Mess Detector, that are the two big ones to use for PHP. So, why do we need continuous integration? Obviously, I mentioned it a bit at the beginning, but really it comes down to, we as developers, we want it, there's pressure from our bosses, but also to ourselves, we want to commit code often. You want to make a change, just push it and be done with it when you catch something. You don't want to have to think about it or do more. There's this idea if you work with agile, extreme programming, whichever methodology that you're using, the idea is you want to commit code often. And there's a lot of benefits to doing that, but it's not without its issues either. So, here has broken a left side of the client code. Yeah. Everybody, right? So, the faster this happens, the faster errors can get split in. You know, you've got a typo fix and actually you forgot to put a semicolon in it and you just broke everything. Because you were like, you didn't even refresh the page, you were just like, oh, I'm just going to fix this, you hit it, send it up, and then you didn't put a semicolon and you just broke the site. So, you really don't want it to let it affect the quality of your code because, again, you make changes quickly and you might be, oh, I'm just going to make this variable A and I'll be done with this. And you want to catch these errors as well. So, that's really the idea here is you want to prevent these two specific types of issues with continuous integration. So, this is our first question break. I don't know if any of you have questions so far. That's fine. All right, so piecing it together. So, I want to talk about two types of continuous integration workflows. So, the first one I want to talk about is what I would call a local workflow. So, just doing it on your own machine. So, why would we want to do that? I mean, after all, we're talking about automation, about working as a team. Why would you want to do it on your own machine? Well, first of all, it's a lot easier to get it up and running. You can do it on your machine on your own time. You get it working and then you don't have to sign up to the service, figure out how the service works, read all the documentation, connect your repository, all these things that we're going to see in a minute. So, it lets you test these things on your own. What's really useful about it is that even if you do all this work locally, it's still useful when you decide to move on to a service. And that's because of the tool that you can use to do that. It's called Grump PHP, although I just call it Grump. And Grump is basically this tool that takes all these other tools that PHP has for static code analysis, for mess detection, for code styling. And it bundles them all together and lets you... It checks all your code whenever you commit. So, it's also the only tool to do... There's no other tool like it in the PHP ecosystem. So, like I said, it lets you run these code qualities. So, if you have a PHP unit, it'll run your unit tests. It'll run your code styling checks. It'll run everything. You can even tell it to check your commit messages. It'll yell at you if you do... Your commit messages are too long. You can really... It's very, very, very flexible. And it's all done through...