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 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.

1 Answer 1


You can create build pipeline triggers to trigger your builds based on branch along with path triggers. In your release pipeline, you can set triggers and filters to decide which artifacts to be deployed.

  • 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
    Dec 27, 2019 at 20:50
  • 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 docs.microsoft.com/en-us/rest/api/azure/devops/git/commits/… Dec 27, 2019 at 21:52
  • 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. Dec 28, 2019 at 1:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.