Catalog Changes

Making changes to a product in a single repository is relatively simple. You've a series of commits that precede a deployment. While not trivial, it is easy to figure out what changes and upon error, easy to revert and make changes to fix the problem. If the team follows a relatively standard format to write their commits, it makes it obvious to know what parts of the code is likely the culprit.

For a product that's contributed by multiple teams from different repositories and shipped out to multiple customers and deployed in various ways, it is risky to not have a standardized system to catalog all of the changes that are slated to go in any particular release. Even the simplest cases may require scrutinizing the code from multiple dependencies and repositories to find the source of the problem.  

Therefore, it is imperative to have a way for each contributing team to provide their changes along with documentation and a release note for the change. A single logical change to the product should be accompanied by its code changes, a release note, the nature of the change, products affected, and any other notes. For Tanzu Application Service, we also make a point to mark a breaking change separately.

This allows a Release Train to pick up a set of changes and nothing else in the release. Even the release team doesn't make changes to the product without the metadata required to catalog a product change.

This introduces a rigor in achieving a level of traceability for an enterprise product that's necessary in this day and age. Integrated with the version control system like Git, this provides personnel info, date and time, and particular code commits that were included. On top of that, this also allows us to generate release notes for every new product version release.

Another benefit is keeping a record of what was included in each release train for historical tracking and auditing purposes.