Branching strategy - Hotfix/Release

(0) Share

Report

Posted on by Yuji

4,131

I need some advice on how to develop hotfix on different branches.

We have Dev, Main and Release branches and in the project, we have two releases.

When we release 1st release to the production environment - create a Release branch from Main Branch.

So now we are still developing new features for Release 2, however we need to delivery hotfixes to the current productions.

Daily work for developers, they work on Dev branch (this is for new release), once the features (consists of changesets), we merge changesets that grouped by features from Dev to Main.

But where should we development on the hotfixes? Directly point the Dev machine to map to the Release branch? Or we can still work on Dev branch, and merge the hotfixes changesets from Dev to Release?

Thanks,

I have the same question (0)

All responses (7)

Answers (2)

Suggested answer

Sukrut Parab 71,710 Moderator on at

Like (0)

Report

You should do all the fixes on dev branch and merge those from dev to main using change sets as you do . After those are verified in main its up to you if you want to merge those CS from dev to Release or Main to release .We do main to release. Dont do any check ins directly to main or release branches from dev machines . Merge CS from dev branch.

Was this reply helpful? Yes No
WillWU 22,361 on at

Like (0)

Report

Hi Yuji,

Please read the DOC about how to install application hotfixes:

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/migration-upgrade/install-metadata-hotfix-package.

you should install the hotfix to one development box, then add it to Devops to share with other developers. Then you deploy it to test and production or other environments by creating a deployable package.

Refer to this link:

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/deployment/apply-deployable-package-system

Please be conscious about this:

Make sure that the Application binary update package is applied to your dev/build environment before it is applied to your sandbox and production environment - If the application binary package is applied directly to your Tier 2+ sandbox environment but is not applied on your dev/build environment, the next time you move an AOT package from dev/build box (which does not have the same application binaries as your sandbox environment) to sandbox, some of the application binaries will be overwritten with what is in your dev/build environment. This could result in a regression of the version of your sandbox environment.

Hope this helps.

Was this reply helpful? Yes No
Suggested answer

Martin Dráb 237,880 Most Valuable Professional on at

Like (0)

Report

In your setup, you should develop hotfixes in the Release branch. Your Dev branch contains different code and therefore you may be unable to reproduce, fix and test production issues there.

Was this reply helpful? Yes No
Suggested answer

István Orosz 2,137 on at

Like (0)

Report

Directly point a DevBox to other branch then DEV has potential risks of merging changesets which are not present in DEV branch, so must be taken with extra care - only if you are totally sure of what you do.

Was this reply helpful? Yes No
Yuji 4,131 on at

Like (0)

Report

That is exactly my paint point is. I am struggling to decide whether to create a new dev branch for Hotfix or not. If yes, how to move the change-sets from one Dev (release 2) branch to the current production branch.

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

You move the changesets via the Merge functionality, the process is exactly the same than when you move changesets from Dev to Main.

Was this reply helpful? Yes No
Verified answer

István Orosz 2,137 on at

Like (0)

Report

Creating a second Dev branch does not seem good option for me, because you need to strictly distinguish these two on the same level. The changeset merge, as Nikolaos wrote, technically the same.

Was this reply helpful? Yes No