Skip to main content
Version: 12.10.0

Branching Strategy Frontend and Backend

Backend:​

Existing release/develop will act as main branch where complete code is maintained.

alt text

  1. Starting day of the sprint - new branch named release/release_version_number should be created from release/develop branch in Bitbucket. [Ex., release/12.2.0] Action on PoD Team is responsible to create release specific branch as applicable.

  2. Developers will create feature branches from release/12.2.0 and works in respective feature branch to develop the feature in Local environment.

  3. While developing, Dev Team must ensure the JIRA ticket is tagged with appropriate release version and if there is any dependency with CMS, ensure that CMS JIRA ticket is also tagged under same release by taking confirmation from CMS Team.

Action on

PoD Lead and Team is responsible to finalize the release version. This will help developers to commit the code in release specific branches appropriately.

  1. After completion of the development with unit testing, Developers create PR from feature branch and merge the code in release/12.2.0 branch. Ensure codes are considered for PR merging is applicable for 12.2.0 release only.

Action on:

Dev team : Up on PR creation, Developers must ensure Sonar build is successful in Bitbucket/SonarQube before intimating Reviewers to approve the PR. Dev team : If any sonar build failure, it should be addressed immediately or should be discussed with PoD Leads to take any deviation approval. Up on Sonar build successful, do intimate reviewers. PoD Lead : Must ensure the PR raised against JIRA task is applicable for target release branch before approving. Must ensure sonar build status against the PR raised before approving.

  1. Tag the code from release/12.2.0 branch with “dev-” prefixed to deploy the code in DEV environment. Sanity/integration testing should be in done in this environment. Action on:: PoD Team is responsible for this activity. Also team should take care of merging code from release/develop to release specific branch as well to ensure the code sync-up.

  2. Developers must create PR from feature branch and merge the code in release/develop branch as mandatory step. Action on:: PoD Lead/Team is responsible for this activity.

  3. Tag the code with “tst-” prefixed to deploy the code in TST environment from release/develop branch only. EY QA will test the feature in TST environment before releasing to AOK. Action on:: Release Management Team is responsible for TST tagging.

  4. Based on Release Management Team confirmation, BE services will be tagged from release/develop branch for SAPW deployment. There is no change in SAPW tagging process. Action on:: Release Management Team is responsible for SAPW tagging.

  5. Bugs identified in SAPM/SAPW/PROD environment as part of v12.2.0 release, fixing should be done in release/12.2.0 branch and tag the code with “dev-”, “tst-” and SAPW deployment/testing respectively. PoD Development team must fix this issue on top of release/12.2.0 branch and tag with “tst-“ for TST environment testing. SAPW tagging shall happen from this release specific branch only. Development team must create PR from feature branch and merge the fix in release/develop branch as part of bug fixing activity.