Single Source of Truth

A typical release engineering system uses different data as inputs to invoke necessary workflows. End-of-support dates can, as an example, determine whether a pipeline for a particular product version is triggered and whether it is published publicly to all customers.

Such type of information typically includes:

• Release dates for Beta, RC, or GA releases along with end-of-support dates.
• Configuration of the product for test setup.
• Environment infrastructure setup (in our case, Terraform files)
• List of changes in each release train.
• One set of steps to run the release train.
• Upgrade path information.

As the system grows in complexity, it's generally convenient to duplicate the information in question directly in scripts instead of implementing a way to refer to the central source of information. Taking the time to do so pays dividends.

Release Engineering systems become convoluted when each script consumes different copies of the same underlying data to perform its function. Making any change to that piece of information will then need to be propagated everywhere. Not doing so will lead to disaster. Your source of one type of information in any system should come from one central place only.

We were duplicating the dependencies needed in our system in multiple places in the old version of our system. It was present in the metadata of the product but was also embedded directly in the CI build and test templates. This would lead to errors that were misleading because one had to just know to fix these.

Resolving this meant that we had to do the heavy lifting of extracting our product and grabbing the dependency information from there instead of it being passed as a parameter. Definitely not convenient, but it helped us eliminate the source of this error forever.

On top of that, having centrally located source of truth for all key data means that customers, contributors, and other stakeholders can also reliably refer to it.