<p>You can create <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&amp;tabs=yaml" rel="nofollow noreferrer">build pipeline triggers</a> to trigger your builds based on branch along with <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&amp;tabs=yaml" rel="nofollow noreferrer">path triggers</a>. In your release pipeline, you can set <a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops" rel="nofollow noreferrer">triggers and filters</a> to decide which artifacts to be deployed.</p>

CC BY-SA 4.0
2019-12-27T20:50:20.277Z
Thanks for the answer Anthony. I'm currently using triggers that are configured with path and branch filters to fire off CI builds of each project. The build I'm working on now is the release at the end of a sprint, which will be triggered manually. What I'd _like_, and I'm not sure if it's possible, is to know what's changed since the last release from the previous sprint and only build those projects that have had activity.
Dzejms
CC BY-SA 4.0
2019-12-27T21:52:56.820Z
I started to look at the API documentation from the link you provided and I'm just surprised that they didn't include a URI parameter for the buildDefinitionId for a specific pipeline. Surely, MSFT didn't expect people to have a single build pipeline for an entire project in AZDO. That API call isn't helpful when there are multiple pipelines in a project. Anyways, I think you should be able to achieve this by using the Git API and using searchCriteria.fromCommitId

https://docs.microsoft.com/en-us/rest/api/azure/devops/git/commits/get%20commits?view=azure-devops-rest-5.0
Anthony Klotz
CC BY-SA 4.0
2019-12-28T01:18:46.923Z
To expand just a little more, my thought was that you would always know what the last commitId is after every sprint/release so the value of fromCommitId would be the updated every sprint/release.
Anthony Klotz
CC BY-SA 4.0
2019-12-27T17:41:50.553Z
2019-12-27T17:41:50.553Z
Anthony Klotz
<p>Say we have 6 microservices in a monorepo, each with their own CI build pipeline that is currently only building each project and running unit tests. Is there a way to identify which projects have had code changes since the previous release and only build and deploy those, leaving others untouched? I've not seen anything in the documentation examples that describe this as a possibility but I'm hoping that with all of the conditional and scripting abilities in YAML and possibly templates, never used them, that I could achieve this. </p>

<p>One way forward without this would be to manually comment out the services that I know had no changes in the YAML and commit that, then build from the updated definition. This is open to human error so I'd like to increase the level of automation.</p>

<p><a href="https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get%20changes%20between%20builds?view=azure-devops-rest-5.1" rel="nofollow noreferrer">Builds - Get Changes Between Builds</a>
Something like this looks interesting but I'm not sure how I'd integrate it with YAML</p>

<p>The goal of all of this is to only version stamp and deploy what has changed. I may be missing some core DevOps concepts here and am happy to read more if you'll guide me.</p>

<continuous-integration><azure-devops><continuous-deployment><azure-pipelines>
Azure DevOps - Conditionally Build and Deploy
Dzejms
# Azure DevOps - Conditionally Build and Deploy

(Asked by: username_0 on 2019-12-27)

Say we have 6 microservices in a monorepo, each with their own CI build pipeline that is currently only building each project and running unit tests. Is there a way to identify which projects have had code changes since the previous release and only build and deploy those, leaving others untouched? I've not seen anything in the documentation examples that describe this as a possibility but I'm hoping that with all of the conditional and scripting abilities in YAML and possibly templates, never used them, that I could achieve this.

One way forward without this would be to manually comment out the services that I know had no changes in the YAML and commit that, then build from the updated definition. This is open to human error so I'd like to increase the level of automation.

[Builds - Get Changes Between Builds](https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/get%20changes%20between%20builds?view=azure-devops-rest-5.1)
Something like this looks interesting but I'm not sure how I'd integrate it with YAML

The goal of all of this is to only version stamp and deploy what has changed. I may be missing some core DevOps concepts here and am happy to read more if you'll guide me.

**Tags:** continuous-integration, azure-devops, continuous-deployment, azure-pipelines


---

## 1 answers

### Answer by username_1 on 2019-12-27. Score: 2

You can create [build pipeline triggers](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml) to trigger your builds based on branch along with [path triggers](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml). In your release pipeline, you can set [triggers and filters](https://docs.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops) to decide which artifacts to be deployed.

> **Comments:**
> **username_0**: Thanks for the answer Anthony. I'm currently using triggers that are configured with path and branch filters to fire off CI builds of each project. The build I'm working on now is the release at the end of a sprint, which will be triggered manually. What I'd _like_, and I'm not sure if it's possible, is to know what's changed since the last release from the previous sprint and only build those projects that have had activity.  
> **username_1**: I started to look at the API documentation from the link you provided and I'm just surprised that they didn't include a URI parameter for the buildDefinitionId for a specific pipeline. Surely, MSFT didn't expect people to have a single build pipeline for an entire project in AZDO. That API call isn't helpful when there are multiple pipelines in a project. Anyways, I think you should be able to achieve this by using the Git API and using searchCriteria.fromCommitId  https://docs.microsoft.com/en-us/rest/api/azure/devops/git/commits/get%20commits?view=azure-devops-rest-5.0  
> **username_1**: To expand just a little more, my thought was that you would always know what the last commitId is after every sprint/release so the value of fromCommitId would be the updated every sprint/release.  

---

