Change control and release management process

Owned by Boris Jockov
Dec 17, 2020
1 min read

Developers at Stratus Add-ons follow change control and release management processes to:

  • Record every significant change made to our software.

  • To formally control when changes to the software are released into production systems.

  • To create an audit trail of change requests, approvals, test results, etc.

  • To provide operational consistency.

  • To provide mechanism to allow effective and controlled disaster recovery.

Source Control

All software within Stratus Add-ons must be held in a backed up software control repository. At the time of writing git is used for source control, partly because every local repository is a complete history of changes.

Release Management

Within source control all products will have a “release” branch separate to the main/master branch where development branches are merged together.

Only senior engineers have permissions to write to this branch and process dictates that only merges from other branches where the commit is tested and approved may be taken over. Direct commits to the release branch are only permitted for admin changes specific to the release itself.

Repeatability

Every product release must be repeatable. Tagging must exist across all repositories that are used to create a product to indicate the state of those repositories used to create that build. Tagging binaries/libraries is not enough where we have the source, the source must also be tagged.

The reason for this is if a release has a critical bug and a patch release is to be created to solve the bug, often only exactly that bug is to be fixed in the release. Users do not want the additional uncertainty of unnecessary changes to the codebase.