Branching Workflow – CI / CD Part 6

Branching Workflow – CI / CD Part 6

How to start?” … Well, I avoided answering this question a long time, until now. I found an approach which fits perfect into Azure DevOps and satisfy my CI / CD workflow.

You know, Real-Life of Microsoft Dynamics 365 Business Central is development, deployment, support, and maintenance together. Therefore all of these processes need access to the right source code.

Source Code Management (SCM)

Some basics: Most of us know “OMA” (Object Manager Advanced). Microsoft Navision developers uses OMA since a long time as SCM. It tracks and manage code changes from C/Side.

Microsoft AL introduced new tools like Visual Studio Code. Source Code is now written externally and stored in textfiles. Furthermore, development happen not longer centralized in one “database”.

Finally, the introduction of industry standard technology is the result of these development process and methodology changes.

This is one reason why git have been appeared in our tool chain and is now the standard SCM for Microsoft Dynamics 365 Business Central.

Git Workflow

First of all, you know, Developers now work with an “isolated” copy in their local sandbox. As result, the development process and source code handling is: distributed and isolated.


The project source code is shared with the team as Remote Repository and stored e.g. in Azure DevOps. Each developer work locally with a cloned copy of the Remote Repository, the Local Repository.
[see also: Distributed Git Workflows]

As a developer, I store my changes with commits in branches. My local work is synchronized by Pull and Push operations with my Remote Repository.
[see also: Git Branching or Git Synching (atlassian)]

Once I have finished my Work (Gap, Feature or Bug Fix), then I create a Pull Request to integrate my source code changes into a target branch.
[see also: Pull Requests]

Finally, an Azure DevOps Build Agents creates a new Artifact based on the integrated source code (finished work) and so on…

SCM Workflow Requirements

My basic requirements on a SCM workflow within git and Azure DevOps are therefore:

  1. Changes of Gap / Feature development are tracked in branches
  2. Artifact / Release creation is based on finished work

After the artifact is successfully created, it will be deployed into test stages (see also: Deployment Stage). Finally, the tested and approved Artifact will be released into Production.

I know, testing is a time consuming process and huge changes invoke lots of tests:
…First of all, as project manager you must align your consultants and key users. Then you need their approval to enter the next stage. If there is a problem and usually there is one then you start from the beginning…

In other words, to decrease the time to production we need fast issues correction of releases. Furthermore all of us know, when a production issues is reported, you need to fix it ASAP.

Therefore we have 2 new important requirements:

  1. Artifact creation for testing based on Release Source Code
  2. Hotfix creation based on Production Source Code

Let’s see, what we can do…

Branching Workflows

All we need is a well defined branching workflow!

Remember, it is necessary for real CI / CD within Azure DevOps and it must provide the right source code for development, testing, support, and maintenance.


At the beginning with Azure DevOps, I focused on Git-Flow. This is a very popular workflow / branching model. Here are some resources I recommend to read:

My branches with this workflow are:

  • [master] … contains production source code
  • [dev] … includes all finished gaps as Squash Merge from Pull Request
  • [feature(s)] … comprises all commits for a gap, the unfinished work
  • [release(s)] … handle source code changes and fixes during testing
  • [hotfix] … contains bug fixes for production

Releases in Gitflow are managed by branching from [dev]. Finally they will be merged into [master]. Gaps are developed in [feature] branches:

Well, initially I prefered this workflow. But however, Gitflow did not satisfy myself. Pretty soon during first projects I discovered its not handy enough for me. This workflow might have to much overhead.

Let me explain. My biggest issue was the handling of Pull Requests between [dev], [release], and [master] branches in Azure DevOps.

I needed to rebase and merge a lot during release creation. This is okay for a small Waterfall Project when you have approx. 1-3 releases in your project scope.

Secondly, [hotfix] or [release-fix] branches increase the complexity a lot:

This is not acceptable for Agile Projects. Each Sprint have a Release. This happens Weekly, Bi-Weekly or Monthly. As a result, I need to spend a lot of effort in SCM.

Furthermore, this workflow is not scalable. Another “Showstopper” appears when you have multiple production sites. Gitflow defines:

[master] branch   =   Released   =    Production Source Code.

There is only 1 [master] branch. So how can I serve 2 or more production sites?

My conclusion: There must be a better way!

Release Flow

I started searching and found this promising article:

