Build metadata records all information that is gathered during the execution of the build. Especially, the specific versions of all assets should be tracked for further reference.

Builds that run from the beginning to the end don't necessarily need further information. The steps are executed in one run until either the build breaks or finishes successfully. If, however, specific steps or artifacts are required to be referenced or re-executed, further information is required.

Artifact versions are the prime example for this necessity. A WAR file and its contents corresponds to a specific version in the VCS commit history. In order to track the originating commit from a deployed application, this information needs to be tracked somewhere. The same is true for container image versions. In order to identify the origin and contents of a container, the versions need to be traceable. Database schema versions are another example. A database schema version matches a specific application version, including the previous and the next version, by following N-1 compatibility. A deployment that migrates the database schema needs to know the schema version to migrate to for the desired application version.

Build metadata is especially required when the process enables rolling out specific application versions. In general, Continuous Delivery deployments roll forward to the current repository version. However, especially with database schemas and migrations involved, the possibility of rolling the environments to an arbitrary state is a huge benefit. The process in theory works like this: take this specific application version and perform everything required in order to run it on this specific environment, no matter whether the rollout is moving forward or backward.

In order to improve traceability and reproducibility, it is advisable to track quality information about the build as well. This includes, for example, results of automated tests, manual tests, or code quality analyses. The deployment steps then are able to verify the existence of specific metadata before deploying.

There are many solutions possible for representing metadata. Some artifact repositories such as JFrog Artifactory provide the possibility of linking built artifacts with custom metadata.

Another approach is to use the CI server to track this information. This sounds like a good fit to store metadata for a build; however, depending on how the CI server is operated and set up, it is not necessarily advisable to use it to store persistent data. Old builds can be discarded and lose information.

In general, the number of points of truth, for example, to store artifacts and information, should be kept low and explicitly defined. Using artifact repositories for metadata therefore certainly makes sense.

Another, more custom solution, is to use company VCS repositories to track certain information. The big benefit of using, for example, Git to store metadata is that it provides full flexibility of the data and structure being persisted. CI servers already contain functionality to access VCS repositories, therefore no vendor-specific tooling is required. Repositories can store all kind of information that are persisted as files, such as recorded test result.

The metadata repository, however implemented, is accessed at various points in the pipeline, for example, when performing deployments.