teams working on different areas of the codebase. And then at one point, they would all merge it in and deal with the avalanche of merge conflicts. So continuous integration was introduced as a way to fix and streamline this workflow. And there's no shortage of services to assist with this. For example, Travis CI is really popular for open source code. The team at JetBrains has a tool called TeamCity. Or even GitHub has their own popular option called GitHub Actions. Notice, build, test, and deploy your code. So in effect, what this often translates to is we are pushing to production potentially multiple times a day versus once every three weeks, or once at the end of a six-week cycle. No, instead, we are continuously integrating our changes. But now, as you can imagine, if we take this approach, we need certain systems in place to assist us. For example, what if we push up to our central repository, but the tests are currently

changes. But now, as you can imagine, if we take this approach, we need certain systems in place to assist us. For example, what if we push up to our central repository, but the tests are currently failing? Well, in that case, yeah, we probably have a problem, and we don't want to push to production. So again, we need systems in place to assist with this. All right, let's have a look at GitHub Actions. But first, I have pushed the source code from episode six, where we worked on subscriptions and billing gateways. And in fact, if you didn't watch episode six, it doesn't matter. We just needed some kind of code that could be placed in version control. Just imagine this represents a full web app or a library or a tool or a framework. Okay, let's have a look at GitHub Actions. So I'm working with PHP, and it looks like they have a workflow to assist with this. Now, notice it wants to create a new commit where we add a new .github directory to the

GitHub Actions. So I'm working with php, and it looks like they have a workflow to assist with this. Now, notice it wants to create a new commit where we add a new .github directory to the project that includes our PHP workflow. Now, this can be a little confusing, and in fact, I often have to refer to the documentation. But hopefully, we should be able to parse what's going on here. Here, we have a set of jobs that need to run every time we merge new code into our main repository. And by the way, if you ever get confused, just click on over to documentation, and everything is illustrated here. Anyways, we can see this job runs on Ubuntu at the moment. But yeah, if you need it to run on Windows and Mac, for example, for Laravel Mix, it's important that the tool works in every OS. So for our workflow, we do run the entire suite on a Mac, and on Windows, and on Linux. But for this particular project, I think Ubuntu is fine. Okay, so here's

the tool works in every OS. So for our workflow, we do run the entire suite on a Mac, and on Windows, and on Linux. But for this particular project, I think Ubuntu is fine. Okay, so here's the steps that need to take place. First, it validates your composer.json file. So if we run this, I actually think it may fail. Yeah, there is no description property on our composer.json file. And if you were building a composer package, that would be very important. In this particular case, I think we can skip it. So I'm going to remove it. Next, we're going to cache the composer packages. So again, as you can imagine, if you are testing this suite across potentially three OSes, and maybe multiple versions of php or phpunit, that can take a pretty long time. So luckily, there are some convenience in place to cache your composer packages. Okay, next up, it installs your dependencies. So notice what we have here is effectively a list of steps we need to follow,

there are some convenience in place to cache your composer packages. Okay, next up, it installs your dependencies. So notice what we have here is effectively a list of steps we need to follow, or GitHub Actions needs to follow, in order to build and test your project. And here's the final step. So why don't we uncomment this section out. And we're going to add a new step to run our test suite. And how do we run it? Well, if we were using composer scripts, and in fact, I'll show you that real quick. Open up your composer.json file. And you could add at the bottom a script section. So you could add a script called test. And that will defer to maybe a command like phpunit. And I don't have a phpunit.xml file. So let's go to tests and add colors. And yeah, to be honest, I don't often reference composer scripts like this, but they're an option. So I could say composer test. And notice we get that output. Or I could say composer run scripts, it's kind of the long

I don't often reference composer scripts like this, but they're an option. So I could say composer test. And notice we get that output. Or I could say composer run scripts, it's kind of the long form. And that's all we're doing here. So yeah, if you want to keep that we would want to make a new commit with those changes, or you could defer to phpunit directly. Anyways, I think that's enough to get us going. So let's create our commit. And there we go. Okay, so now if I click over to actions, we have a new workflow running. Let's have a look. So we have our job build. And it's currently in progress. Ooh, but it fails. Let's see what happens. Cannot stub or mock class Gateway, which does not exist. It can't seem to find that. Oh, you know what, I know what the problem is here. Let's fix this. Let's run phpunit. And we're going to generate a configuration like this. And I should be able to stick with most of the defaults. So again, yeah, it's saying

here. Let's fix this. Let's run phpunit. And we're going to generate a configuration like this. And I should be able to stick with most of the defaults. So again, yeah, it's saying where's your source directory? Where's your test directory? Now, if I switch back, you'll see right here, we have our phpunit configuration. And notice there is a section to declare the boot strapper. So is there anything we need to run before our suite? And the answer is yes, we want to make sure we pull in our autoloader so that our PSR for autoloading is recognized. All right, let's run git status. And we will add phpunit.xml and commit with add phpunit configuration and push that up. Ah, yeah, it fails. And that's because on the GitHub website, we created that new commit to add the GitHub directory. So why don't we pull that in, merge it, that's fine. And if I run git log, you can see that commit here. Okay, so now I can push.

we created that new commit to add the GitHub directory. So why don't we pull that in, merge it, that's fine. And if I run git log, you can see that commit here. Okay, so now I can push up our changes. And now here's the key. Because I've made changes to our code, and I've pushed them up to a central repository, which again is continuous integration in practice, that's now going to trigger a new build, it's going to run our tests, and it could even determine whether or not we deploy to production. And all of this can be automated. So let's come back and switch back to our actions tab. We can see our new commit here. And it's already complete. And this time, it did pass. So let's have a look. We have our job. And again, notice that each of these is a step, one step to cache composer packages, another step to install dependencies, another step to run our test suite. And let's see, we have a warning here,

one step to cache composer packages, another step to install dependencies, another step to run our test suite. And let's see, we have a warning here, element coverage was not, oh, this is because of the default configuration. I will fix that. It's just a warning, though. And it had no bearing on the results of our tests. So if we want to fix that, by the way, let's go back to phpunit.xml. And let's see that warning is related to the covers annotation. So let's get rid of that. And we're not using coverage. Okay. And we could even add colors back on. Reformat. And I think that'll get us going. Anyways, let's make a commit. And we'll say tweak phpunit.xml. I'm instantly going to merge this back into the central repository. When that gets pushed up to GitHub, it will trigger a new build. That build can have a series of jobs associated with it.