-
Notifications
You must be signed in to change notification settings - Fork 0
GitLab Flow with Release Branches
See proposed 3 DevOps pipelines that supports continuous delivery with this branching strategy
| Acronym | Definition | Description |
|---|---|---|
| MBS | Main Branch to SIT | GitHub Action workflow that deploys the main branch continuously to the SIT environment. |
| RBUPP | Release Branch - UAT, Pre-production, Production | GitHub Action workflow that manages the progressive deployment of a release branch across environments. |
| HBPP | Hotfix Branch - Pre-production, Production | GitHub Action workflow that deploys hotfix branches to Pre-Prod and Prod, safely bypassing SIT and UAT. |
| DoD | Definition of Done | The criteria that must be met before a backlog item is considered complete. |
-
Version Management: A release branch usually tracks a minor version line (for example,
release/v1.4covers1.4.0,1.4.1,1.4.2). -
Patch versions are tracked using Git tags, not new branches.
-
Branch Lifespan: Release branches are long-lived and continue receiving fixes throughout that release version’s lifecycle.
-
Upstream-First Philosophy: GitLab generally recommends fixing bugs upstream first. The approach depends on where the bug exists:
-
Upstream First (
main→ Release): Preferred approach. Fix the bug inmainfirst, then merge or cherry-pick it into the release branch if both branches share the issue. -
Release First (Release →
main): Exception approach. Use this when the bug only exists in the release branch, or whenmainhas changed too much for a clean merge. Fix it in the release branch first, then manually apply it tomain.
-
Upstream First (
- Orchestrates 4 distinct environments: SIT, UAT, Pre-Production, and Production.
- Handles target bug fixes originating from UAT/Pre-Prod testing.
- Provides a fast-track lane for Production Hotfixes.
- Seamlessly supports maintaining multiple system versions concurrently.
-
main(The continuous integration line) -
feat/*(Short-lived feature branches) -
bugfix/*(Short-lived bug mitigation branches) -
hotfix/*(Emergency production fix branches) -
release/v*.*(Stable deployment tracks)
main feat/1 feat/1 into main feat/1
gitGraph
commit id: "A"
branch feat/1
checkout feat/1
commit id: "1"
branch feat/2
checkout feat/2
commit id: "2"
checkout main
merge feat/1
merge feat/2
# 1. Start on main and ensure it is up to date
git checkout main
git pull origin main
# 2. Create and switch to the new feature branch
git checkout -b feat/1
# [Make code changes and commit them here]
# 3. Merge feature branch back into main via Pull Request
git checkout main
git pull origin main # Fetch latest remote changes
git merge feat/1 # Fast-forward or merge commit
# 4. Clean up the feature branch
git branch -d feat/1 # Delete locally
git push origin --delete feat/1 # Delete from remote repository- Each backlog item must strictly meet the DoD before merging.
- Pull Requests (PRs) should always reference their corresponding issue number (Base: main ← Compare: feat/1).
- The MBS Pipeline automatically triggers a continuous deployment to SIT on every push to main to catch integration or build failures early.
- Best Practice: Ensure automated API and UI testing suites run inside the pipeline to guard against regressions.
main release/v1.4 branch
gitGraph
commit id: "A (main)"
branch release/1.4
checkout release/1.4
commit id: "A"
# 1. Ensure your local main branch matches remote tracking
git checkout main
git pull origin main
# 2. Cut the release branch from main
git checkout -b release/v1.4
# 3. Push the release branch upstream to trigger UAT deployment
git push -u origin release/v1.4
Release Thursday - Every Thursday at 2:00 PM
- The DevOps Lead broadcasts a main branch freeze to the team.
-
mainremains frozen (verbally/chat announced, 1–2 hours maximum). No feature branch PR merges are permitted during this window. - Cut the new release/v1.4 branch directly from the frozen main baseline.
- The RBUPP Pipeline detects the new branch and automatically deploys it to the UAT environment.
- Run automated and manual smoke tests to validate the UAT deployment state.
- Once the UAT deployment is verified as successful, the DevOps Lead officially declares main open for feature merges again.
main bugfix/1 main Cherry-pick commit hash release/v1.4
gitGraph
commit id:"init"
%% --- Main (SIT lane) ---
commit id:"feature A"
commit id:"feature B"
commit id:"[SIT] baseline deploy"
%% --- Release branch (UAT / PROD lane) ---
branch release/v1.4
checkout release/v1.4
commit id:"release baseline"
commit id:"[UAT] baseline deploy"
%% --- BUGFIX FLOW ---
checkout main
branch bugfix/1
checkout bugfix/1
commit id:"fix bug"
%% Merge PR into main
checkout main
merge bugfix/1 id:"merge abc1234"
commit id:"[SIT] deploy fix"
%% Cherry-pick into release
checkout release/v1.4
commit id:"cherry-pick abc1234"
commit id:"[UAT] validate fix"
# 1. Download tracking info for all branches from the remote repository
git fetch origin
# 2. Branch from main to isolate and fix the bug
git checkout main
git checkout -b bugfix/1
# [Make code changes and commit your fix]
# 3. Open a PR to merge bugfix/1 into main
git checkout main
git merge bugfix/1
git push origin main
# 4. The MBS pipeline automatically deploys this fix to SIT for baseline validation
# 5. Extract the specific merge commit hash from main for cherry-picking
git log -1
# 6. Switch to the release branch and cherry-pick the fix
git checkout release/v1.4
git cherry-pick <insert-commit-hash-abc1234>
git push origin release/v1.4
# 7. The RBUPP Pipeline deploys the updated release branch straight to UAT
# 8. Verify and sign off on the bug fix inside the UAT environment
non-critical UAT bugs, feedbacks from UAT, Pre-Production and Production can record as backlog items and let sprint planning decide when to work on feedbacks
Reuses same existing release/v1.4 branch
-
Stakeholders/Customers conduct formal code reviews for all unique commits accumulated within the release/v1.4 branch.
-
Dev Crew manually triggers
Approvalstep in RBUPP Pipeline stage to promote the code safely into the Pre-Production environment.
If a bug is found during Pre-Production testing, follow the exact same UAT Bug Fix cherry-pick procedure outlined in Section 3, followed by a manual approval step to redeploy to Pre-Production
Reuses existing release/v1.4 branch Tag prod-v1.4.0
gitGraph
commit id: "A (main)"
branch release/1.4
checkout release/1.4
commit id: "A" tag: "prod-v1.4"
- The customer reviews the Pre-Prod state and officially declares that release/v1.4 is ready for Production deployment.
- The customer reviews and provides the manual "Approve" signature within the production stage of the RBUPP Pipeline.
- The pipeline proceeds with the deployment to Production.
- Automated Tagging: Upon a verified, successful deployment, the RBUPP Pipeline automatically creates and pushes the immutable production release tag (prod-v1.4.0).
- The pipeline must only generate the Git tag after the production deployment is entirely successful
Production Tag prod-v1.4.0 hotfix/1 branch HBPP Pipeline prod-v1.4.1 hotfix/1 back to main and release/v1.4
gitGraph
commit id:"init"
%% --- SETUP BASELINE ---
commit id:"feature A"
branch release/v1.4
checkout release/v1.4
commit id:"baseline release"
commit id:"[PROD] live release" tag:"prod-v1.4.0"
%% Main continues normal development
checkout main
commit id:"feature B"
%% --- HOTFIX FLOW ---
%% Branching from the prod tag baseline
checkout release/v1.4
branch hotfix/1
checkout hotfix/1
commit id:"fix production bug"
%% --- BACKPORTING ---
%% 1. Backport to main via PR
checkout main
merge hotfix/1 id:"PR: backport to main"
%% 2. Backport to release via PR
checkout release/v1.4
merge hotfix/1 id:"PR: backport to release"
# 1. Fetch latest tags and cut a hotfix branch directly from the active production tag
git fetch --tags
git checkout -b hotfix/1 prod-v1.4.0
# [Apply critical hotfix code changes and commit them]
# 2. Push the hotfix branch to origin
git push origin hotfix/1
# 3. Pushing triggers the HBPP Pipeline, which automatically deploys hotfix/1 to Pre-Production
# 4. The Dev Crew reviews and manually grants "Approval" inside the Pre-Prod pipeline stage
# 5. The customer validates the fix in Pre-Prod and issues a passing status
# 6. The customer provides the final manual "Approval" for the Production stage
# 7. The HBPP pipeline completes the deployment job to the live Production servers
# 8. Post-deployment, the pipeline automatically generates and pushes the updated patch tag
git tag prod-v1.4.1
git push origin prod-v1.4.1
# 9. BACKPORT STEP A: Open a PR to merge the hotfix changes permanently into main
git checkout main
git pull origin main
git merge hotfix/1
git push origin main
# 10. BACKPORT STEP B: Open a PR to merge the hotfix changes back into the active release branch
git checkout release/v1.4
git pull origin release/v1.4
git merge hotfix/1
git push origin release/v1.4
-
Agile Delivery
- Product Requirement Template
- Documenting Product Requirements
- Estimation & Sizing
- DevOps
-
Software Architecture Design
- Agent Engineering
- Logging
- Tech Stack
- Testing & Quality
- Observability & Operations