Automating Builds & Deployments

[00:00:00]
>> Erik Reinert: To recap really quickly, really fast, what have we done so far, right? We came out of stage one with a deployed environment and a process that allows us to ship code. Easiest way to put it. We went into stage two, we realized, okay, this is great that we have this set up, but it's kind of specific.

[00:00:21]
We could use some improving here. We knew a lot of painpoints. Again, we all went through the pain points of having to remember the commands and setting up the environment and da, da, da, da, da. I just want to reiterate that a lot of this isn't just creating cloud infrastructure and building things in the cloud.

[00:00:42]
A lot of creating deployments and infrastructure and stuff like that is also improving your environment and what you're working in, making it so that developers can move fast but also still do complex operations. That's really the problem you're trying to solve. If a dev is just like you said earlier, is it really just this?

[00:01:04]
Yeah, it really is just that. Because that's the point, right? Is to make it so that if a dev is just brand new to a project, they don't necessarily need to know what's Dockers running underneath the hood or anything like that. You've abstracted that problem away from them.

[00:01:20]
They just need to know the make commands that are available. That's it, right? And so again, even though it was such a challenge in the first part, we've now solved that problem and you could see the value that that provides. Like, that was the goal of that whole experiment was to show you the value that that provides so that you walk away with it.

[00:01:37]
So we added a make file, we added migrations, right? We said, okay, well, you know, copying and pasting schema into a query document or query, you know, input box, and then hoping to God it works, maybe isn't the best approach, maybe we should like use a tool that does this really well.

[00:01:55]
And so we added migrations as well. Two, like, nothing related to infrastructure, whatever, but two really huge wins that are going to make it so that we ship code faster, right? Improving the docker file. That improvement is really focused on cost, right? Like, how much are you spending in storage and ECR?

[00:02:14]
It's a lot easier to store a 90 megabyte image than a 300 megabyte image or a 500 megabyte image, right? You're cutting down those storage costs when you make that. On top of it, the other changes we did around, you know, making it cache in the specific places that we wanted it to will make your developers move faster.

[00:02:32]
Make Your pipelines go faster, right? So these are small changes and they might not be fully noticeable on the value that you're getting out of them. But again, we didn't make any massive changes and we're getting a lot of value out of it so that we can grow and move faster.

[00:02:46]
We still have a lot of like manual process, we still have to run the commands every time we want to do testing, and we don't really want to do that, right? Like, we really want to make it so that like, we just make our changes, push it, and then something does those rudimentary steps for us.

[00:03:02]
And that's really where GitHub Actions comes into play. Now I will say one thing, which is don't abuse your CI pipelines, please. For the people who manage them, please don't abuse your pipelines. What do I mean by that? What I mean is that things that you can run locally that will save you time rather than just expecting it to run in CI.

[00:03:24]
Try and do that. You know what I mean? Like, if you can run your unit tests locally, of course there are going to be unit tests that are run in CI. But like, maybe don't just blindly commit your code and hope that your tests work. Like maybe actually run the test locally, right?

[00:03:39]
If you wanna talk about real impactful changes, it's stuff like that that's gonna save you money and save you time in CI. I know we have stuff that happens at my company where people kind of blindly push code and I will see fail, fail, fail, fail, fail, fixed problem success, you know, and like that's.

[00:04:01]
It's just like there are times where I feel like I have to go to the developer and be like, hey man, I get what you're doing, but like, just run the test locally before it fails on lint nine times, okay? Like, just don't just be like, fix, push, fix, push.

[00:04:14]
Like try and understand what CI is doing. So that's our goal. Our goal is just to put the stuff in CI that we don't really wanna hav run twice. So what I'm going to do first is, I'm going to create a new directory. I'm gonna say mkdir.p.github/workflows. So I'm actually gonna make a directory in a directory, and then I'm gonna create a file called github.workflows, build and deploy.yaml, right?

[00:04:43]
So I'm going to create a new file and then I'm going to open up that file so I have a blank YAML file here. Show of hands, how many of you worked with YAML before? Okay, all of you. Fantastic. YAML is the standard language that we do. All of our configuring in Terraform uses hcl, but most of it's like JSON, YAML, HCL and stuff like that.

[00:05:03]
So get comfortable with YAML because you're definitely going to be using it quite a bit. So at the top of the file we are going to add the name of our workflow. We're going to add the name of the actual workflow that we are creating. In this case, it's called Build and Deploy.

[00:05:17]
It's the same name of our file. The next thing underneath we're going to add to that is what is called our triggers. So this is a GitHub Action specific thing, but this tells GitHub Actions what exactly should tell it to run pipelines. So there are really two things that are telling it to run pipelines.

[00:05:37]
The first one is a pull request and the second one is a push to the main branch. So that means that if I open up a pull request anywhere in this repository or, or if I push to the main branch anywhere in this repository, then I should get a pipeline.

[00:05:52]
Effectively the next thing I want to do is I want to add our very first job. We are going to take the Docker approach here. There are multiple ways of doing this. I could make a job that installs Go and then runs the go build on the actual runner itself for the job.

[00:06:14]
But that Go version may change. There may be other things that happen on the runner that are impacting the build. This is how Docker can be really helpful because again, we've already got the Make Build Image command. We're already using Docker to do it. Might as well just use Docker in our pipelines to build the image.

[00:06:31]
And we're shipping a container, so there's really no need to try and run Go directly in the run or in the build. What we're really going to do is we're going to tell it that our build stage builds us a image. Actually, that's all I'm going to do for now.

[00:06:47]
Just to get this started, I'm going to do that. And the reason why is because that is all you need really to start to get a pipeline running. I commit my code and I'm going to push it up. Now again, if you want to access this code, go check it out.

[00:07:02]
But you can see here that I pushed my code and hey, look at that, I got a little orange circle. We're actually cooking now. So if we go in here, look at that. GitHub Actions is running the exact same command that I run to build my container. Now, if we stopped here, the value we get out of this is every time we push code to our repo, we should know that the make build command works.

[00:07:32]
So that's nice. Good to know that at least every time we make a change that the build, you know, the build command works. But there may be more things we want, right? Like we kind of want to know that the migrations run successfully, right? We want it to also, like, do a deployment for us and all this other stuff.