We mostly do software development on our laptops, which are obviously computers in a way that we are familiar with: screen, keyboard, and a CPU that heats up every time I need to create and test a build (i.e., compile our software so that you can load it in your browser). I often edit files on my hard drive, which are then compiled and loaded locally in my browser where, if I’m working on a user interface element, I can see if the code is working the way that I expect. But when I get to the point where I’m ready to submit my code for a code review, things move to the cloud.
We use GitHub to store our code, which makes it easy for developers to share proposed changes, review them, and eventually merge them into the branches we use to track our stage and production environments. Any change that goes to production has to start by being merged into a special branch called Develop. When that happens, GitHub tells an AWS service called CodeBuild that there’s been a code change, and CodeBuild grabs the latest code and builds it. In fact, you can see the status of the latest stage build by looking at this badge:
In general, by the time we merge a set of changes into Develop the changes have been through a battery of testing and review, so hopefully if you see the badge above you’ll know that the build is passing. But this is a stage environment, and every once in a while a build will blow up and you may see that a build has failed. You’re more likely to glimpse a blue badge that tells you that a build is in progress, and about four minutes later you’ll hopefully see the badge go back to green.
What’s great about CodeBuild is that it takes all of the code that worked so well on a developers’ laptop and in our test environment and it rebuilds it from scratch. A bunch of libraries we use get downloaded from a repository called npm. These libraries are composed of about 115,000 files that are used to develop and test the application and are compiled with the correct configurations (stage APIs, stage accounts, etc.). The resulting 49 files are published to a stage URL where we can sanity test that the build worked, show a new feature to a colleague, or even demo the feature for a customer to make sure we got something right before we push it to production.
There’s actually a lot more goodness baked into CodeBuild that taken together really is transformative. For starters, we don’t have to maintain any of the servers that CodeBuild runs on; AWS maintains enough hardware that it can spin up a container to run a build process for us within a few seconds of our code being checked into GitHub. All we have to do is tell CodeBuild where our GitHub repository is and what kind of project it is, and it takes care of the rest. No servers, no system administrators, no patches. I appreciate it every bit as much as I appreciate not having to raise and dress chickens myself any more. Sure, I’d love to raise chickens and manage a data center if I had infinite time, but that’s not the world we live in.
Like all the Build-as-a-Service systems that I’ve used, CodeBuild uses a configuration file that makes it easy for us to ask more or less of the build system over time. We can run configuration scripts before we create a build, and run test and cleanup scripts after the build.
Not only does CodeBuild automate work that some developers still have to do by hand on hardware they have to maintain themselves, it also allows us to build much more often than we would if we didn’t have access to this cloud service. This means that our customers use an application that is a great deal more reliable than it otherwise would be, even as we update it more frequently than any application we’ve ever built.