Release Train
Purpose
Section titled “Purpose”A predictable release train reduces last-minute negotiation and lets features that miss the cut move safely to the next release.
Nexa context
Section titled “Nexa context”Nexa may use a two-week or monthly cadence depending on product maturity. The important control is a declared cut time and readiness criteria, not a particular interval.
Standard
Section titled “Standard”-
MUST: Publish the release calendar and cut-off time.
-
MUST: Cut the release branch from a known green develop commit.
-
MUST: Record the intended platform version and included service versions.
-
MUST: Stop adding features to the release after the cut.
-
MUST: Allow only release-blocking fixes, documentation, and controlled configuration changes during hardening.
-
SHOULD: Hold a brief readiness review before the cut.
-
SHOULD: Use labels or milestones to identify candidate scope.
-
SHOULD: Treat missed scope as next-train work rather than extending the release indefinitely.
Working model
Section titled “Working model”At cut time, the release owner creates release/<version> from develop. The branch pipeline publishes release-tagged images. Argo CD Image Updater deploys those images to the Test environment. QA starts regression against a stable composition.
Evidence of compliance
Section titled “Evidence of compliance”Compliance is demonstrated through repository configuration, protected-branch settings, CI results, and review records. Teams should be able to show the evidence without reconstructing it manually.
Common failure modes
Section titled “Common failure modes”Cutting from a red build, continuing feature merges into release, and changing the release content without recording it make regression evidence invalid.
Maturity path
Section titled “Maturity path”The initial standard favors consistency and auditable automation. Exceptions and advanced controls are introduced only after the baseline is adopted across repositories.