Git Branching Model
- Branching strategy
- Development
- Pre-release
- Release
- Post-release/Hotfixes
- Branch naming
- QA strategy?
- Q&A
Agenda
Branching Strategy
Main branches
- master for production releases
- develop for development. develop branch will progress ahead with new development features
Development & Feature branches
- Feature branches will be where developers will develop features.
- They will be forked out from develop branch.
- Once dev tested and unit tested, they will be merged back to develop branch
- Naming convention will be based on JIRA ticket/story ID. eg. AIR-1234
3. code review
Preparing for Release
- RLS branch will be forked out of develop branch when you know that features to release are ready.
- RLS branch will be handed over to QA for tests
- Once QA passes, it will be merged to master for release
QA
Fixes on the Release branch
- QA finds issues while doing tests on RLS branch
- Small issues can be fixed directly on RLS branch
- If something critical, then fork out a branch from RLS. Fix the issue, create a PR and merge it.
Post QA pass, the RLS branch will be merged back to develop so that it has the changes for future development and releases
Staging
- Once RLS branch is merged to master, it will auto generate a RLS tag eg. v1.0.0
- QA can deploy this tag to staging and proceed with stage testing.
Production Release
Once stage testing passed the same tag can be used for production release.
Hotfix/Post Production
- Create a hotfix branch directly from master
- Fix the issue
- Create a PR and merge with master. This will be a patch release
- So label the PR with patch
- Example Tag generated will be v1.1.2
- Once tag is generated, QA will follow same process like staging
merged back to develop
Github CI and Releases
Lumi Github project has CI actions set up for
- Run test suites and create production builds for verification
- Auto Releases + Tag creation
When a PR is merged with master, a RLS/Tag will be created.
To define a release use the correct label in the PR
- patch - to make a patch release. eg hotfixes. Backward compatible bug fixes vx.x.1
- minor - for a minor release. Backward compatible new features vx.1.0
- major - for a major release. Changes that break backward compatibility v1.0.0
- norelease - for those merges that do not need a release. eg. config changes etc
CI pipeline for Lumi
Github Labels for Release
References
Git branching model
By Joseph K
