Azure DevOps : 1 solution, plusieurs projets CI/CD

Je viens de commencer à configurer Azure DevOps avec CI/CD. Ce n’est peut-être pas possible mais j’espère trouver des réponses.

J’ai une solution avec 6 projets :

  • Projet Web Api (référence les projets Infrastructure, Repositories et Models)

  • Projet Website (appelle l’API Web pour les données et référence les projets Infrastructure, Repositories et Models)

  • Projet Node.js (appelle uniquement l’API Web pour les données)

  • Projet Infrastructure (partagé par Web Api et Website)

  • Projet Repositories (partagé par Web Api et Website)

  • Projet Models (partagé par Web Api et Website)

Avant de commencer à chercher comment publier les projets Web Api, Website et Node.js vers leur propre Azure App Service dans les définitions CI/CD :

Est-il possible de configurer le système pour que seuls certains projets soient déployés ? Par exemple : seul le projet Node.js est publié, ou seuls Web Api et Website sont publiés mais pas Node.js.

Ou dois-je garder les choses dans des solutions séparées ?

Si je les garde dans des solutions séparées, comment cela affecte-t-il les projets partagés (Infrastructure, Repo et Models) en ce qui concerne le contrôle de source (Git) ? Si j’ajoute du code aux Models et Repo dans la solution Web Api, dois-je commiter ces changements dans le dépôt Git de Web Api ? Comment cela affecte-t-il les autres projets qui référencent les mêmes projets Models et Repo ? Est-ce là que les sous-modules Git entrent en jeu ?

Mise à jour 1 (08/03/2019)

Il semble que je puisse faire fonctionner cela dans une seule solution en utilisant les Filtres de chemin (https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops). Je suis toujours intéressé par tout retour supplémentaire.


Source : Stack Overflow.)

En espérant que cela aide d’autres personnes :

J’ai résolu cela en utilisant les Filtres de chemin sur la définition de Build et cela fonctionne parfaitement. J’ai créé 1 définition de build par projet qui doit être hébergé quelque part (dans mon exemple, j’ai 3 définitions de Build : Web Api, Website, Node.js).

Avec le bon chemin vers le projet dans le Filtre de chemin, seuls les Builds appropriés se déclenchent, et les projets non modifiés ne déclenchent pas de build. Chaque build a sa propre release qui déploie ensuite l’application spécifiée vers sa propre destination.