Git Source Code Management Process for Emergency Releases
Documentation Version: 1.0
Effective Date: [Insert Date]
Purpose
To define a standardized procedure for managing emergency releases in accordance with Gitflow workflow
principles, ensuring consistency, traceability, and minimal disruption to ongoing development activities.
Scope
This process applies to all software development teams utilizing the Git version control system for source
code management. It outlines the steps for handling critical defects requiring immediate resolution and
deployment to production.
This document outlines the standard Git workflow followed by the Software Development Department.
**Git Source Code Management Process for the Software Development Department**
1. **Creation of Feature Branches**
- Developers shall create feature branches from the `develop` branch, adhering to the naming
convention `features/(feature name)`.
2. **Deployment to DEV0 Environment for In-Sprint Testing**
- Upon completion of feature development, developers shall deploy the feature branch to the DEV0
environment for in-sprint testing conducted by the SVT team.
3. **Bug Resolution During In-Sprint Testing**
- If bugs are identified during in-sprint testing, developers shall address them within the respective
feature branch (`features/(feature name)`) and redeploy the updated branch to the DEV0 environment.
4. **Merging Feature Branches into Develop Branch**
- Once feature development and testing are complete, the feature branch shall be merged back into
the `develop` branch.
5. **Creation of Release Branch for QA Testing**
- For QA testing, the Tech Lead shall create a release branch from the `develop` branch. The naming
convention for release branches is `Release-X.Y.Z`, where the middle digit (`Y`) represents the bi-weekly
release number. For example, if the current production release branch is `Release-7.0.0`, the
subsequent bi-weekly release branch shall be named `Release-7.1.0`.
6. **Testing and Bug Fixing in QA2 Environment**
- Testing shall be performed on the bi-weekly release branch within the QA2 environment.
- Any necessary bug fixes shall be implemented in dedicated `bugfixes/(bug or defect number)`
branches and subsequently merged back into the active release branch.
7. **Deployment to Production Environment**
- Upon stabilization and approval of the release branch, it shall be deployed to the production
environment.
8. **Merging into Master Branch and Tagging**
- The stable release branch shall then be merged into the `master` branch.
- A tag shall be created on the `master` branch to mark the release version for tracking purposes.
9. **Merging Release Branch Back into Develop Branch**
- Finally, the release branch shall be merged back into the `develop` branch to ensure all changes are
incorporated.
**Procedural Guidelines for Git Source Code Management**
1. **Verify the Master Branch Content**
- Ensure that the `master` branch contains the current production code before initiating any hotfix
processes.
2. **Create a Hotfix Branch**
- From the `master` branch, create a new hotfix branch using the naming convention:
`hotfixes/{ALM_bug_number}`.
3. **Initiate an Emergency Release Branch**
- The Technical Lead is responsible for creating an emergency release branch from the current
production release or `master` branch.
- Name the emergency release branch following the convention: `Release-X.Y.Z`, where the rightmost
digit (`Z`) is incremented to indicate the emergency release.
- *Example*: If the current production release branch is `Release-7.0.0`, the emergency release
branch should be named `Release-7.0.1`.
4. **Merge Hotfix into Emergency Release Branch**
- After fixing the defect, developers merge the hotfix branch into the emergency release branch to
consolidate changes.
5. **Deploy to Testing Environment**
- Deploy the emergency release branch to the TRNG environment for System Verification Testing (SVT).
6. **Conduct Testing and Implement Additional Fixes**
- Perform thorough testing on the emergency release branch within the TRNG environment.
- If further bug fixes are needed, implement them in new `hotfixes/{ALM_number}` branches.
- Merge these additional hotfix branches back into the emergency release branch.
7. **Deploy to Production Environment**
- Once testing is complete and the emergency release branch is stabilized and approved, deploy it to
the production environment.
8. **Merge into Master Branch and Tag Release**
- Merge the stable emergency release branch back into the `master` branch.
- Create a tag on the `master` branch to mark the emergency release version for tracking and future
reference.
9. **Incorporate Changes Across All Relevant Branches**
- Merge the emergency release branch into the `develop` branch.
- Additionally, merge it into any other active release branches that have not yet been deployed to
production.
- This ensures that all changes are consistently integrated across all pertinent branches.
---
Maintaining a structured and consistent git workflow is crucial for efficient collaboration and seamless
deployments. By following these procedural guidelines, the development team can ensure that
emergency fixes are properly managed and integrated, minimizing potential disruptions to the
production environment.
Compliance
All developers must adhere to the naming conventions, branching strategy, and merge protocols
outlined in this document.
Any deviations from this process require prior approval from the Technical Lead or Release Manager.
Revision History
Versi Auth Changes
Date
on or Made
[Dat [Nam Initial
1.0
e] e] Document
Approved By: [Name/Title]
Signature: _________________________
Date: ______________________________
