 Git hooks. So if you're familiar with Git hooks, um, it's, if you're not familiar with Git hooks, it's very similar to WordPress hooks. It's just whenever something happens in Git, it'll run this script. So the idea is that you can't commit code without the tool running, and if the tools fail, it'll just yell at you and prevent you from committing that code until you fix the issue. Also, if you can technically turn it off, but you know, you should yell at the other person that may even feel bad if you disable it and commit code, but really the idea is that it runs all the time and it catches them before the code even leaves your computer to make it too, to your Git repository. So it comes down to it, it's almost the same thing as if you were, it was done elsewhere. It's just done on your machine. But it doesn't have limitations. So the big limitations with it are you have no control over the environment. So it runs on your machine. So that means that if somebody's on Windows and your own Linux and the other person's on Mac, those can affect how the tools run. You're also not reproducing a live environment, if that's important. You might not have the same data. If you're using data to run your tests, you might not have the same thing. So it's harder to standardize it so that everybody, the code, the checks that are being done are done in a kind of uniform kind of way. The other ones that I want to talk about is what we call hosted services. So hosted services are basically continuous integration in the cloud. It's a super broad category if you, if you try to look at different continuous integration services, you'll find dozens. The ones that I want to focus on all support WordPress in some way or another. And they also have a lot of common features. So I want to talk about these common features. First, a lot, all of them have a free tier. So I like free stuff. I think everybody here loves free stuff. Free tiers I think are super important for evaluating these types of services. You want to test. You want to see how they work. You want to see if they solve a problem for you. And you know what? For most of us, if you work in a small team or if you're a small agency, you actually can do a lot with just a free tier from one of these services. So it's really awesome for that. And they also, a lot of them also support open source projects, which is great. So if you have an open source, then they'll do it for free. And some of them will even do more for you than the free tier. So that's super useful as well. They use YAML for configuration. So who here is familiar with YAML? Okay, good. It's kind of a documentation format. The big thing about it is that it's super easy to read. So if you read a configuration file, it's all written in English. It makes it really easy to read, to see what's going on, what you're trying to do. The other thing that they use, they all integrate with your version control system. That's pretty obvious that they need to do that. There's some kind of exceptions here. Some of them, as we'll see, are kind of platform specific. But in general, most of them support GitHub. So I think who here uses GitHub? Yeah, most of them use GitHub. So a lot of them support GitHub, except a few of them that we'll see that are more proprietary. They need to do that because they need to know when somebody pushes code. So the way these services work is you push code to GitHub, GitHub messages them, and they're like, okay, now run your tests, and then they'll go check out the new code and run all your tests on it. And what's cool too is that they can do it on different branches. So if you have teacher branches, PRs, things like that, they can also do this. It's like Appian, although I don't think most of us really use something, I guess, we use SVM a lot, but all these services only support Git. But most of us work with Git, so it shouldn't be too much of an issue. And all of them are supported with WPCI live, I accept from one. And that's what we'll see a bit later in the talk. So I want to take a second to compare these different services. So here are the five services in question that we're going to talk about. So there's Bitbucket pipeline, so who here uses Bitbucket? Okay, so we'll talk about Bitbucket in a second. You have Buddy, Circle, CI, GitLab, CI, who here uses GitLab? Cool, a few of you. And Travis. So let's start with Bitbucket. So Bitbucket is a bit like GitLab, like we saw. The thing with Bitbucket is that it's a feature of Bitbucket. So if you use Bitbucket, you actually have continuous integration for free. It's the pipeline's feature. It's a feature of Bitbucket. So the minute you use Bitbucket, you actually have a CI platform available to you for free. So that's like a big, big, big thing with Bitbucket. So if you're using, if you're really part of the Atlassian kind of platform, you use Jira, Bitbucket, all their tools, HipChat, then that might be the one that you want to take a look at more seriously. The other one that I want to talk about briefly, that's a bit different, but really interesting if you're not as tech savvy is Buddy. What's cool with Buddy is that they really have kind of this entire interface to build your continuous integration pipeline. They have all these actions that you can pick from, whether it's fdpa, checking out code, running some php, some ssh, your gulp. So that's what kind of like the pipeline looks when you start building it. So you can do like, if you're like building your precomposite assessment, identifying your JavaScript with gulp, you can run your gulp to do your build process. It's much more intuitive, but it's more basic because it's a graphical user interface. And it's also not supported with WPCLI. Although I've asked them to do it, but they haven't yet. So if you want to do something like what we'll see in a bit with WPCLI, you can do that. The other one is CircleCI. I like CircleCI a lot. CircleCI is kind of the most advanced platform out there. They're not complex, but they like to do very complex things with them. And they're feature rich, but it's really meant for a more advanced workflow. And if we have time at the end, I will show you what that can look like. The other one is GitLab CI. Again, it's very similar to Bitbucket. If you're using GitLab, you get GitLab CI for free. It's part of the platform. So if you're a GitLab user, you can just use that instead. If you're on GitHub and you really like... So I actually know a couple of people that have done this. So GitLab has a very interesting feature where they'll mirror a GitHub repository right into GitLab. And then you can just use the GitLab CI instead. So whenever you push changes to GitHub, GitLab will copy those changes over and then run your continuous integration workflow on it. The last one I want to talk about is Travis CI. So if you've touched continuous integration before, it's probably with Travis. Anybody here familiar with Travis? Okay, a couple of you. So Travis is kind of like the de facto continuous integration platform with GitHub. If you look at projects on GitHub that have continuous integration, you're using Travis 95% of the time. There's a lot of cool things with Travis, but the big one that's really useful for us as WordPress developers is they have a feature called Build Matrix. So what you can do is you can specify, let's say, I want to test all these versions of PHP and I want to test all these versions of WordPress. Well, they'll do, they'll run your continuous integration workflow on all possible combinations of those two things. So you can do that with something with Circle CI, but it's not as well done as it is with Travis. And often for if you're a plug-in agency, if you're building a plug-in, especially for plug-in agencies, I should say, and team shops where your team or your plug-in might be installed in these weird configurations of different WordPress versions, different PHP versions, it's really, really useful to run tests on this. Any questions? How can you get started with this? So how can you do your, you don't have anything, you've never done continuous integration, and you want to get started, what do you do? So the easiest way to do it is with, let me TCLI, there's a command, sorry, it looks like this. So you, so this isn't the example of plug-in, so you just say, I want to scaffold the plug-in tests for my plug-in, and then you specify what service that you want. So all the ones that we've mentioned so far, minus buddy, you can do. So you can then say, okay, I want to do it by default, it does for Travis. But let's say you want to use BitMucket, I want to do this for BitMucket. So you just say, okay, create my tests for my plug-in, and just do it for BitMucket, and it'll generate all your test files, your test skeletons, your config files for BitMucket, it'll do all of that for you. You can also do it if you have a team, it's a very similar command, so it's a plug-in test, it's a team test, and you just specify the service that you get. So what do you get with that? Like I said, you get the Continuous Integration Configuration file. So you don't have to figure out, you don't have to go reach your documentation and figure out what to do or how to set it up. You do it, it just generates it all for you, and you don't have to think about it. It also does, it also gives you rules for PHP code snippers. So if you want to follow the WordPress coding standards, it'll have the rules there for you, and it'll check all your plug-in codes for those violations of WordPress coding standards, and it will tell you where they are and how to fix it. It'll also give you a configuration file for PHP units. So PHP unit is the kind of standard unit testing tool for PHP, so it'll create all your skeletons for your tests, all the configuration files for your tests, and do it all for you, and all that you have to do at that point is just start writing tests for your plug-in. And then what do you have to do? You just need to connect your repository to the service that you want to use. So if the exception here is if you're using Bitbucket or GitLab, well, you don't need to do any of that because they're built into the platform, but if you're using CircleCI or Travis, then you need to go on Travis and say, okay, you can start monitoring this repo, and you'll go find the configuration on that the WPCLI abandoned for you, and it'll start running the two workflows for you. So what do you get with that? You get a workflow that consists of two processes. The first one is, like we said, it checks for codes on issues of private coding up to the WordPress code standards. If not, it will generate errors and tell you. Then it will run WordPress unit tests, the ones that it generated. So once you get your skeleton, you start writing tests, it'll run those as well to see if somebody pushes the code change and breaks the test. It will tell you. And then it does that on a mix of PHP and WordPress versions. So here, this varies a lot on the service that you use. So Travis supports the most PHP versions out of all the services. So if you're a client shop and you actually have people that have PHP 5.3 or 5.2, the only service that has those versions of PHP built in is Travis. But otherwise, all the other services support PHP 5.6 or newer. So this is a modern approach to development. And it's a huge topic. We've really kind of glanced at how to get started. But if you work in a large, large, large enterprise, these continuous integration deployment processes can get very large and complicated. And there's a lot of different services out there. I didn't even cover the ones that you can post yourself. So if you're familiar, there's one named Jenkins that's very, very, very popular. And those are hosted yourself. Actually, you could even post GitLab yourself and run that on your own. So we really didn't even look at self-posted, because I assume some of us really want to manage a server for continuous integration on top of learning about it. You can really customize this any way that you want. And you might think, oh, well, I do this and that's not really standard or this and that. But it's okay. Like, all of these services are very, very flexible and they can let you really build the custom workflow that you need. And that kind of brings me to this idea that if you already have processes that you have for checking code and enforcing quality and stuff like that, I would look into automating those first and not just jump in and use WPCLi. But WPCLi is great. It's a great, great, great, easy way to get started if you don't have any. And it's really a great foundation for any workflow that you want to do as well. Any questions? Yeah. Before you get started on this, let's say you haven't been any kind of CI or CD before, do you have any tips or like aha moments you had learning this stuff that might help you? Um, I mean, the big, so the question was, uh, when I started working with this, was there any kind of moment where I had a kind of ha-ha-ha illuminating, uh, Eureka moment about it? And it's not so much, it's, it's, it's not so much like a aha, but it's kind of a more of a like, I'm really passionate about writing the code. But if, if you read any of my stuff, like it's something that I'm really passionate about. And I'm really passionate about helping people do that. And what I found, what really kind of like hurt me was I want to trust people to do their best, but I want to catch them. And I don't want to be like looking over their shoulders. Because I've been like, I've been a PM. I've been like a team lead. I don't believe in micromanaging people. That's a topic for another time, but I don't believe in any micromanagement and looking over people's shoulders. I want to give them the courage to do what they want to do and, and the power to do it. So what I was trying to do is, is enable them.