Continuous Integration

[00:00:00]
>> Brian Holt: So when we're talking about CI/CD, we have done the CD portion, we are about to do the CI portion. So the idea between continuous delivery or continuous deployment is that whenever something is done, there's no person there saying like, alright, ready to go, like as soon as everything is built and validated and all that kind of stuff, and all the tests have passed, at that point it automatically goes out to production.

[00:00:28]
This is like from having worked at companies that don't do this versus companies that do do this. It can be a little bit scary to have like these automated rolling deployments of like, hey, everything that makes it into master is going to head out to production, but you ship so much faster and you have like a really high quality bar. So because anytime that you're merging into master, like, it's been reviewed, it's been tested, it's been all these kind of different things, and you just have like this assurance that like if I can get it in a master, it's going to go and deployed.

[00:00:58]
So some of this you can't really control too much of, but like a good example, this would be like a service that takes like 30 minutes to build, you know, and you have people committing to it all the time. You can't have like a bunch of 30-minute builds going at the same time, so maybe you'll like roll them up into like one release and then release it at the end of the day or something like that.

[00:01:23]
I guess my plea for you is just like, please deploy multiple times a week. Like that's the bar I think any software should set. Daily, multiple times daily, like you're really into like elite company at that point, but like, if you find yourself releasing every other week, every month, it's just too slow. That's my opinion, and I like, I, if you end up with such better software if you can ship more quickly.

[00:01:50]
So that's the CD portion, that is like the end result, now we need to do the part up to that, which is like getting confidence in your builds. That is the CI portion of CI/CD. So we won't cover all this. CI/CD is like a very deep topic. It's like people's entire jobs and it's not my job full time, but I do it, you can call me a CI/CD enthusiast. I do enjoy this part of the process.

[00:02:20]
So there's so many ways to do this. We're just going to do it with Vercel and GitHub Actions, which I'm going to describe as like a lighter weight approach to this. Google, or sorry, GitHub Actions that have come a long way. You can actually have a pretty sophisticated setup with them now. I mean, a good example of this, if I just go to my repo here, like the one for the full stack wiki.

[00:02:48]
I'm pretty proud of the CI/CD process. Wherever it is. Full stack wiki. Like if we go into the actions here and look at the last action run. This was me at, what time was this, 12 hours ago. So yeah, about 1:30 in the morning, 11:50 in the morning. But it, this has 13 steps to the CI/CD process, right? But that means every time this goes out, I'm positive everything passed lint, everything passed type check.

[00:03:24]
All the unit tests pass, all of the end-to-end tests passed, right? And so I'm pretty confident at that point that like things are at least mostly working at that point. It breeds a high level of confidence. Similarly, if you look at like a, do I have this up here? No. Show more activity here. I want, yeah, this one. This one as well, I have fear with GitHub Actions as well.

[00:03:59]
So actually perfect example, Dustin, our fearless leader over there, committed something to this, but he doesn't have to redeploy it. There's already GitHub Actions here that do everything for him. So that he can just commit stuff to it, he doesn't have to tell me, he can just put Brian's stupid and put that in there, and it's going to go out to production right away, right, which is exactly what we want.

[00:04:20]
But he committed something, this goes out, it builds, it reports the build status, and it just deploys. This all is hosted on GitHub pages, so I don't pay anything for it as well, which is great. But there you go. That's why like I'm asserting here, you can actually get pretty sophisticated with these builds. OK, so let's go ahead and get started on this like CI portion. We'll do GitHub actions here in just a second.

[00:04:52]
I want to show you the Vercel side of things first, because I think it's pretty cool. Let's, so we have our app here. What should we do to our app? Like let's, what, how can we make it like different? Maybe we change like the styling somehow. I don't know, let's open our source, globals.css here. Let's see if we can find something fun to mess around with here. Or we can even just use Copilot to do something really dumb.

[00:05:43]
Let's do something extra dumb here. Make the main brand color seafoam green. Make it real pretty like. Please. So let's just, let's see what GitHub Copilot comes up with. I don't know I'm just trying to show you something so that we can visually see a difference between a preview deployment and the actual deployment. I mean, I'm interested to see what I, what GitHub thinks is beautiful.

[00:06:19]
Modern, vibrant, we don't want none of that dated seafoam green. That's what I always say. That's what mom always said. There you go, that is so modern. You could even call it postmodern. All right, well. I don't even really care what it looks like, because we're just going to open a PR, but what we will find out. Keep that. Get status, so this ended up just modifying globals.css.

[00:07:06]
We're going to put this into a branch. So git checkout -b. Mighty seafoam. OK, and then we're going to get add ., git commit. What does Copilot think seafoam is? OK, git push origin mighty seafoam. What what what? What do we do here? Source respect might might mighty mighty seafoam. OK. Now, let's go back to Btholt. FEM Wiki Masters, we got this, we're going to compare and pull request.

[00:07:51]
I don't write these things myself anymore, please summarize this for me, Copilot. The ones I always wrote were just a joke, so I would just do this because this is always way better. And they always come out with like really nice things. It's got links and stuff, yeah. Create pull request. OK. And then immediately in here, we should see Vercel saying, I'm working on a build for you.

[00:08:32]
So Vercel has commented now, this is the update on your project. You can look at the building, this just takes you directly into Vercel. You can see what the build is happening, what's happening in the build rather. OK, generating all the static stuff, blah blah blah. Build completed, deploying outputs. And we should get pretty close to build here. All right, so let's go back here.

[00:09:08]
It should edit this fairly quickly to say that this is built. Is there, right there. Ready. So now we can do preview. It's going to authenticate with me, with my Vercel, so I'm logged into my Vercel account right now, so if you go and navigate to this, it should block you. I am navigating right now, you can see you got some modern mighty seafoam up here. I don't really know if it did too much more than that.

[00:09:35]
I don't think it did. Oh, look, it's kind of seafoamy green right there. Again, if I wanted to be able to like log into this and edit it, I'd have to go add this to my Neon Auth redirect URLs. So I'm not going to do that right now. I showed you how to do that earlier. But let me show you like something that I find very cool about this, we use it all the time at Neon. This little feature right here.

[00:10:11]
I'm going to click comment. And then I'm going to say. This is not seafoam. What the actual and then just say send. So now what's cool about this is if someone once someone else comes and logs in, they can see, Brian has commented on this, like, we'll go back and forth to the designers and the developers here on these preview deployments. But again, what's really cool about this is, it's going to block merging until all those comments are reserved as well, or sorry that they are like resolved.

[00:11:01]
So, super, super cool here. All these are going to fail, so that's fine. So because he he's right there, unresolved feedback. Again, if I go back into our comments here. And I come in here. It's it's better if it's in all caps all the time. That's what I like to call professional etiquette. And then at some point you can just say, resolve this, Brian, and then come back here and it'll resolve that, at least that check on GitHub, right?

[00:00:00]
No unresolved feedback. So I like that, it's like human in the loop stuff where you can basically say like, hey, go fix this before we could we log in. You can send this to the product managers, to the designers, to tech leads, all that kind of stuff.