Condividi tramite

Creare un pacchetto di grafici in Azure Artifacts

  • Articolo

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

Quando si rilascia un pacchetto, è fondamentale assicurarsi che tutte le dipendenze di tale pacchetto siano disponibili nel feed usandole da un'origine upstream. Dopo aver utilizzato un pacchetto da un'origine upstream, una copia viene salvata nel feed. In questo modo, anche se l'origine upstream diventa inaccessibile, la copia continuerà a essere disponibile sia per l'utente che per i consumer del feed.

Come costruire il set di pacchetti disponibili in upstream

Poiché i feed di Azure Artifacts possono avere altri feed come upstream, esiste un potenziale per la creazione di cicli di origini upstream, dove feed A upstreams to feed B, che upstreams to feed C e infine feed C upstreams back to feed A.As Azure Artifacts can have other feed as upstreams, there's potential for creating upstreams to feed A, which upstreams to feed C, and endly, feed C upstreams back to feed A. Un ciclo di questo tipo, se non gestito correttamente, potrebbe causare problemi con le richieste di pacchetto, creando un ciclo infinito in cui un utente richiede un pacchetto dal feed A, quindi richieste A da B, richieste B da C e infine richieste C a A, formando un ciclo.

Le origini upstream sono progettate per evitare situazioni di questo tipo. Quando un feed cerca un pacchetto dalle origini upstream, riceve i pacchetti nella vista configurata per l'origine upstream. Ciò significa che l'esecuzione di query sul feed A non attiva una query transitiva per il feed C (A -> B -> C) perché le visualizzazioni sono di sola lettura. Di conseguenza, il feed A avrà accesso a tutti i pacchetti da C che sono stati precedentemente salvati in B da un utente, ma non il set completo di pacchetti disponibili in C.

In questo modo la responsabilità del feed B è garantire che i pacchetti locali rappresentino un grafico completo delle dipendenze. In questo modo, gli utenti che usano il pacchetto B tramite un'origine upstream da un altro feed possono risolvere correttamente il grafico e installare il pacchetto B desiderato senza riscontrare problemi.

Esempio: costruire il set di pacchetti disponibili

Si considerino tre feed: Fabrikam, Contoso e AdventureWorks. In questa illustrazione verranno esaminati i pacchetti disponibili nel feed Fabrikam durante l'introduzione delle origini upstream.

Inizialmente Fabrikam non dispone di origini upstream, consentendo agli utenti connessi a Fabrikam di installare solo le versioni 1.0.0 e 2.0.0 del pacchetto Widgets. Analogamente, Contoso non dispone di origini upstream, limitando gli utenti connessi a Contoso per installare solo le versioni 1.0.0 e 3.0.0 del pacchetto Gizmos. Lo stesso vale per il feed AdventureWorks, in cui gli utenti connessi possono installare solo le versioni 1.0.0 e 2.0.0 del pacchetto Gadgets o versione 1.0.0 del pacchetto Things.

Figura che mostra tre feed diversi senza origini upstream.

Si esaminerà ora lo scenario in cui Contoso aggiunge AdventureWorks come origine upstream. Quando un utente è connesso a Contoso, ottiene l'accesso a un'ampia gamma di pacchetti. Possono installare qualsiasi versione di Gizmos, Gadget o Cose. Ad esempio, se l'utente installa Gadgets@2.0.0, questa versione specifica del pacchetto viene salvata in Contoso con un collegamento a AdventureWorks.

Illustrazione di Contoso che aggiunge AdventureWorks come origine upstream.

Si consideri ora una situazione in cui il feed Fabrikam aggiunge Contoso come origine upstream. Un utente connesso a Fabrikam può installare qualsiasi versione di Widget, qualsiasi versione di Gizmos, ma SOLO versioni SALVATE di Gadget (2.0.0).

Figura di Fabrikam che aggiunge Contoso come origine upstream.

L'utente non sarà in grado di installare la versione 1.0.0 di Gadget o qualsiasi versione di Things, perché tali versioni del pacchetto non sono state salvate in Contoso da un utente Contoso.

Illustrazione dei pacchetti disponibili per gli utenti di Fabrikam.