GitHub Action Patterns

[00:00:00]
>> Steve Kinney: In fact, let's, from the room right now, whose CI/CD is in GitHub Actions? All but one. That was more than I expected though. All right, we also have some on ADO pipelines. We used to have some in Jenkins and Octopus, so Jenkins. That's a name I have not heard in a long time and have no fond memories of. Yeah, you know, maybe you're using GitHub Actions, maybe you're using BuildKite, maybe using Jenkins.

[00:00:35]
What were the other ones? Octopus Deploy. Octopus Deploy. All right, I've never heard that one, and so we'll do this in the kind of broad sense because anything we're talking about works in any of the CI/CD processes and possibly even Jenkins. You can make Jenkins do anything. You can make Jenkins do anything, and Jenkins is one of those things, if you're self-hosting it, whichever one has worked in your company is usually probably seven versions back.

[00:01:15]
But the overall philosophy is the same whether it's being run through BuildKite or Jenkins or Octopus Deploy, which I just learned about, or Circle CI or Travis CI or what have you. They've all got their, the high level is all the same, right? Which is, first of all, building everything all the time doesn't work, right? And most of these have a way, because almost always—I shouldn't say that. Much of the time, it is usually some kind of Git commit that is kicking something off, right?

[00:01:52]
Especially if you're doing it against the PR, it's a Git commit, and with that Git commit, you have arguably the files that changed, unless you're using Git in a way that I'm unaware of, right? And you can kind of see what are the things that we should run. So there's always an argument of figuring out how to detect what the changes are, right? And Turbo repo will do some of this for you out of the box, but I'm not insisting that you use Turborepo either, right?

[00:02:22]
But figuring out what were the changes and what should we kick off, right, and then testing and deploying just those kinds of pieces, because if you have to test everything all the time, that is usually the argument that people will make for, and this is why we need a lot of repos. Because if everything is broken up into its own repo, you have effectively accomplished this goal, right? Which is a push to one repo that kicks off its own CI/CD process, because the monolith and the repo is the unit of measurement.

[00:02:59]
I think a lot of times the pain that we feel in the monolithic architecture, the solution feels like, well, if I just made multiple repos, I don't have a problem. You don't have those problems, you just have new and different problems. And so part of our goal is the thinking around, well, how do we get the advantage of being able to do things atomically and having all the packages kind of in a given—at that commit, we know the state of the world, right?

[00:03:26]
If everything can move at its own pace, maybe that autonomy is good, but it comes with complexity. And if that complexity is worth it, break it up into multiple repos, 100%. You know, and we'll use GitHub Actions here as the metaphor, but we will kind of think about it in a general sense. So GitHub Actions, for instance, you know, a workflow might contain many jobs, right? Each job will run kind of in its own container, and then you might have a number of steps in the job, right?

[00:04:08]
And, you know, that could be like, okay, install all the packages from npm, run the makefile on the server, right? Those are all maybe the steps, and then once you've installed all the packages, maybe it's build the application or what have you, right? Then run the tests, and we can kind of begin to put all these things in place. But I think the interesting part is, for whatever the tool that you're using is, trying to figure out can I do as little as I can get away with, and what can I parallelize, right?

[00:04:46]
And so if we have done a good job establishing those boundaries like we saw with, you know, ESLint rules that we saw earlier is one way to do it, it will always depend. If we know that a package is an isolated unit of a team, right, then theoretically we can look at, did anything change in this package? Do I need to run the test for that? Applying more of the ideas from Turbo repo if you're not using Turbo repo into your overall architecture, right.

[00:05:25]
And if, in the moment people are crossing those boundary lines where it's like, I'm on the dashboard team and I reached in to grab a file from the design system, right, without it being part of the public API. Well, guess what, you just broke the ability to run just the way you will fix that is you'll decide, okay, I guess we need to run all the tests all the time, right? And then you'll be fine again, right?

[00:05:51]
And that's whether you have one repo or many repos. If stuff starts leaking and gets weird, the solution is going to be CI has to pull down all the repos and run the tests. You can create the same problems in any of these architectures, no matter what, unless you kind of enforce those boundaries you can keep in place. In GitHub Actions, you have the ability to either, if you've got the monorepo or you've got a monolith, obviously everything is easy because that's the value prop of the one repo to the thing, right?

[00:06:29]
But even in GitHub Actions, you have something called workflow dispatch, right, where you could say, hey, when maybe the database schema is its own repo, which I've seen very common, right, where all the database stuff is its own repo, infra runs that, right, and there's a bunch of checks, and first, you know, you open up a PR to infra's database schema repo, that gets merged in, and then the next things happen, right?

[00:06:55]
You can send workflow dispatches from one GitHub Actions one to another repo to kick off another job there as well.