Body: <h1>Overall problem</h1>
  
  <p>I seem to run around myself in circles with this problem. Either I'm doing something wrong, or Azure Devops simply does not support it.</p>
  
  <p>For the simplest case (we've got many products and sub-products with various forms of complexity over this problem) we have a simple 2-part system, where one is a plugin to the other. They have a common, known, stable, versioned interface and have completely seperate builds, versioning, git repo and all that.</p>
  
  <p>Where I get stuck, is where I'm trying to fit this together in a release pipeline.</p>
  
  <p>The release triggers if any of the artifacts have changes in their respective master or release branches. The trick here is then, that I'd like to fit these pieces together based on the same release branch. However being based on triggers on the artifacts, only the latest avaiable artificat will be used.</p>
  
  <h2>A few words about our release cycle</h2>
  
  <p>When we develop, we develop to master, and everything that's on master when a set date occurs, is then included in the next release (stabilization if you will) branch, and after some extensive testing and perhaps a few corrections, this is what we ship.</p>
  
  <p>If a serious flaw is then detected as it rolls out, it will be fixed on that branch, and a new version will be release from there.</p>
  
  <p>Meanwhile, development on master continues un-interrupted, and is continously released internally for various testing, which triggers the same release build.</p>
  
  <h2>The release build - what it is supposed to be doing</h2>
  
  <p>The release build takes the two artifacts, and joins them together in an installer. So it simply takes the latest from both CI builds, produces an installer, and pushes that to a central storage where we can consume it for further automation.</p>
  
  <p>The problem is the hotfixes - I would like for the release pipeline to stitch the artifacts correctly together based on the branch the artifacts are from - at the same time I would like for it to be a permanent solution, where my current workaround is to clone the release pipeline from release to release, and set it to target the newly created release/stabilization branch for both parts of the product.</p>
  
  <h2>How is it supposed to work?</h2>
  
  <p>Am I dreaming up a complex scenario here that is impossible, or should this be possible in Azure DevOps - if so, how? If not, how should this challenge be tackled instead. Other approaches to recommend when deploying software with decoupled plugins?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-08-28T16:28:15.863Z
Comments: I am not sure if I am getting your problem correctly, so we have repo1/branchA and repo2/branchA as a source for all the artifacts and we want to have all done in one go by branchA from both repos?
Comments: profesor79
Comments: CC BY-SA 4.0
Comments: 2019-08-29T11:32:36.197Z
Comments: Exactly @profesor79. The plugins are developed in their own repos, and a release pipeline attempts to pull it all together as one deployable bundle.
Comments: Johny Skovdal
Comments: CC BY-SA 4.0
Comments: 2019-09-30T12:23:47.570Z
Comments: Have an issue that is about the same. I'd like for a release to trigger on any build in project A or B. If I push to A I'd like the pipeline to use the Latest from A and master from B and if I push to B I'd like the pipeline to use the Latest from B and master from B. Currently I've only been able to fix it with a release pipeline per Project, which is basically duplicated code.
Comments: Karl Morrison
Comments: CC BY-SA 4.0
Comments: 2019-10-01T06:13:44.040Z
Comments: @KarlMorrison - did you mix up your last example with B twice? As for release with always latest, that should be possible by default. Trigger decides what artificat to use from trigger repo, but uses latest from the other repos. Which can be narrowed down to only master through setting on the release def.
Comments: Johny Skovdal
Comments: CC BY-SA 4.0
Comments: 2019-10-01T09:05:53.577Z
Comments: Ah yes I did (I used B twice by accident)! Nice catch. This "release definition", where would one find this in the UI?
Comments: Karl Morrison
Comments: CC BY-SA 4.0
Comments: 2019-10-02T14:04:21.163Z
Comments: @KarlMorrison go to release defs: https://<yourteam>.visualstudio.com/<teamproject>/_release?_a=releases&view=mine, edit, click an artifact and there you specify the version: https://ibb.co/YyVRcMK
Comments: Johny Skovdal
Tags: <azure-devops><azure-pipelines>
Title: Multi-branch release pipeline in Azure Devops for multiple artifact triggers
UserDisplayName: Johny Skovdal
ThreadText: # Multi-branch release pipeline in Azure Devops for multiple artifact triggers
  
  (Asked by: username_0 on 2019-08-27)
  
  # Overall problem
  
  I seem to run around myself in circles with this problem. Either I'm doing something wrong, or Azure Devops simply does not support it.
  
  For the simplest case (we've got many products and sub-products with various forms of complexity over this problem) we have a simple 2-part system, where one is a plugin to the other. They have a common, known, stable, versioned interface and have completely seperate builds, versioning, git repo and all that.
  
  Where I get stuck, is where I'm trying to fit this together in a release pipeline.
  
  The release triggers if any of the artifacts have changes in their respective master or release branches. The trick here is then, that I'd like to fit these pieces together based on the same release branch. However being based on triggers on the artifacts, only the latest avaiable artificat will be used.
  
  ## A few words about our release cycle
  
  When we develop, we develop to master, and everything that's on master when a set date occurs, is then included in the next release (stabilization if you will) branch, and after some extensive testing and perhaps a few corrections, this is what we ship.
  
  If a serious flaw is then detected as it rolls out, it will be fixed on that branch, and a new version will be release from there.
  
  Meanwhile, development on master continues un-interrupted, and is continously released internally for various testing, which triggers the same release build.
  
  ## The release build - what it is supposed to be doing
  
  The release build takes the two artifacts, and joins them together in an installer. So it simply takes the latest from both CI builds, produces an installer, and pushes that to a central storage where we can consume it for further automation.
  
  The problem is the hotfixes - I would like for the release pipeline to stitch the artifacts correctly together based on the branch the artifacts are from - at the same time I would like for it to be a permanent solution, where my current workaround is to clone the release pipeline from release to release, and set it to target the newly created release/stabilization branch for both parts of the product.
  
  ## How is it supposed to work?
  
  Am I dreaming up a complex scenario here that is impossible, or should this be possible in Azure DevOps - if so, how? If not, how should this challenge be tackled instead. Other approaches to recommend when deploying software with decoupled plugins?
  
  **Tags:** azure-devops, azure-pipelines
  
  > **Comments:**
  > **username_1**: I am not sure if I am getting your problem correctly, so we have repo1/branchA and repo2/branchA as a source for all the artifacts and we want to have all done in one go by branchA from both repos?  
  > **username_0**: Exactly @username_1. The plugins are developed in their own repos, and a release pipeline attempts to pull it all together as one deployable bundle.  
  > **username_2**: Have an issue that is about the same. I'd like for a release to trigger on any build in project A or B. If I push to A I'd like the pipeline to use the Latest from A and master from B and if I push to B I'd like the pipeline to use the Latest from B and master from B. Currently I've only been able to fix it with a release pipeline per Project, which is basically duplicated code.  
  > **username_0**: @username_2 - did you mix up your last example with B twice? As for release with always latest, that should be possible by default. Trigger decides what artificat to use from trigger repo, but uses latest from the other repos. Which can be narrowed down to only master through setting on the release def.  
  > **username_2**: Ah yes I did (I used B twice by accident)! Nice catch. This "release definition", where would one find this in the UI?  
  > **username_0**: @username_2 go to release defs: https://<yourteam>.visualstudio.com/<teamproject>/_release?_a=releases&view=mine, edit, click an artifact and there you specify the version: https://ibb.co/YyVRcMK  
  
  ---
  
  ## 0 answers
  
  