Add automated release process ADR with branch/workflow diagrams and long-term-support hotfix flow [WPB-22420]#21221
Open
screendriver wants to merge 6 commits into
Open
Add automated release process ADR with branch/workflow diagrams and long-term-support hotfix flow [WPB-22420]#21221screendriver wants to merge 6 commits into
screendriver wants to merge 6 commits into
Conversation
Contributor
|
🔗 Download Full Report Artifact 🧪 Playwright Test Summary
|
…grams and long-term-support hotfix flow Establish a release process that is safe, predictable, and fully executable from GitHub without local release operations. The process ensures that quality assurance controls promotion from beta to production, production tags represent actual successful deployments, hotfixes can be propagated quickly without branch drift, and long-term-support customers receive stable, low-frequency releases with a dedicated hotfix path.
screendriver
force-pushed
the
release-process
branch
from
dce5778 to
8f9ee86
Compare
screendriver
requested review from
arjita-mitra,
e-maad,
otto-the-bot,
thisisamir98 and
zskhan
as code owners
screendriver
changed the title
zskhan
reviewed
May 7, 2026
arjita-mitra
reviewed
May 8, 2026
e-maad
reviewed
May 11, 2026
iskvortsov
reviewed
May 12, 2026
Rework the proposed release process ADR based on review feedback. - rename the ADR to focus on trunk-based automated releases - replace the dev/master model with main as the single trunk - define continuous Edge deployment from main - define automatic Beta deployment from release branches - keep Production gated by GitHub Environment approval - clarify post-deployment production tagging and beta tag lineage - replace long-term-support wording with on-premises maintenance releases - clarify hotfix, rollback, ownership, and feature flag expectations
Member
Author
|
First of all: big thank you for all the discussions, comments, and challenges on this ADR. The feedback changed the proposal quite a bit and made the process clearer. I updated the ADR based on the discussion. The proposal now moves from "automated release process with
I also renamed the ADR file to:
The previous name was too narrow because the ADR is no longer only about the quality assurance gate. It now also covers the branch model, I replaced the "long-term-support release" wording with "on-premises maintenance release". The intent is not that every Production release becomes a long-term-support line. A maintenance line is created only when a customer-managed deployment needs a stable branch for later patches. The webapp team produces the branch, artifact, and tags; customer deployment stays outside this workflow. I also clarified ownership:
The main tradeoff is that |
Clarify that beta and production tags include the full release identifier. - use YYYY-MM-DD.N-beta.M for beta tags - use YYYY-MM-DD.N-production for production tags - anchor tag families to the release branch identifier instead of deployment date"
Add serialization rules for release workflows. - allow only one beta deployment per release branch - allow newer beta runs to cancel older pre-deployment beta runs - allow only one production deployment at repository level - prevent automatic cancellation of production deployments
Clarify how feature flags behave in the trunk-based release process. - do not require feature flag removal before merging to main - allow disabled features to land on main for later Edge dogfooding - enable features for Beta and Production when they are in release scope - remove flags later after rollout and rollback-by-flag is no longer needed
markbrockhoff
approved these changes
May 20, 2026
|
iskvortsov
approved these changes
May 20, 2026
panuschek
approved these changes
May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Establish a release process that is safe, predictable, and fully executable from GitHub without local release operations. The process ensures that quality assurance controls promotion from beta to production, production tags represent actual successful deployments, hotfixes can be propagated quickly without branch drift, and long-term-support customers receive stable, low-frequency releases with a dedicated hotfix path.
What this pull request contains
docs/decision-records/0002-automated-quality-assurance-gated-release-process.mdReview request
Please read the entire ADR carefully, including:
Discussion focus
Please comment on:
dev,master,release/...,lts/...)Process
This is the discussion round.
After comments are resolved, I will freeze the ADR text and request final approvals.