What does “build” in software development mean?

Customer centricity is of the highest priority in an agile software development approach. One way, it manifests itself is, through the continuous integration (CI) and continuous delivery (CD) of software. This makes programming iterative, meaning a developer obtains a copy of the source code from a shared repository, make changes, test them and integrate them back into the main repository. These steps which are referred to as “software build”, is a precondition for CI.

In this article, I have attempted to explain what does a “build” in software development entail. More specifically, this articles covers the following.

• Meaning of software “build”
• Build automation
• How to trigger the software build process?
• Types of build
• Build process in Java
• Build process in Python

Introduction

Put simply, software build is a process of converting the source code (i.e. human readable) into an executable program. During this process, all the relevant source code files are compiled to create binaries or executable programs which can then be released. The build process itself depends on the programming language and also the software’s target operating system.

As noted in this answer on StackExchange, the build process consists of steps which fall into two broad categories- transformation and quality assurance.

Transformation

These are the steps involved in transforming the source artifacts (code, database schema, documentation etc.) into a format which can be deployed on the target machine. This includes the following steps.

1. Fetching the code from the source code repository.
2. Compiling the code into executables (only for compiler-based languages like C++ or Java)
3. Compressing target files into archives such as JAR or ZIP (again only applicable for compiler-based languages)
4. Deploy executables to a known location for deployment.
5. Publish the results of the build (like successful compilation and unit test success) including notifying the developers.

Quality assurance

These are quality assurance related steps during the said transformation. These steps include running tests (unit, system, integration) against the compiled code.

Build automation

Given the number of steps involved in the build process and the fact that they are more or less deterministic, it’s natural to automate it. Automation offers, among others, the following benefits.

1. Higher developer productivity: By automating the drudge work, developer productivity goes up.
2. Reproducible steps: Ensures correct execution order of commands making the process reproducible.
3. Parallelization of execution: Execution of commands not dependent on each other can be parallelized as opposed to a sequential execution in case of a manual build process.
4. Enhanced transparency: All the stakeholders can be better informed thereby promoting transparency.

Build automation is a precondition for continuous integration (CI). CI necessitates the developers to integrate their changes into the shared repository several times a day. Every time a developer checks in the code, build process runs, thereby allowing teams to detect the problems early. As such, build automation is at the core of the CI pipelines.

Note the subtle difference between build automation and CI. While the automated build includes getting the source code, compiling it, packaging it and automating the tests etc., CI refers to the triggering of the build process on each and every commit.

How to trigger the software build process?

Following are the types of trigger which can be used to initiate a build process.

1. Manual build trigger: When a developer is ready with the code change, she requests a build.
2. Scheduled build trigger: Build server can be configured to trigger the build at a specific time of the day or when a specific event occurs. For example, scheduled nightly builds or builds whenever source code changes are committed in the code repository. The latter is in line with the CI best practices.

Type of build

1. Full build: Each time a build is triggered, the build server generates the complete build artifact from the source files.
2. Incremental build: As the name suggests, an incremental build takes an existing build, check what has changed in the source code and the artifacts since the last time software was built. It builds only corresponding to the files which have changed. Other files will remain unchanged and be reused from the previous build.

Needless to say, incremental build is faster and more resource efficient. However, it is less reliable than the a full build.

Build process in Java

In this section, I have explained the build process for Java applications through Maven, mainly because of my familiarity with this tool.

Maven follows a specific life cycle to deploy and distribute the applications. There are three built-in life cycles. Each of these life cycles consists of a sequence of phase.

1. default : This is the main build life cycle and is responsible for project deployment.
2. clean : This life cycle is used to clean the project and remove all files generated by the previous builds.
3. site : This is used to create project site documentation.

For the purpose of understanding the meaning of build, which is the goal of this article, it is the default life cycle in Maven which is relevant for us. It has the following phases which are basically the steps in a build process. Please note that these are copied as-is from official Maven documentation.

• validate : validate the project is correct and all necessary information is available.
• compile : compile the source code of the project.
• test : test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
• package : take the compiled code and package it in its distributable format, such as a JAR.
• verify : run any checks on results of integration tests to ensure quality criteria are met.
• install : install the package into the local repository, for use as a dependency in other projects locally.
• deploy : done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.

Build process in Python

As discussed earlier, in the case of Java (or any compiled language), building the code involves taking the raw code and everything necessary for its execution and compiling it into a format that computers can run directly. However, as Python is an interpreted language, its “build” mainly revolves around test execution rather than compilation. The term test execution can mean the following.

• Unit test
• Integration test
• Functional test
• Static analysis: Source code analysis without executing the program. It is used for finding issues such as programming errors, coding standard violations, syntax violations, security vulnerabilities. pylint and pyflakes are popular libraries for static analysis of Python programs.
• Type checking: As Python is a dynamically typed language, the Python interpreter does type checking only as the code runs. In addition, the variable type is allowed to change over its lifetime. This is in contrast to the statically typed languages (C and Java for example) where type checking is performed without running the program. In these languages, type checking is performed as the program is compiled. With static typing, variables generally are not allowed to change types, although mechanisms for casting a variable to a different type may exist. Python has tools like mypy for type checking.
• Dynamic analysis: Analysis of the properties of the running program. It typically instructs the program to examine or record some of the run-time states.

References

1. Real Python: Python type checking
2. Apache Maven Project
3. StackExchange: What does an “automated build” mean?