Ever faced issues with spiky build and test loads toward the end of a sprint? I certainly have my share of experiences. Managing build infrastructure has very similar challenges to what is observed when supporting the dynamic nature of application environments. The customers – the software developers, in this case – should be able to use these capabilities without worrying about any service limits, caring about the time of the day they are working, or facing system slowness in any regard. I have managed GitLab runners for my team in the past and had all sorts of automations and requirements covered to the best of my knowledge. But now and then, an additional edge case used to emerge, requiring more modifications around the build environment’s availability and scalability, among other challenges. Striking the right balance between cost and system availability was another big task.
The cloud’s pay-as-you-go model and elasticity fit very well with the needs of creating and maintaining a build/test server farm. CodeBuild adds to this by offering a lot of other features you can cherry-pick that work well with the kind of applications you are supporting. Let’s dive into the basics of the service; we’ll cover some interesting features later.
How CodeBuild works
CodeBuild offers managed build environments that can be extensively customized. Whenever you’re thinking of building code artifacts or testing recent code revisions, you should evaluate CodeBuild. You can choose the specifications of your build environment, what compute and memory power they should have, what runtimes they should support, and what commands or scripts need to be executed. Depending on the outcomes of these scripts, you can define follow-up workflows for your application. It uses the following constructs:
• Build project: This is where all the configuration sits. It defines how to run a build, where to source the code from, what commands to execute, and where to store the outputs (artifacts).
You can be very specific with operating systems, programming language runtimes, and so on. You can choose specific build environments by targeting a docker image, which is what the service uses in the background, to spin up your build/test instance.
- BuildSpec: This is thespecification of what commands to execute for validating certain aspects of your code base. It could either be defined as part of your build project or maintained separately together with your code. The latter is a common approach as it ensures visibility for all software developers and allows modifications as code. It is defined in YAML format and allows dynamic configuration changes. The file is parsed and evaluated at runtime when a new code revision is pushed. We will look at a buildspec.yml file definition as part of the hands-on exercises toward the end of this chapter.
You can leverage this service’s features independently or together with CodePipeline, which we will cover in the following sections. Some of the features that make this service a great choice will be discussed next.