Continuous integration doesn't have to be hard

Maybe "continuous integration" sounds like a complex thing to setup. We explain why it doesn't have to be, how to start small, and what the benefits are.

Show Notes

* Github Actions by Michael Heap (50% discount for podcast listeners)
* masteringlaravel.io - get a jump start on validation with our free worksheet

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:16):
And this is Aron.

Joel Clermont (00:16):
I would say these days it's becoming more common to have some sort of continuous integration tooling, CI for short, running as part of your project. Now maybe that's not you, I certainly have had projects in the past where I didn't set that up. But for you and I, and the way we work now, we find it valuable and I thought today we could talk a little bit about why that is and maybe give people some tips on how to get started and make it not seem like such a big scary thing.

Aaron Saray (00:49):
When you say CI or continuous integration, what does that actually mean?

Joel Clermont (00:54):
Before we get into the specifics of actual products or tools, I would say, at a high level I would describe it as some sort of system that integrates with your version control. Where when you push new code, whether that's to a branch or a feature request or anything like that, some automated stuff happens, right? It checks the code out, it maybe runs some tools across it, maybe it runs some unit tests, maybe it produces some reports. It can get really fancy and maybe it can deploy a test environment. At a high level, it is something that happens automatically when you push new code up to your source code repository.

Aaron Saray (01:41):
So it's automated tooling after you've pushed up the code but it's not necessarily deploying your software? That's continuous deployment?

Joel Clermont (01:50):
Yeah, I would draw a line there. Some of these terms and phrases, people have different strict definitions. But yeah, I would draw a line like the deployment and the delivery phase is something different from what we're going to talk about today.

Aaron Saray (02:04):
Okay. What is the value in that though? I'll tell you the reason why I'm asking that is because, for many years I found myself knowing it was a good thing but I didn't fully understand the value proposition. And I was always just so busy and I was like, "I got to get code out the door." It took a while first to even win my heart over to unit testing, now I 100% do unit testing. But it was like another thing I had to then learn and put in there. And I think it's important to kind of talk about what is the value proposition and why is this important, so that we can know to start implementing it. Especially since whenever you introduce new tooling or new concepts, it always kind of slows down things to begin with until you get comfortable and good at it.

Joel Clermont (02:48):
Yeah, there's a little bit of learning curve, there's no denying that. I'll talk about one. The first thing that came to mind is maybe not the thing I would have said when I first implemented one of these systems. But if you have it set up where somebody else is reviewing your code, one of the things I really like about CI is I get a whole bunch of green checks and assurance that this code doesn't like break everything before I even start looking at the individual code changes that they made. A lot of the things that the CI system will do are things that you can do locally as a developer. In fact, I would say they are things you should do locally, like running unit tests or running a style checker or a linter, or things like that.

Aaron Saray (03:34):
Those are the green check marks you're talking about?

Joel Clermont (03:37):
Yeah, those are just kind of like a smoke test that there's not something horribly wrong with this code that would cause it to just break out of the box. It doesn't mean I don't have to review the code. Obviously that's still important but it's just a nice sanity check. In the past, before I had a CI system if I was being diligent I would actually check that branch out and maybe run some of those things on my machine. So just not having to do that saves me some time and that's one benefit that I find from having that in place. The other side of it and maybe the one that most people will identify with first is that me as the developer, again, I should be doing a lot of these things locally but you know what, sometimes, again depending on the size and age of the project, maybe your test suite to run the entire thing is kind of slow. Or maybe locally I run tests against one's particular environment but for some reason we have to support multiple environments. Multiple versions of PHP or something like that. Having CI set up to do some of that grunt work automatically in the background when I just pushed my code, it's a time saver too and it's a safety net for me as the developer. Just like it is sort of for the person doing the code review.

Aaron Saray (04:56):
When I started getting involved with the idea of doing CI too, I was a little overwhelming because there's so many different choices and so many different things. So you kind of talked about, first of all, what are some of the things? You could do style testing, you could do unit testing, you could do all these different integration sort of tests, you could run tests with postman, you can do all these different things against your API. And then when you search for a CI tool, you end up with like Travis CI or CircleCI, or all of the main repos. Like GitLab has Actions of some sort, Bitbucket has pipelines. I think they might be called pipelines in GitLab too. And then GitHub has Actions. How would you kind of whittle it all down and get started?

