0

During the past few days I have struggled with how to handle versioning and our branching strategy while using Azure DevOps, so I decided to find some more information regarding how Microsoft does it.. However.. the versioning-part isnt really shared anywhere from what I have seen.. but I just watched how they handle branching over at this video: Git patterns and anti-patterns for successful developers

However.. the part I dont quite get is.. its quite common to have your verison of your product configured as variables in your yaml. So for instance, during development you might have the following variables setup: variables: Major:1 Minor:1 Patch:0 Now lets say that we release version 1.1 and create our release-branch according to the above "relase flow" git stratgey.. we would once the release branch is created "bump" the version in our master-branch to for instance: variables: Major:1 Minor:2 Patch:0 Now.. all new code thats branched of master would end up with version 1.2.0.. however.. if we suddenly need to hotfix our production code, the release flow branching stratgey mentioned in the video would branch of master for our bugfix, this would give us a branch which has version 1.2.(1), but the minor and major we actually are trying to "patch" is 1.1... so as suggested by the video, if we now PR our bugfix into master and our release-branch, we would also not just patch our prodiction code with the bugfix, we would bring it up to a new minor-version.. which I would argue is not a prefered way of versioning the code, since the "logical" verison for our new bugfixed production-code would be 1.1.1 Any ideas of how this is solved?

Inx51
  • 1,911
  • 3
  • 24
  • 44

2 Answers2

1

The way I understand it in the release flow org site, if you cut a release branch to correspond with what is in production, your maintenance work (i.e. hotfixes/patches) happen on the release/1.1.0 branch. You then apply the same fix to mainline (e.g. master). See the following diagram:

enter image description here

Furthermore, if you want to avoid full branch merges to propagate fixes to mainline and other release branches, git cherry-pick is your friend. Just cherry-pick the commits into another hotfix off of mainline or another release branch and make any adjustments needed to get it working with that version of the code.

Cheers!

Dharman
  • 30,962
  • 25
  • 85
  • 135
czifro
  • 784
  • 7
  • 24
0

Azure DevOps and Release flow, hot to handle versioning when hotfixing?

If the minor and major we actually are trying to "patch" is 1.1 and you do not want to patch production code with the bugfix branch, we could try to merge the master branch to the hotfix after completing the development work, give the version 1.2.1.

After completing the above PR, we could merge the hotfix branch to the master, then we went back to our previous scene:

enter image description here

Now, we could forget the hotfix branch and continue to develop and release on the master branch.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135