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

https://nvie.com/posts/a-successful-git-branching-model/

Made with Slides.com