The Build Process
A Look into DevOps’ First Automative Stage
Sitting between Code and Test, two relatively straightforward and hands-on stages in the DevOps lifecycle, the Build phase has a more ambiguous nature.
“In the Build stage, we take the provided code and build it for testing purposes.”
This is HubSpot’s definition, the shortest of all the descriptions of the DevOps stages. But what does it mean to build code? And what types of tools build it?
Big Picture: Continuous Integration
A build is a process that complies and packages source code into an executable form. An application might have many dependencies required for successful implementation, so to avoid manually downloading these dependencies ourselves, a build tool is used.
When a developer pushes code to a repository, a Continuous Integration (CI) Server detects these changes. Automatically, based on the settings of the build configuration, a build agent or multiple build agents are activated. A build agent is a program that begins the build process by initiating a series of build tools to do their jobs.
Build tools are programming-language-specific scripts/frameworks used to compile and/or run tests on the pushed code. Most builds are incremental rather than full, meaning that only the parts of the source code that were changed are built. Unit or integration tests might be performed on the newly added features and the results are then sent down further steps of the DevOps pipeline, such as deploying to production, activating more tests, or relaying back to the developer in case of failing conditions.
Small Tools: Build Automation
Build Automation Tools do the following:
- Download dependencies
- Compile/interpret source code into machine code
- Package code for deployment
- Run tests
Ruby has Rake, Python has PyBuilder, Javascript has Grunt and Gulp. Java has Apache ANT, Apache Maven, and Gradle. Let’s look at Gradle as an example of how a build tool works.
The build.gradle file is the build script for a Gradle project and it looks like this:
Gradle’s build script is written in Groovy, a concise JVM language, while Apache’s build tools are written in XML. plugins, repositories, dependencies, and tests are all methods that run a block of code called a “closure” in Groovy. Inside these closures, other configuration methods are called. By adding new dependencies or plugins, the Gradle project object model (an object representing information about a project) changes. In Maven, the build script is called pom.xml after this object and has similar methods.
In Gradle, each project is made up of a collection of Tasks, or units of work needed to be done to build the project. Similarly, Maven has Phases, and ANT has Targets.
Both Gradle and Maven follow the “convention over configuration” methodology, meaning that users rely on the project structure of the build tool to compile and test code from designated source files (such as src/main/java and src/test/java). With ANT, users need to write scripts manually and specify where a source is, what tasks will be built, and how to package everything together.
For more information comparing the three build tools, click here.
A core component of practicing DevOps is that everything is continuous — continuous integration, continuous-release, continuous testing, etc. This is achieved with the help of automating tasks to push code through the DevOps development pipeline, and the Build Phase is the first stage where automation really kicks into play.