Joel Clermont (05:49):
Well, I prefer to have fewer tools than more tools. I would say especially when starting out, I would reach for whatever I already have with my source control provider. If you're on GitHub, I would first start playing around with GitHub Actions before I bring in a third party. Now, I know some people will feel differently. There's some CI tools that are even optimized for Laravel application third party tools. So there's nothing wrong with going down that approach but if it's putting in your credit card or signing up for a new trial, if that's just enough friction to keep you from doing it, well then just use what's in your repo already.

Aaron Saray (06:29):
Yeah. And I think then you also don't have to use all of the tools you have locally, you can start to implement this one by one. I can give a good example of something actually. We were working on a older product and it had a number of really old PHP files. It was even before Laravel and we were trying to bring this up to speed and get this convert over some things and I made a mistake. I somehow put a typo in some PHP that was in a PHP file with a ton of PHP and a mixed HTML and all this stuff and stuff. My editor already was highlighting everything as all being wrong, so I pretty much missed that. Like, I missed the semicolon. When we deployed it was obviously a broken issue. What I ended up doing is thinking, "You know, I normally don't have a problem in Laravel app, but for something like this I'm going to need to lint this with PHP." I also found a package that could do multiple linting at the same time, multiple processes of it. The first thing we implemented in this project for CI was just something that would lint out the PHP files. I mean, it didn't take anything and it was something that actually would save us on this issue because I would've missed it. It was something I should have tested by hand but I didn't. People say you should test everything, and you should, but sometimes you don't. Having this in place just quickly in GitHub was a lifesaver then moving forward.

Joel Clermont (08:01):
Yeah. Well, and to be fair I probably looked at that code and didn't notice that. I can't remember if it was a... it was a missing semicolon, right?

Aaron Saray (08:12):
Yeah.

Joel Clermont (08:12):
People aren't perfect, especially when you're in a older project that's got a lot of legacy baggage that it's just really hard to miss those things that might seem kind of obvious in a newer, fresher application. But, yeah, that was a great one. And how long did it take you to set that up, would you say?

Aaron Saray (08:32):
I would say that was 15 minutes to 30 minutes. Somewhere in there, because I just had to remember how to make a GitHub action which is something that I know pretty well, but you have to always bring that up into your memory again, and then you know how to run this thing against all the files. So it was run it locally, figure out how to do that in a GitHub action, and then you're good to go.

Joel Clermont (08:54):
Let's try to maybe get a little more concrete, so let's just talk about GitHub Actions. I know there's other tools that work very similar so the concepts we're talking about here will likely apply if you're using a different version control system. But GitHub Actions, first of all the thing to know if you've never set one of these up is it's just a file or files in your repo. They go into special folder and they're formatted a certain way and that that's how GitHub knows this is your action. But it's not some separate thing. The reason I mentioned that is because, to me another benefit as we talk about this that I think of is, it's really some living documentation of how your project works to a certain extent. How do I run the unit test? How do I do these things? These are things you put in a README, but sometimes there's little quirks or things that might get missed. But if they're in that action file, then that's another piece of living documentation you can look at too.

Aaron Saray (09:57):
Right. Let's say you're kind of bought into this now, how do you get started with GitHub Actions? Because also I know they've changed a lot over the years too.

Joel Clermont (10:07):
Sure, yeah. I don't know if they've versioned them, but yeah it's gone through some changes in its life. Honestly, I start with the docs. I mean, that sounds like the boring answer but for you and I it's a sincere answer. That is where to start. If you're in the GitHub interface in your browser, there's a button to add an Action and it even has some templates to get you started. You could even just start there, but then take some time. I would bet to read through the high-level intro docs is going to take you maybe 30 minutes, but it'll explain the concepts. Because there are some different concepts of tasks and how there's input and output from things, and how that all flows together. Yeah, for sure start with the docs, that's always a good piece of advice.

Aaron Saray (11:00):
I would say if you're looking at the templates too, keep in mind that you're looking for a template for either Laravel, or PHP, or Composer. Those sort of three are a lot interchangeable, whereas a PHP or a Composer-based template might get you 95% of the way there and then you just have to make a few tweaks for your Laravel project.

