Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
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 en amont. Une fois que vous utilisez un package à partir d’une source en amont, une copie est enregistrée dans votre flux. Cela garantit que même si la source en amont devient inaccessible, votre copie continuera d’être disponible pour vous et vos consommateurs de flux.
Comment les sources construisent l’ensemble des paquets disponibles
Comme les flux Azure Artifacts peuvent avoir d'autres flux en amont, il est possible de créer des cycles de sources en amont, où le flux A a pour source en amont le flux B, qui a pour source en amont le flux C, et finalement, le flux C a pour source en amont le flux A. Un tel cycle, s’il n’est pas géré correctement, peut entraîner des problèmes avec les demandes de paquet, créant une boucle infinie où un utilisateur demande un paquet à partir du flux A, puis A effectue une demande vers B, B fait une demande vers C, et enfin, C fait une demande retour vers 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 en amont, il reçoit les packages dans la vue configurée pour cette source en 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 un graphique de dépendance complet. Ainsi, les utilisateurs qui consomment le package B via une source en amont à partir d’un autre flux peuvent résoudre 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 pour le flux Fabrikam lors de l’introduction de sources en amont.
Initialement, Fabrikam n’a pas de sources en 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 en 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 en 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 où le flux Fabrikam ajoute Contoso en tant que source en 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.
