How to setup priorities between pipelines that might be triggered simultaneously on Azure DevOps pipelines

Question

I am using Azure devOps to build and deploy my application, and within that application I have a project that is being used by other related applications (let's call it project N). Thus I decided to deploy this project as a NuGet package, and consume it during the build.

Project N is likely to change often, thus I am having some trouble in defining a reliable setup that:

1. Creates the NuGet package only when there are changes in Project N and its dependencies
2. Guarantees that, if the NuGet package is to be created, as per 1), the pipeline does that before anything else

The way I have setup this so far, is to have two different pipelines, one that creates the NuGet package and deploys it (NuGet Pipeline), and another one that consumes that NuGet package and then builds and deploys the application (Main Pipeline).

The problem is, when changes happen both in files related with Project N, and in some of the remaining files of the solution, I don't know how to make a rule that says "Run NuGet Pipeline before the Main Pipeline", so for the moment I have to trust in luck for that to happen, and if not, I would have to manually trigger the Main Pipeline after the two build are finished. Because I want to be sure that the new changes introduced in the Project N do not break the Solution.

Is there an elegant way to do that? I could setup a trigger that, whenever the Pipeline NuGet finishes it would trigger the Main pipeline, but by doing it that way I would trigger the Main Pipeline twice whenever changes would be made to the Project N and to the rest of the solution.

Answer 1

It sounds like both of these pipelines are being triggered by the same source commit(s). If that's the case, you should be able to use CI trigger source path filters so that the builds only happen on commits to the relevant code.

If a developer does a single commit that is committing changes to both the main application and the package library (which would still trigger both pipelines regardless of the filter), you should consider promoting better code commit practices. Commits should be generally atomic to an appropriate context (i.e. don't commit to a stand-alone library and an app that consumes it together). Commit [and push if Git] the package changes first so they'll build and publish, then commit [and push] the main application. This will ensure that the trigger filters do what they should.

I don't know of a feature in ADO that allows you to serialize the pipeline execution order in the way you would like. As you suggested, the alternative of triggering one pipeline from another would kind of work but ultimately doesn't solve the core problem.

Alternatively, considering that "project N" changes a lot, and if it has that tight a relationship with the main project. Perhaps consuming it as a package is not appropriate. If the library is also to be consumed by other applications that have a more loose relationship, perhaps consume the dependency directly as code by the main project, but make its package publishing a part of the main application build instead of its own pipeline. (I've used this model for API applications that publish a data contracts library. The API application itself consumes the project directly as a project reference since the two are very tightly related, but others consume as a published package.)