GIT Branching And Code Management - AI4Bharat/Shoonya GitHub Wiki

Overview

This document explains the code management strategy for the Shoonya project. Git branching, release tagging, code checkin and general maintenance of the Shoonya source code.

Getting Started

Source code for Shoonya can be found here. Shoonya follows the standard feature-master type of branching strategy for code maintenance. The releases happen through the master branch via release tags.

Feature branches

A set of branches owned by individual developers, in order to work on specific tasks. These branches are forked out of the master branch and they eventually feed into the same master branch once the code for that particular use case is developed and tested. These branches can either be deleted right after merge to master or can be retained to be reused for other use cases.

Feature branches can ONLY be deployed in the ‘Dev’ environment. ‘Dev’ environment is a dedicated VM for the developers to test their code. Once the code is dev-tested, the same has to be merged to the ‘develop’ branch which further feeds into the ‘master’ branch.

Develop branch

‘Develop’ branch is a mirror branch to the master branch. This branch is a dedicated branch for QA/UAT testing, all feature branches must feed into this branch before the use-case is sent for QA testing and at times UAT if needed. This branch will also act as a backup branch in case there’s something wrong with the master branch.

Develop branch can ONLY be deployed to the ‘QA’ environment. This is a dedicated environment for the QAs to perform unit, regression and smoke testing of the features and the App as a whole. This environment can also be used for UAT purposes. Once there’s a QA signoff on the features, this will directly feed into master.

Master branch

The main branch from which all releases happen. All features once dev-tested and QA-tested will feed into master via the develop branch. The master branch is from where the code is deployed to Production. Every release to production from the master branch will be tagged with the specific version of that release. In case of production issues, we can fallback to any of the previous stable releases.

Hotfix branches

These branches are temporary branches which are forked out directly from the ‘master’ branch and will feed back into the ‘master’ only. These are for special cases when there’s a production bug to be resolved and the ‘develop’ branch is at the (n+m)th commit and master at (n)th commit.

These branches will act as temporary mirror branches for the master branch and can be tested on the QA env, once tested and merged back to master these branches have to be deleted. After the merge, the develop will have to be rebased with master, the features will have to be rebased with the develop branch and the commits will flow upstream only after a rebase is successfully completed on all the forks. Apart from the feature branches, individual devs will also own these branches.

Code checkin

Code checkin to feature can be done by anyone, there’s no need for a review as such. These branches are mainly for the devs to test their code. The use case developed in this branch will have to be dev-tested on the ‘Dev’ environment before a merge request to the ‘develop’ branch is raised.

Code checkin to the ‘develop’ branch should only happen after a ‘Peer Review’. Merge to ‘develop’ will only happen once the code is dev-tested on the ‘Dev’ environment. It should be noted that a merge to ‘develop’ should ensure that the code quality is upto the mark, all the standards are followed and such that it doesn’t break anything that is already merged to the ‘develop’ branch by other devs. QA testing must happen on this branch deployed in a dedicated environment for QA/UAT, any bugs reported will be fixed in the feature branch, reviewed and then merged back to the ‘develop’ branch.

QA signoff happens on this branch.

Code checking to the ‘master’ branch will only happen from the ‘develop’ branch and NO feature branches. Any merge to master branch apart from the hotfix branch MUST come from ‘develop’ branch only. Merge from ‘develop’ to ‘master’ should happen only after an extensive code review from the leads, only a select bunch of members of the team will have access to merge the code to master branch. The onus of the master branch is on the Technology leads of the team. Once the code is merged to ‘master’ a final round of regression testing must take place before the code is tagged for release.

Code checking to ‘hotfix’ branch can be done by individual devs once it is reviewed from a peer and the leads. This branch feeds into master only after a second round of review. QA must happen on the ‘hotfix’ branch before this is merged to master, the merge to master must also be released only after a regression testing is done on the fix.