Process notes: release management

Recently I had to spend some time to produce comments around different aspects of software development. Publishing these notes here is a good way of saving it for future use.

 

Basic definitions and requirements

Artifact – a set of files that we work with or produce. This can refer to a source code drop or to a binaries produced by building the application from this sources.

Process – a repeatable and traceable set of actions that are performed on a given artifact(s).

In scope of release management process we work with the following artifacts:

• Source code – a complete set of project source code together with required configuration files.
• Build – a labeled set of binary files that is sufficient for deployment to any environment we have.

Processes we need to have in place:

1. Build process – takes a source code and produces a labeled build [package].
2. Deployment process – takes a build and deploys it to a specified environment.

Process requirements:

1. Repeatability – we need to be able to repeat any process and be sure that for a given input it will produce exactly the same output.
2. Traceability – we need to be able to trace when a process was initiated, who initiated a process, what were the inputs and what were the outputs/results or process execution.

Security considerations:

1. We’d like to control who can trigger certain processes (like deployment to production).
2. We’d like to control who have influence on the artifacts used to produce the build.

Implementation notes

The crucial aspect of organizing release management process is a definition and labelling of artefacts. Here’s what might help us improve our process:

• Having a dedicated release branch which is used as an input for build process (helps with both repeatability and security)
• Establishing a consistent build labeling mechanism and using the same labels across all the environments we run.
  • Build label should consist of major and minor release number (might be based on sprint number)
  • Should include source control revision number in some form
  • Should be stamped on each binary we produce during the builds – usually embedded in each assembly via AssemblyVersion attribute
  • Should be surfaced somewhere on the web-site – does not necessary visible to end user, can be a hidden field or a hint
    • Simplifies support and solving technical issues
    • Helps in development and testing by making it 100% clear which version is being deployed/tested
    • Allows easy and reliable tracking of what was fixed when and where it is deployed to

Bottom-line:

1. Define consistent build artifacts labeling mechanism
2. Define how to build official (i.e. labeled) builds (release branch or some other strategy)
3. Define responsible personnel and limit access to corresponding artifacts/processes
4. Define how we ensure repeatability (the simplest and most common way is to store official builds somewhere and allowing deployment to be triggered for a given set of [build] artifacts)

HTH,
AlexS