Tworzenie pakietów grafów w usłudze Azure Artifacts
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Podczas wydawania pakietu należy upewnić się, że wszystkie zależności tego pakietu są dostępne w kanale informacyjnym, zużywając je ze źródła nadrzędnego. Po użyciu pakietu ze źródła nadrzędnego kopia zostanie zapisana w kanale informacyjnym. Gwarantuje to, że nawet jeśli źródło nadrzędne stanie się niedostępne, kopia będzie nadal dostępna zarówno dla Ciebie, jak i użytkowników kanału informacyjnego.
Jak nadrzędne konstruuje zestaw dostępnych pakietów
Ponieważ źródła danych usługi Azure Artifacts mogą mieć inne kanały informacyjne jako nadrzędne, istnieje możliwość utworzenia cykli źródeł nadrzędnych, gdzie źródło danych A jest źródłem danych nadrzędnych B, które są nadrzędne źródła danych B, które są nadrzędne do kanału informacyjnego języka C, a w końcu do kanału informacyjnego A. Taki cykl, jeśli nie jest zarządzany prawidłowo, może prowadzić do problemów z żądaniami pakietów, tworząc nieskończoną pętlę, w której użytkownik żąda pakietu ze źródła danych A, a następnie żądania A z B, a następnie żądania B z języka C, a na koniec żądania C z powrotem do A, tworząc pętlę.
Źródła nadrzędne mają na celu zapobieganie takim sytuacjom. Gdy źródło danych wyszukuje pakiet ze źródeł nadrzędnych, odbiera pakiety w widoku skonfigurowanym dla tego nadrzędnego źródła. Oznacza to, że zapytanie dotyczące źródła danych A nie wyzwala przechodniego zapytania do źródła danych C (A -> B -> C), ponieważ widoki są tylko do odczytu. W związku z tym źródło danych A będzie mieć dostęp do wszystkich pakietów z języka C, które zostały wcześniej zapisane w usłudze B przez użytkownika, ale nie do pełnego zestawu pakietów dostępnych w języku C.
Spowoduje to umieszczenie odpowiedzialności za źródło danych B , aby upewnić się, że jego lokalne pakiety reprezentują pełny wykres zależności. Dzięki temu użytkownicy korzystający z pakietu B za pośrednictwem nadrzędnego źródła z innego źródła mogą pomyślnie rozwiązać graf i zainstalować żądany pakiet B bez napotkania problemów.
Przykład: konstruowanie zestawu dostępnych pakietów
Rozważmy trzy źródła danych: Fabrikam, Contoso i AdventureWorks. Na tej ilustracji zapoznamy się z dostępnymi pakietami w kanale informacyjnym firmy Fabrikam, wprowadzając źródła nadrzędne.
Początkowo firma Fabrikam nie ma źródeł nadrzędnych, umożliwiając użytkownikom połączonym z usługą Fabrikam instalowanie tylko wersji 1.0.0 i 2.0.0 pakietu Widgets. Podobnie firma Contoso nie ma źródeł nadrzędnych, ograniczając użytkowników połączonych z firmą Contoso do instalowania tylko wersji 1.0.0 i 3.0.0 pakietu Gizmos. To samo dotyczy kanału informacyjnego AdventureWorks, w którym połączeni użytkownicy mogą instalować tylko wersje 1.0.0 i 2.0.0 pakietu Gadżety lub wersję 1.0.0 pakietu Things.
Teraz przyjrzyjmy się scenariuszowi, w którym firma Contoso dodaje firmę AdventureWorks jako nadrzędne źródło. Gdy użytkownik jest połączony z firmą Contoso, uzyskuje dostęp do szerszego zakresu pakietów. Mogą zainstalować dowolną wersję Gizmos, Gadżety lub Rzeczy. Jeśli na przykład użytkownik zainstaluje Gadgets@2.0.0, ta określona wersja pakietu zostanie zapisana w firmie Contoso z linkiem powrotnym do bazy danych AdventureWorks.
Teraz rozważmy sytuację, w której źródło danych firmy Fabrikam dodaje firmę Contoso jako nadrzędne źródło. Użytkownik połączony z aplikacją Fabrikam może zainstalować dowolną wersję widżetów, dowolną wersję Gizmos, ale tylko zapisane wersje gadżetów (2.0.0).
Użytkownik nie będzie mógł zainstalować wersji 1.0.0 gadżetów ani żadnej wersji rzeczy, ponieważ te wersje pakietu nie zostały zapisane w firmie Contoso przez użytkownika firmy Contoso.
