Introduction

People working as Developer, DevOps, or SysOps hear a lot about the build of an application, screams that the build failed, and requests to not break the build all the time. So, what do they mean about the build? The developers write code and push it to a version control system such as GitHub, SVN, or CodeCommit. This source code needs to be analyzed and processed further so that it can be deployed to the production server or platform. 

The processing step can be any of the following:

1. Source code usually consists of classes, objects, methods, and functions. So, we have to compile and link them to make it in an installable or binary format.
2.  Running test cases or quality analysis on source code means that the source code will pass through the seven axes of code quality--duplication, code coverage, complexity, comments, bugs, unit test, and architecture and design.
3. Minimizing the image assets and JavaScript to decrease its downloadable size.

In layman terms, it is packaged and compiled, which makes the code ready for deployment on Production. Different programming languages are built in a different manner and using different tools and utilities. For example, Ruby and ROR uses rake, C and C++ use make, Java project uses Maven, NodeJS uses yarn, and Python uses PyBuilder.

Many enterprises use tools to automate these steps in order to obtain a reproducible and easily executable output. Some teams in an enterprise run the build tools or commands manually once the changes to the source code are done, and some team uses Continuous build tool such as CircleCI, Jenkins, and AWS CodeBuild, which automatically detects the changes made to the source code and act accordingly. When your teammate says don't break the build, they meant don't make changes in the source code in such a manner that let build fail. If the build fails, then it will stop all the developers from building the latest versions of code, until the previous code is fixed.

When we build an application, sometimes it creates another folder and adds all the binaries or packaged source code into the new folder. Later, those binaries or packaged source codes are directly deployed into the production. So, the preceding things differ based on the application stack. The build output that we usually obtain with Java-related applications may differ with the output that we will get with the NodeJS application.

In this chapter, we will cover two different applications both in different languages, that is, Java and NodeJS. We will understand why exactly we need to build the application. We will build Maven- and NodeJS-related applications on a local machine. Later on, we will see how CodeBuild works and how we can build both the Maven- and NodeJS-related applications in CodeBuild. So, specifically we will be covering the following topics:

• Understanding of the Maven-based application and building it
• Understanding of the NodeJS-based application and building it using yarn
• Features and advantages of AWS Codebuild and the workflow of it
• Building sample Maven-based web application using a CodeBuild console
• Building a NodeJS application using the Build Specification file