2

I have multiple projects in the same folder, each of them creates a microservice. Each has a separate build and release pipeline. Currently each project is configured so to trigger when code is committed in its own sub folder. I am currently in the process of adding some common code which is used in some of the projects. I would like for a microservice to build and deploy if it uses a library that is being changes.

What is the best way to achieve this?

Ideally, I imagine something like this: Build task which triggers on root directory -> Use MsBuild to determine if a project needs to build, by checking its dependencies -> Build/Abort.

Is this possible?

user1038502
  • 767
  • 1
  • 9
  • 21
  • There's no way to set this up in AzDO where your only the services that depend on the changed library code will trigger without doing some distasteful setup and following some equally distasteful conventions. Making a build trigger on another build is easy. Fondling it to only do work when a change is made to a specific project or folder, is yucky! Are you wanting your shared code to be in the same repository? – Josh Gust Feb 12 '19 at 22:12

1 Answers1

0

If you want to share code in source form and you are using .NET Framework projects, the best (but not optimal) approach that I found is to have the projects in the same folder and put the shared code in a subfolder that you include in both projects. To put shared code in a folder outside the root folder of a project is even worse.

The best approach (IMO) is to share code in compiled (Dll) form (rather than in source form): you can create a DLL with the shared code, package it in a NuGet package, and publish the NuGet package in some internal NuGet repository (for example, you can use the Artifacts feature of Azure DevOps as NuGet repository for your organization). The projects that require the shared code do it through NuGet references. The advantages is that the shared code in Dll/NuGet form can be versioned (not all projects must be updated at the same time for incompatible changes), it can use its own CI pipeline with unit tests, it can use its CD pipeline to publish to the Artifacts repository, etc.

I switched from the former approach to the latter. Much cleaner IMO.

Carlos Quintero
  • 4,300
  • 1
  • 11
  • 18
  • Thanks for you answer, but it does not fully address my question. If going with nuget (I prefer not to, as I dont want to publish when ever I do a change in a common lib), I still have the problem of dependency managment. How do I then trigger a build in a module which uses the nuget without manually setting up the dependencies in devOps? I would like to use ms build to find the dependencies for me. – user1038502 Feb 12 '19 at 18:18
  • Using NuGet you can trigger automatically the build pipeline for the NuGet project (to test that it compiles, to pass code analysis and automated tests) but to launch manually its release pipeline (to publish to the internal NuGet repository). So you publish only when you want. Once the new NuGet package is published to the repository, projects referencing it get a notification in the Updates section of the "Manage NuGet Packages for Solution" window. If a project decides to update its NuGet dependency, it modifies its .csproj file, which would trigger its build pipeline when committed. – Carlos Quintero Feb 12 '19 at 21:30