Graphes de package dans Azure Artifacts
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Lors de la publication d’un package, il est essentiel de s’assurer que toutes les dépendances de ce package sont disponibles dans votre flux en les consommant à partir d’une source amont. Une fois que vous avez consommé un package à partir d’une source amont, une copie est enregistrée dans votre flux. Cela garantit que même si la source amont devient inaccessible, votre copie continuera d’être disponible pour vous et vos consommateurs de flux.
Comment amont construire l’ensemble de packages disponibles
Comme les flux Azure Artifacts peuvent avoir d’autres flux en tant que amont s, il est possible de créer des cycles de sources amont, où le flux A amont s pour alimenter B, qui amont s à alimenter C, et éventuellement, le flux C amont s de retour au flux A . Un tel cycle, s’il n’est pas géré correctement, peut entraîner des problèmes avec les demandes de package, la création d’une boucle infinie où un utilisateur demande un package à partir du flux A, puis des demandes A de B, des requêtes B de C, et enfin, des requêtes C à A, formant une boucle.
Les sources en amont sont conçues pour éviter de telles situations. Lorsqu’un flux recherche un package à partir de ses sources amont, il reçoit les packages dans la vue configurée pour cette source amont. Cela signifie que l’interrogation du flux A ne déclenche pas de requête transitive pour le flux C (A -> B -> C), car les vues sont en lecture seule. Par conséquent, le flux A aura accès à tous les packages de C précédemment enregistrés dans B par un utilisateur, mais pas à l’ensemble complet de packages disponibles en C.
Cela place la responsabilité sur le flux B de s’assurer que ses packages locaux représentent une graphe des dépendances complète. Ainsi, les utilisateurs qui consomment le package B via une source amont à partir d’un autre flux peuvent résoudre correctement le graphique et installer leur package B souhaité sans rencontrer de problèmes.
Exemple : construire l’ensemble de packages disponibles
Prenons trois flux : Fabrikam, Contoso et AdventureWorks. Dans cette illustration, nous allons examiner les packages disponibles dans le flux Fabrikam à mesure que nous introduisons amont sources.
Au départ, Fabrikam n’a pas de sources amont, ce qui permet aux utilisateurs connectés à Fabrikam d’installer uniquement les versions 1.0.0 et 2.0.0 du package Widgets. De même, Contoso n’a pas de sources amont, limitant les utilisateurs connectés à Contoso pour installer uniquement les versions 1.0.0 et 3.0.0 du package Gizmos. Cela s’applique au flux AdventureWorks, où les utilisateurs connectés ne peuvent installer que les versions 1.0.0 et 2.0.0 du package Gadgets ou la version 1.0.0 du package Things.
Examinons maintenant le scénario dans lequel Contoso ajoute AdventureWorks en tant que source amont. Lorsqu’un utilisateur est connecté à Contoso, il accède à un large éventail de packages. Ils peuvent installer n’importe quelle version de Gizmos, Gadgets ou Things. Par exemple, si l’utilisateur installe Gadgets@2.0.0, cette version de package spécifique est enregistrée dans Contoso avec un lien vers AdventureWorks.
Prenons maintenant une situation dans laquelle le flux Fabrikam ajoute Contoso en tant que source amont. Un utilisateur connecté à Fabrikam peut installer n’importe quelle version de Widgets, n’importe quelle version de Gizmos, mais uniquement les versions enregistrées de Gadgets (2.0.0).
L’utilisateur ne pourra pas installer la version 1.0.0 de Gadgets ou toute version de Things, car ces versions de package n’ont pas été enregistrées sur Contoso par un utilisateur Contoso.
