At JGraph we 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.
All software within JGraph 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. Even with our third-party git hosting provider providing it’s own backup, we have every single change in at least two different geographical locations. In the event of a catastrophic disaster in one location, we are able to restore the correct state of all git repositories using our local copies.
Within source control all products will have a “release” branch separate to the main/master branch where development branches are merged together.
Only the two senior release engineers have permissions to write to this branch and process dicates 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.
Every product release must be reproducible. 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.