Developers agree that source code should be kept under version control. Distributed version controls such as Git have been widely accepted as state-of-the-art tools. However, as mentioned earlier, besides application source code, there are more assets to track.

The motivation behind infrastructure as code is to keep all artifacts needed to ship the application in one central place. All changes made to the application, configuration, or environment are represented as code and checked in to the repository. Infrastructure as code leverages reproduciblity and automation. Taking this approach further also includes the definition of Continuous Delivery pipelines as code. The Pipeline as code section will cover this approach with the widely used Jenkins server as an example.

As we have seen in the previous chapter, the first principle of 12-factor applications is in fact to keep all files and artifacts needed to build and run the application in one repository.

The first step of the Continuous Delivery pipeline is to check out a specific commit from the version control repository. Teams that use distributed version control systems need to synchronize the desired state to a centralized repository. The Continuous Integration server takes the state of a specific commit in history to start the build process.

The reason behind taking a specific commit version rather than just the latest state is to enable reproducibility. Rebuilding the same build version can only reliably result in the same outcome if the build is based on a specific commit. This is only possible if the build originated from checking-in to version control with a particular commit. Check-in actions usually trigger builds from the corresponding commit version.

Checking out the state of the repository provides all sources and files necessary. The next step is to build the software artifacts.