Pakketgrafieken in Azure Artifacts

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Wanneer u een pakket vrijgeeft, is het van cruciaal belang dat alle afhankelijkheden van dat pakket beschikbaar zijn in uw feed door ze te gebruiken vanuit een upstream-bron. Wanneer u een pakket uit een upstream-bron gebruikt, wordt een kopie opgeslagen in uw feed. Dit zorgt ervoor dat zelfs als de upstream-bron ontoegankelijk wordt, uw kopie beschikbaar blijft voor zowel u als uw feedgebruikers.

Hoe upstreams de set beschikbare pakketten samenstellen

Omdat Azure Artifacts-feeds andere feeds kunnen hebben als upstreams, is er een potentieel voor het maken van cycli van upstreambronnen, waarbij feed A upstreams naar feed B, die upstreams voor het invoeren van C, en uiteindelijk C-upstreams doorvoert naar feed A. Een dergelijke cyclus, indien niet goed beheerd, kan leiden tot problemen met pakketaanvragen, waardoor een oneindige lus ontstaat waarbij een gebruiker een pakket aanvraagt vanuit feed A, vervolgens A-aanvragen van B, B-aanvragen van C en ten slotte C-aanvragen terug naar A, een lus vormen.

Upstream-bronnen zijn ontworpen om dergelijke situaties te voorkomen. Wanneer een feed een pakket opzoekt op basis van de upstream-bronnen, ontvangt deze de pakketten in de weergave die is geconfigureerd voor die upstream-bron. Dit betekent dat query's op feed A geen transitieve query activeren om C (A -> B -> C) in te voeren omdat weergaven alleen-lezen zijn. Als gevolg hiervan heeft feed A toegang tot alle pakketten van C die eerder zijn opgeslagen in B door een gebruiker, maar niet de volledige set pakketten die beschikbaar zijn in C.

Dit plaatst de verantwoordelijkheid voor feed B om ervoor te zorgen dat de lokale pakketten een volledige afhankelijkheidsgrafiek vertegenwoordigen. Hierdoor kunnen gebruikers die het pakket van B gebruiken via een upstream-bron uit een andere feed, de grafiek oplossen en hun gewenste B-pakket installeren zonder dat er problemen optreden.

Voorbeeld: de set beschikbare pakketten samenstellen

Laten we eens kijken naar drie feeds: Fabrikam, Contoso en AdventureWorks. In deze afbeelding bekijken we de beschikbare pakketten voor de Fabrikam-feed wanneer we upstream-bronnen introduceren.

In eerste instantie heeft Fabrikam geen upstream-bronnen, waardoor gebruikers die zijn verbonden met Fabrikam alleen versies 1.0.0 en 2.0.0 van het widgetspakket kunnen installeren. Op dezelfde manier heeft Contoso geen upstream-bronnen, waardoor gebruikers die zijn verbonden met Contoso alleen versies 1.0.0 en 3.0.0 van het Gizmos-pakket kunnen installeren. Hetzelfde geldt voor de AdventureWorks-feed, waarbij verbonden gebruikers alleen versies 1.0.0 en 2.0.0 van het Gadgets-pakket of versie 1.0.0 van het Things-pakket kunnen installeren.

Een afbeelding met drie verschillende feeds zonder upstream-bronnen.

Laten we nu het scenario verkennen waarin Contoso AdventureWorks toevoegt als een upstream-bron. Wanneer een gebruiker is verbonden met Contoso, krijgt deze toegang tot een breder scala aan pakketten. Ze kunnen elke versie van Gizmos, Gadgets of Things installeren. Als de gebruiker bijvoorbeeld Gadgets@2.0.0 installeert, wordt deze specifieke pakketversie opgeslagen in Contoso met een koppeling terug naar AdventureWorks.

Een afbeelding van Contoso die AdventureWorks toevoegt als een upstream-bron.

Laten we nu eens kijken naar een situatie waarin de Fabrikam-feed Contoso toevoegt als een upstream-bron. Een gebruiker die is verbonden met Fabrikam kan elke versie van Widgets, elke versie van Gizmos installeren, maar ALLEEN OPGESLAGEN versies van Gadgets (2.0.0).

Een afbeelding van Fabrikam die Contoso toevoegt als een upstream-bron.

De gebruiker kan versie 1.0.0 van Gadgets of een versie van Things niet installeren, omdat deze pakketversies niet door een Contoso-gebruiker zijn opgeslagen in Contoso.

Een afbeelding van pakketten die beschikbaar zijn voor Fabrikam-gebruikers.