Branch/Merge diagram showing a bug fix propagating
from the old release branch to the ongoing development
branch via another release branch.

Fundamentals

When people start writing new code, nobody thinks of release management. It's a non-problem. You're happy if it works at all. You have a small team, everyone understands the whole code base. You might be using a simple version control system, but that's it. Version 1.0 comes out, is a blazing success and you grow, add features, add more developers, build a company .... and hit a wall. Your merges are hell, builds break, bugs you thought fixed re-appear. You're afraid of refactoring, because you have lost the overview of the dependencies, and meanwhile your product people are pressing for shiny new features - to be delivered tomorrow...

The purpose of these pages is to define language and techniques to help you avoid hitting the wall. The impact on velocity is minimal if the techniques are applied with good judgement and common sense. The main objective is to create an awareness of likely growth patterns, so that you can be ready for them and plan for them.

The central concept here is The Artifact:

Artifacts come in various shapes and sizes:

C++ Libraries
Python Modules
Java jar or war files
Packages
Tarballs
Machine Images
Clusters of Machine Images

The parts that make up an artifact are:

Lineage

The origin of the artifact, i.e. the exact revisions of the source files involved in constructing the artifact are known.

Dependencies

Artifacts can and will depend on other artifacts. Sometimes we may even construct "virtual" artifacts that actually do not have any payload at all, but just exist as a node in a dependency tree.

The example above demonstrates how one could represent a complete production site via artifacts:

The cluster artifact can be simply a list of hosts and references to the images on those hosts
A host can be represented by an image (e.g. ISO file, AMI for EC2 or similar), or be a tarball representing the configurable portion of that host, or simply the name of an "image package" with the right dependencies to pull in all the required packages, if a packaging system is used.
Applications can generally be split into two portions: the application code and the configuration. The point of splitting is that some applications can be reused for different purposes in different contexts: one obvious example of this is apache.

State

For the purposes of release management, artifacts will be assigned a state. In the simplest model, three states do fine:

Development: The artifact is not ready for release, or is built from source that hasn't been merged up to with the latest already released revisions.
Release Candidate: The artifact has been built from source that has been merged up with the latest already released revisions, and will be released if it passes QA
Production: The artifact is used in production. The source code revisions used to build the artifact are in the mainline branch.

The artifact state is not only dependent on the revisions used to build it, but also on the state of the other artifacts it depends on. Depending on a Development artifact will preclude the state from being anything else but Development.