Establish and Document the Application's Software Repositories

This chapter explains how to establish and document the repositories in which an Application’s source code, configuration, and built artifacts are stored.

Why Software Repositories Matter

An Application’s repositories hold everything needed to rebuild it: its source code, its configuration, its infrastructure definitions, its build scripts, and the artifacts produced by its builds. If the enterprise does not know where these repositories are, who controls them, and which branches or versions correspond to which Releases, it cannot reliably rebuild, fix, or audit the Application.

Establish the Software Repositories

Identify each repository the Application uses, for example:

• Code Repositories for source code, scripts, and code-level documentation.

• Configuration and infrastructure repositories for configuration files and infrastructure-as-code definitions.

• Artifact repositories for built and packaged artifacts, such as binaries, packages, and container images.

For each, establish who owns it, who may read and change it, its branching and versioning approach, how Releases are tagged, and how it is backed up. Ensure that every repository is controlled by the enterprise, not held in an individual’s personal account.

For vendor-provided Applications, identify where the enterprise’s own configurations, customizations, extensions, and scripts are stored, even if the vendor’s own source code is not available.

Document and Share the Repositories

Record each repository’s location, purpose, owner, access rules, branching and tagging approach, and which branch, tag, or version corresponds to each Release, in the Build, Packaging, and Configuration section of the Application Documentation. Review the record with every Release.

Best Practice: Establish and Document the Application’s Software Repositories

It is a best practice to both establish and document the solution for where an Application’s code and artifacts live: identify every repository it uses, ensure each is enterprise-controlled, and record its owner, access rules, branching and tagging approach, and how its contents correspond to Releases.

Benefits: Knowing exactly where an Application’s code, configuration, and artifacts live, and which version matches which Release, makes it possible to rebuild any Release, fix Production quickly, and satisfy auditors. Requiring enterprise-controlled repositories prevents the loss of an Application’s source when an individual or vendor leaves.

Connections to Related IF4IT Practices and Inventories

The Systems Development Lifecycle (SDLC) Best Practices addresses configuration, baseline, and technical-data management across the lifecycle. The IT Operating Environments Best Practices addresses the use of infrastructure-as-code.