Branching Strategy for Development and Deployment Process
Objective
To define a structured branching strategy that facilitates smooth feature development, efficient bug fixes, and streamlined deployment processes. The strategy ensures:
- Parallel development of features using feature branches.
- Clear release workflows with dedicated release branches.
- Fast resolution of production issues using hot-fix branches.
- Consistent integration and testing through PR reviews and automated CI/CD pipelines.
- Effective management of code quality and stability in production through branch protection and version control.
Branch Types Overview
| Branch Type | Purpose | Source | Destination (Merge into) | When to Create | Branch Naming Standard | Approval / Sign-Off Required |
|---|---|---|---|---|---|---|
| Feature | For developing new features or enhancements. | develop | develop | For each new feature or task. | feature/<task-id>-<short-desc> | Peer Review & Manager Approval |
| Develop | Integrates completed features; used for testing & QA. | N/A | releasesbranch | Ongoing development and feature integration. | develop | QA (Testing Sign-Off) |
| Release | Prepares for production release; final bug fixes. | develop | main | When develop is stable for a new release. | releases/v<version-number> | QA (Final Testing) & Manager Sign-Off |
| Main (Master) | Holds production-ready, stable code. | N/A | N/A | For all stable releases to production. | main | Senior PR review required e.g. If the sync is for backend then senior approval required |
| Hotfix | For urgent bug fixes in production. | main | main and develop | When critical issues arise in production. | Hot-fix: hotfix/<issue-id>-<short-desc > Example: hotfix/102-fix-login-error**Release**: release/v<latest-version > Example: release/v1.0.1 (for a hotfix)Here, 1.0 is the latest release version, and 1.0.1 indicates the hotfix update. | Manager & Change Request Approval |
Tags:
- Only tags will be deployed to PRE-PROD and PROD.
- Tags serve as pointers to versions that have been deployed.
EPIC Level Branch:
- The EPIC level branch will always be baseline with the develop branch.
- Multiple developers will contribute to the EPIC level.
- Once the EPIC is ready for release, it will be merged into the develop branch.
- An EPIC branch can be merged into develop when there is a logical split of functionality (MVP) and it does not depend on other changes or disrupt existing functionality.
Best Practices for Branch Management, Pull Requests, and Deployment
| Guideline | Description |
|---|---|
| Rebasing Before Pull Requests | Developers must rebase (not just pull) their feature branch against the target branch before raising a pull request to avoid conflicts. |
| DEV and INT Deployments | Deployments to DEV and INT can include versions from EPIC branches, but changes from an earlier EPIC will be overridden if not merged into develop. |
| Rebasing EPIC Branches | Always rebase EPIC branches against develop before deployment to DEV/INT to ensure no updates from develop are missed. |
| SIT Deployments | SIT deployments will occur only from the develop branch, ensuring all features and bug fixes are fully integrated. |
| Pre-Prod and PROD Deployments | Deployments to Pre-Prod and Production will only take place after merging develop into releases |
| Thorough Peer Reviews | Pull request reviews should be comprehensive. Reviewers share responsibility for any issues that arise from the approved changes. |
To better understand the process of creating branches and managing feature deployments, we present a clear flow below.
To Start With
- The Main branch will contain the "Production version".
- The Develop branch will contain the "Upcoming Production version".
Sprint Starts:
Scenario:
Member 1, Member 2 (Group 1) are working on EPIC 1.
Member 3, Member 4 (Group 2) are working on EPIC 2.
Member 3, Member 2, Member 5 (Group 3) are working on EPIC 3.
EPIC 1 and EPIC 2 are small and will take only one sprint to complete.
EPIC 3 is larger and will take two sprints to complete.
Process:
Step 1:
- Group 1 creates a new branch from develop and names it EPIC 1.
- Group 2 creates a new branch from develop and names it EPIC 2.
- Group 3 creates a new branch from develop and names it EPIC 3.
Step 2:
- Member 1 → Creates their own version of EPIC 1.
- Member 2 → Creates their own version of EPIC 1.
- Member 3 → Creates their own version of EPIC 2.
- Member 4 → Creates their own version of EPIC 2.
- Member 3 → Creates their own version of EPIC 3.
- Member 2 → Creates their own version of EPIC 3.
- Member 4 → Creates their own version of EPIC 3.
Step 3:
- Members will make changes in their own branches.
- They will create a pull request whenever a logical checkpoint or end of day is reached.
Step 4:
- When EPIC 2 is completed, it can be merged into develop and deployed to SIT.
- When EPIC 1 is deployed to DEV/INT next time, it will be rebased from develop (as per guidelines), incorporating the changes from EPIC 1 as well.
Step 5:
- Once EPIC 1 is completed, it will be merged into develop.
Was this page helpful?