Branching & Release Process

Summary

This document is for Branching Standards to be used by developers for effective source control management. This document will provide rules and guidelines with respect to Axonator’s Release process.

Environments

Axonator has a total of 3 environments:

1. QA: For QA Testing, This environment will be using the QA branch.
2. Stage: For Integration Testing, This environment will be using Stage branch.
3. Production: Live Environment, This environment will be using the Production branch.

*All branches used in above environments are locked.

Branch Name

Axonator follows branch naming format, where a prefix has to be added based on development type and source branch.

Development Scenarios

Axonator will have 3 Development scenarios

• Feature Development:  Whenever there is a completely new feature going to be developed, we have to follow these guidelines
  1. All changes for this feature should be pushed from this branch only.
  2. No other branches associated with this feature should be created and pushed to remote repositories.
  3. This branch will only be responsible for this feature, It should not contain code for any other feature, bug, enhancements. 
  4. Once development and unit testing is complete, Create a Pull Request for source branch.
  5. Once PR is approved, Squash & Merge the changes to create a single commit.
  6. All Subsequent fixes/changes should be done from the same branch, keeping above points intact.
• Bug Fixing: Whenever there is a bug fix to be done on Stage environment, we have to follow these guidelines
  1. All fixes for this bug should be pushed from this branch only.
  2. No other branches associated with this bug fix should be created and pushed to remote repositories.
  3. This branch will only be responsible for this bug fix, It should not contain code for any other feature, bug, enhancements. 
  4. Once fix and unit testing is complete, Create a Pull Request for source branch.
  5. Once PR is approved, Squash & Merge the changes to create a single commit.
  6. All Subsequent fixes/changes should be done from the same branch, keeping above points intact.
• Enhancements: Whenever there is a enhancements to be done on Production Environment , we have to follow these guidelines
  1. All changes for this enhancement should be pushed from this branch only.
  2. No other branches associated with this enhancement should be created and pushed to remote repositories.
  3. This branch will only be responsible for this enhancement, It should not contain code for any other feature, bug, enhancements. 
  4. Once enhancement and unit testing is complete, Create a Pull Request for source branch.
  5. Once PR is approved, Squash & Merge the changes to create a single commit.
  6. All Subsequent fixes/changes should be done from the same branch, keeping above points intact.

General Guideline

• You will have to do strong unit testing, Unit testing should include: API testing, front end testing, functional testing on local. Make sure all paths of the code are covered in unit testing.
• Once deployed on QA a couple of rounds of functional testing on QA. Mark tickets IN QA only after your testing.
• Don’t push local branches to origin.
• Once changes are merged on production, delete your branch from repository.
• All extra branches will be deleted from repository, if unchanged for more than 15 days.
• Refer following document for SonarQube PR Analysis .
• Add ticket ID in title of PR. #<Project Prefix>- <i/I><Item number>, Example: #SP-i30.