This workflow have simplified branches:

  • [master] … includes all finished gaps as Squash Merge from Pull Requests
  • [release(s)] … contains released code for testing as well as production
  • [feature(s)] … comprises all commits of unfinished work for gaps
  • [hotfix] … similar to a feature, but contains commits of bug fixes

Yes, my first Pain-Point is gone! There is no [dev] branch and Pull Requests are only merged into [master] branch. Another benefit!

My [release] branches are never merged into another branch. They disappear when they are no longer needed:

In addition I can have as many [release] branches as I want. With this, I’m able to manage productive source code for multiple production sites.

My last critic point, was the branching complexity during bug-fixing. What happen with a [hotfix] branch?

Well, a [hotfix] is also simplified and treated like a [feature] branch:

Once I completed a fix, I create a Pull Request and merge the changes back into its source branch. My changes are “Cherry-Picked” into [release] branch.

Another way is to start from production source code in [release]:

The [hotfix] is based on the [release] branch and merged back by Pull Request. All changes are “Cherry-Picked” into [master] and other [release] branches.

Cherry Picks in Azure DevOps

A Cherry Pick starts after we have applied the [hotfix] back into e.g. [master]. Our changes are now a commit on the [master].

My workflow is:
…When I do a cherry pick, then I apply all changes from a single commit to another branch, the Target Branch…

In other words, my source is the Commit where Azure DevOps provide the “Cherry-pick” action:

After execution, Azure DevOps want to create a new branch to merge my cherry pick changes. The requested target branch will be the source branch for the merge.

Finally I need to specify the name of the new branch:

In my example, the new branch [hotfix/fix01] is created from [release/prod-2019-12-01] and contains my production source code. Only the changes from cherry pick commit [c8648eee] are applied as a new commit on [hotfix/fix01].

After all, Azure DevOps wants to create a Pull Request to apply the cherry pick commit [cdcd95c9] changes back to the target branch:


My preferred branching workflow within Azure DevOps is the now:
Release Flow.

First of all this workflow fulfill my basic requirements on distributed and isolated feature development. All finished work is integrated and stored in the [master] branch.

Moreover, I can manage the source code in unlimited [release] branches for as many production sites as I want. I can apply hotfixes and cherry picks to each of these releases as well.

And finally, maybe the best part:
[release] branches are only needed, when you have to apply a [hotfix]. A [release] branch can be created on demand. Because each commit still exists on the [master] branch.

Instead of using branches you can use Tags to mark your “release” commits … think about this 😉

What’s Next?

OK, I know – this chapter took a while. However, … I’ll try my very best and I’ll continue as fast as possible!

Open topics: “… why I use Universal Packages for my Artifacts and which insights you get from Badges …”

In the meanwhile, I want your feedback! Which branching workflow do you use and how does it satisfy your needs?

Merry Christmas and a Happy New Year!
… Happy Sharing and don’t forget #NeverStopLearning


22 thoughts on “Branching Workflow – CI / CD Part 6

  1. Hola! I’ve been following your web site for some time now and finally got the bravery to go ahead and give you a shout out from Dallas Tx! Just wanted to mention keep up the fantastic work!

  2. Hmm is anyone else encountering problems with the images on this blog loading?
    I’m trying to determine if its a problem on my end or if it’s the blog.
    Any suggestions would be greatly appreciated.

  3. I blog quite often and I truly appreciate your information. This article has really
    peaked my interest. I am going to bookmark your blog and keep checking for new details about
    once a week. I subscribed to your RSS feed as well.

  4. You actually make it seem so easy with your presentation but I find this matter to be
    really something that I think I would never understand.

    It seems too complex and very broad for me. I am looking forward for your next post, I will try to get the
    hang of it!

  5. Magnificent items from you, man. I’ve keep in mind your stuff prior to and you’re just too wonderful.
    I actually like what you have bought right here, certainly like
    what you’re saying and the best way in which you say it.
    You are making it enjoyable and you still take care of to
    stay it wise. I can not wait to learn much more from you.

    This is actually a terrific web site.

  6. Hello just wanted to give you a brief heads up and let you know a few of the images aren’t
    loading correctly. I’m not sure why but I think its
    a linking issue. I’ve tried it in two different browsers and both show the same outcome.

    1. Thx for your feedback. Can you give me a hint, which images / links aren’t correct?

  7. Have you ever considered publishing an e-book or guest authoring on other websites?

    I have a blog centered on the same topics you discuss and would love to
    have you share some stories/information. I know my readers would appreciate your work.

    If you are even remotely interested, feel free to shoot me an e-mail.

Comments are closed.

Comments are closed.