Planning a Release
Before anything gets tagged or deployed, the PO decides whether to release, what version it should be, and whether the component is actually ready.
Release Decision Process
-
Are there more stories being worked on in the sprint?
-
Are the changes non-releaseable (configuration tweaks, documentation updates, etc.)
-
Are there bug fixes or another team waiting on the changes?
As a PO, you may wish to let changes sit on main for a while before cutting a release. Some reasons for keeping changes on main are there are multiple stories in a current sprint on the same component, or that recent changes to the component are non-code changes such as documentation updates. We try to release often, to prevent the service from becoming out of date with important vulnerability updates to the base image, ngss-maven-tiles, or mobile-framework.
If you have changes in a component that are releaseable, try to create the release at the end of the sprint or at the start of the next sprint. If there are important bug fixes or changes another team are waiting on, you will need to release sooner.
Release Version Decision Process
Ticket types affect how version of the component is incremented:
-
Stories require a new minor version
-
Tech debt can be a patch or minor version as needed
-
Bugs should be patch changes unless major rework was required
Reference https://semver.org/Semantic Versioning] for more details.
For detailed guidance on choosing the right release scope and the full versioning rules for services and libraries, see Version Components Appropriately.
|
Version increment cheat sheet
|
Release Readiness
What does readiness look like without readycheck?
Without readycheck, you will need to verify certain things. Are the version in the parent, client, DB and service modules all correct? Are the K8s/Skaffold files updated with the correct version? Is the Swagger version correct? Is the CHANGELOG.md correct - does it have an entry for the release you are getting ready to perform?