Continuous Integration Step by Step

Continuous Integration raises a few questions: How do you write a workflow? How do you trigger it? And how can we use one to make Taylor's life easier as he closes PRs? Let's tackle that in our introductory lesson!

We all know that the biggest argument in software is how to format code - so much so that we have tools like Laravel Pint to settle such disputes. But we don't want to run Pint manually! What are we, animals?! Instead, let's write a workflow that will automatically clean up our codebase any time we make a change.

When you think of Continuous Integration, you think of running tests. It's very common to ensure you have a green suite before you push to production. Let's tackle setting up a workflow that allows us to run Pest, and we'll cover some considerations you'll want to keep in mind along the way.

I tend to stick with SQLite for as long as I can get away with it, but you'll inevitably find yourself needing to execute tests against MySQL or Postgres at some point. How do we do that in Github Actions? In a word: services! Let's take a look.

Every time our workflow runs, we have to rebuild the world from scratch. Whether that's compiling PHP extensions or installing Composer dependencies, it takes time - sometimes minutes! Thankfully, Github provides a solution by allowing us to cache resources across workflow runs. This can dramatically decrease the runtime (and perhaps even cost) of your CI pipeline, so it's well worth your time.

In programming, we have a mantra - "Don't Repeat Yourself". Why should it be any different with Github Actions? Let's take a look at how we can extract the common setup steps across our workflows into a single, tidy composite action.

We don't push sensitive information to source control. In Laravel, we have a local .env file that sits outside of our repository. Is it possible to do something similar in a workflow file? You bet it is! It's time to introduce you to secrets.

It's common in CI to run a coverage report to make sure your team continue to back up new features with tests. To support coverage, we'll need to install and configure a coverage driver, like XDebug. Turns out it's not as tricky as you might first think.

If you're using Forge, you may be quite happy with the handy "Quick Deploy" feature it provides. However, as your app and team starts to grow, you'll no doubt want a little more fine-grain control over both when and where to deploy. Let's wrap up the series by looking at one approach for this.