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:
- Build process – takes a source code and produces a labeled build [package].
- Deployment process – takes a build and deploys it to a specified environment.
- 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.
- 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.
- We’d like to control who can trigger certain processes (like deployment to production).
- We’d like to control who have influence on the artifacts used to produce the build.
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
- Define consistent build artifacts labeling mechanism
- Define how to build official (i.e. labeled) builds (release branch or some other strategy)
- Define responsible personnel and limit access to corresponding artifacts/processes
- 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)