Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
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. Questo garantisce che, anche se l'origine upstream diventa inaccessibile, la copia continuerà a essere disponibile sia per l'utente che per i consumatori del feed.
Come costruire il set di pacchetti disponibili in upstream
Poiché i feed di Azure Artifacts possono avere altri feed come upstream, esiste la possibilità di creare cicli di origini upstream, in cui il feed A è upstream rispetto al feed B, che è a sua volta upstream rispetto al feed C e infine, il feed C è upstream rispetto al 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 il feed A richiede al feed B, il feed B richiede al feed C e infine, il feed C richiede nuovamente al feed 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, esamineremo i pacchetti disponibili nel feed Fabrikam mentre introduciamo le sorgenti a monte.
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.
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.
Consideriamo 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).
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.
