Version Control
Version Control records what each release actually shipped: the version of every component, the Jira items it carried, which components are compatible with which, and the deployment checklist derived from the deployment guides.
|
Each release is published as its own document in the portal’s own component,
Two files are regenerated on every publication and are not a release’s history:
Until the first release is published these files do not exist yet and the links answer 404. |
How it is produced
A draft is generated when a sprint is finalized, reviewed and corrected by the release manager in CI/CD Manager’s Version Control tab, and published from there. Publishing renders the page, commits it to the documentation portal’s repository and asks the portal to rebuild — so a freshly published release appears a few minutes later, once the site build finishes.
A component released by its own repository (the Grafana monitoring stack) is not built by CI/CD Manager: the release records the tag that repository cut. Its version row then carries a line of the artifacts that release produced: the GitHub Release, the documentation PDFs, the images it pins (shown as pull references to copy) and the source archive. An artifact that could not be found when the release was recorded is marked "not found yet". PDFs and archives are published by the repository’s CI shortly after the tag, so rebuilding the draft later checks them again.
A published release is history: it is never edited in place. A correction is made on a new entry, published in turn.
Design and rationale: SDD — Version Control Service.