-1

I've been doing some research for our team to migrate to a new branching strategy. Currently we are using the github flow with only master and feature branches. But since we have some trouble with hotfixes im thinking that we should migrate to the gitflow using release branches so we have a stable branch where we can do hotfixes when needed. We are using Azure Devops as our platform.

Anyway what im having trouble with so far is how should we trigger our continuous deployment pipelines when we create a new release branch?

Normally pipelines get triggered when a PR is merged and a CI build is run. However when you create a new release branch and want to deploy that to for example an Acceptance environment, how should we trigger those pipelines? Another problem is that we have multiple releaseable components in our repository. So when we create that release branch we would end up having to look up which components we changed, run manual build for them so our pipelines get triggered.

It seems to me this should be a common problem, yet i cant find much information on this, which suggests to me im missing something here. What am i missing?

Regards

Demoric
  • 296
  • 1
  • 3
  • 16
  • I see a close vote that this is an opinion-based question. That's just plain silly. This is Azure DevOps we are talking about. You can, or can't. I'm also not sure why this has gotten two down-votes. Being that a release branch in Git is not that uncommon, I'm sure other people have the same question. – Greg Burghardt Aug 13 '20 at 18:39
  • It seems like you are asking about how to structure gitflow triggers ... but there are any number of processes you could put in around the timing and structure of that. Do branches live forever? Do you cut a new one from a tag? I've setup gitflow for release different in Azure DevOps differently at several companies. So yeah, as stated I thought this could lead to some opinionated answers. We don't know your processes, so hard to give you a good answer. – Matt Aug 13 '20 at 20:21
  • 1
    If you are just asking specifically about how to trigger the release, you could just branch into a Release\ folder and setup a build trigger on Release \ *. Or you could setup a policy that matches your master on the release branch and do PR against that. It wouldn't be much different than your current process then? – Matt Aug 13 '20 at 20:22
  • Hi @Demoric. Is there any update about this ticket? Feel free to let me know if the answer could give you some help. – Kevin Lu-MSFT Aug 17 '20 at 01:00
  • 1
    Yes, turns out some of the missing pieces was that creation of a branch also can trigger a pipeline. The last missing piece was that to granularly release only some components we will create a release branch per component that we want to release. So release/componentA/release1.1 etc. This prevents us from getting a trigger on all our components which we dont want. Thanks for the help! – Demoric Aug 17 '20 at 05:36

1 Answers1

2

How should we trigger our continuous deployment pipelines when we create a new release branch?

Since the resources you use are on github, you can try the following triggers configuration in Azure Devops Build Pipeline(CI) and Release Pipeline(CD).

Build Pipeline: You could add release branch to the branch filters. Then when you create a release branch or make changes in these two branches, the Pipeline will be triggered.

enter image description here

Release Pipeline: You could add the Build as artifacts resources. And you could also add the Release branch as the continuous deployment Branch filter.

enter image description here

In this case, the build triggered by the release branch will trigger the corresponding release.

enter image description here

These settings also ensure that the changes you make in the release branch can trigger CI and CD automatically.

Note: Github branches filters are case sensitive in Azure Devops.

Kevin Lu-MSFT
  • 20,786
  • 3
  • 19
  • 28