Joel Clermont (11:21):
Yeah. That actually brings up a good point too is, there's this ecosystem of tasks for GitHub Actions, where you can import a task or refer to a task that somebody else wrote that has a lot of functionality in it and you just configure it with passing a few parameters to it. You can look at them, you probably should, and you should be a little wary because they're running inside the context of your repo. But there's a balance, you don't want to reinvent the wheel but you don't want to just blindly start pulling in things. It's sort of like packages in your Laravel app. They serve a purpose, they're useful, you definitely use them, but you wouldn't just grab a hundred random ones and try them out in your project and ship it to production that way. Another resource that I want to mention that I personally found useful is a book called Building GitHub Actions.
I wouldn't really describe it as a primer to GitHub Actions as a whole. You're going to have to come into it with a little bit of knowledge, but when you get to that step two or three where you want to start writing your own custom Actions or you find that your setup is getting a little lengthy, or maybe you have multiple projects and you want to share some logic between them, this book is really nice. So I would point people to that. It's reasonably priced. In fact, as we were kind of thinking about this episode, I reached out to the author of the book just to see like, "Hey, we're thinking about mentioning this on our next podcast. You got any good deals or anything like that?" He did send me a discount code so we'll put that in the show notes. Again, you look at it yourself and judge. I found it personally useful, I think you might. But the link will be there and that coupon code will be good for a while.

Aaron Saray (13:09):
If I had to leave anyone with kind of a final thought here, I'd say don't be afraid of taking the first step into continuous integration. I know I was and I just needed someone to push me and say, "It's going to be okay. Its worth a little bit of your investment. You can look at this, it doesn't have to take your whole entire next week of programming." Just find out how to do one thing, look at a package and open source package that maybe uses them too and yank one of those into your project. Just even something like that to understand what's happening. And just baby steps and, and get started.

Joel Clermont (13:50):
I haven't gotten big into the whole Internet of Things movement, if you want to call it that. Where everything connects to Wi-Fi and can be controlled remotely.

Aaron Saray (14:03):
Yeah, you're old school I get it.

Joel Clermont (14:06):
Okay, exactly-

Aaron Saray (14:07):
You probably turn on and off your lights with a switch like an animal, I get it.

Joel Clermont (14:12):
Like it's the 1920s. A while back we had to replace our garage door opener and that came Wi-Fi enabled and it was kind of cool. I could look at my phone and know if the garage door was open, like if we left the house and I was wondering. But I used that three times and never again. Recently we got a washer and dryer that also had Wi-Fi features. I didn't even bother setting those up because I just knew I wouldn't care. But there was something else about the dryer that I want to share with you, Aaron, and I'm just going to play this for you. And I just want to get your reaction on how necessary you think this feature of my dryer is, okay?

Aaron Saray (14:52):
Okay. See, I think you're expecting me to laugh more but I already have a rice maker that plays happy birthday when it stops.

Joel Clermont (15:17):
What?

Aaron Saray (15:17):
Yeah. Apparently this must just be coming to the US now, but Japan a lot of the appliances would play songs.

Joel Clermont (15:26):
Now I'm wondering if that song that my dryer plays is an actual song that existed before they put it in the dryer. Because if your rice maker plays happy birthday, I have to go out and do... Is there like a reverse audio search on Google like there is for images?

Aaron Saray (15:43):
Yeah, just try playing... Put Shazam on your phone. How could you not find the song?

Joel Clermont (15:52):
Yeah. At first it was kind of funny and now I'm like, "I probably should go figure out how to turn that off." Because I'm just like, "I don't know if I'm too old or not fun loving enough." But I bet the song just isn't doing it for me anymore. One other kind of fun fact about that song is, I would sing it around the house on purpose just to be funny I guess. I don't know if that's dad humor. But after like the 10th time, my wife got upset. Not because I was singing the song but because I was singing it slightly incorrectly. She's like, "I can't take it anymore." I was leaving notes out or something, so...

Aaron Saray (16:30):
I worked with a designer one time, we were both very musical. I mean, we both are. But we worked in this area and they kind of sequestered us off to the corner. There was a bunch of marketing people with us too like nerds in the corner and they would allow us to play our music on speaker. We'd played music and then we would both sing along. But then we started doing harmony. The next week one of us was singing harmony and then we decided that just to drive people nuts, we would just sing along but slightly off key to the entire song.

Joel Clermont (17:05):
That's horrible.

Aaron Saray (17:05):
One time it was off harmony, the other time it would be like, "Happy birthday to you." And you could just see the people in the cubicle it was like, "What's wrong with these guys?"

Joel Clermont (17:21):
Yeah, they weren't wrong.

Aaron Saray (17:25):
One of the things near and dear to our heart is creating validation rules in Laravel.

Joel Clermont (17:30):
Check out a worksheet we put together for building validation rules at masteringlaravel.io.