Branching Strategy - DTS-STN/sc-digital-centre GitHub Wiki

Overview

Our branching strategy consists of two constant (non-deleteable, protected) branches, main, and dev. And also consists of two dynamic (multiple of the same kinds are possible) branches, *feature, and *hotfix. This only differs slightly from the DC Branching Strategy to reduce merging overhead maintenance, remain more up-to-date with production code, and be closer to a standard trunk-based development pattern.

The branches

release*

The Release* branch will track a release to production and any changes made to it along the way of that release existing. Release branches will be created from main branch, once all features for a release are ready and merged in main; bug fixes can still be made against this branch once created, before released to production. There will be multiple release branches as we have multiple releases. A new release branch is not needed for bug fixes or hotfix patches. The naming convention for these branches should be release-#; '#' will typically reference the major version being released, sometimes the minor, and sometimes a 'beta' or 'alpha' flag in addition to a number.

main

Main branch will hold code that is ready for production, but not yet in production.

dev

The Dev branch is to bring together features, or partial features that are ready for some level of testing. The primary purpose of this branch will be to test integrations with other systems and other internal coded features for regression issues.

The dev branch should merge to main at the end of every sprint.

*Feature

These branches should follow a naming convention of ADO#-description. They are to build and test features independently of other development. They should only be merged to dev.

*Hot-Fix

These branches should follow a naming convention of HF-ADO#-description. These are to make a fix to a production build that must be deployed as-soon-as-possible. These should only be merged to the release* branch that needs the fix and into main only if the fix is also needed there. They should not contain any new features. They should be as minimal as possible to fix the issue and avoid breaking changes for dependencies as much as possible.

Generally used as a method to patch for security.

If merged to main, main should then be merged to dev. This is the only instance main should merge to dev. release* should never be merged into any other branch.

Visual Representation

Update diagram in confluence https://confluence.dts-stn.com/display/DD/SCH+Branching+Strategy