Pipeline triggers and release branches

user_886143 0
Viewed 206

I'm migrating a TFS repo to git and looking at different branching strategies. I like the one suggested by Microsoft here https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops but am struggling a bit with the release branches.

The repository is a monorepo with a couple of different applications. When I create a new release branch I would ideally like it to trigger the pipelines to build the applications which have been changed since the last release, and not the pipelines for all the applications.

The workflow that I am trying to accomplish:

  • Develop on the main branch via feature branches and pull requests
  • Commits to the main branch will trigger builds to our QA environment with path triggers. For example, a commit to /ApplicationA will trigger the pipeline build for ApplicationA
  • When it is time to prepare for a release, create a new release branch which will trigger builds and deploy the release candidate to our UAT environment

When I create a new release branch, I want it to trigger the pipelines for all applications which have changed since latest commit to the previous release branch.

Is this possible to set up with pipeline triggers or am I better off with a long running release branch instead of a separate one for every new release?

azure-devops
1 Answers

When I create a new release branch, I want it to trigger the pipelines for all applications which have changed since latest commit to the previous release branch.

For now the behavior you want is not supported cause that feature has partly been removed for a long time. Normally Azure Devops Service won't roll back to old behavior unless there's big issue with new behavior.

You can check the part of the history about the behavior:

2018: Some members (Issue1is not the only one) posted the feature request in our User Voice forum to remove the old behavior(new branch will trigger CI build) => 2019 July: We made changes to modify the old behavior => 2019 Aug: Some members found the behavior changed.

Is this possible to set up with pipeline triggers or am I better off with a long running release branch instead of a separate one for every new release?

If your newly created branch is only used for release and not development, there is no difference between the newly created branch and the mian branch.

In this way, there is no need to create a separate one for every new release. The release pipeline record will clearly show which commit the released version comes from. We only need to check the commit record to know all the changes.

In addition, separate one for every new release will make our repo bloated and inconvenient to manage. So my personal recommendation is to use a long running release branch

user_74607770
Related