Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Podczas wydawania pakietu należy upewnić się, że wszystkie zależności tego pakietu są dostępne w swoim źródle, pobierając je ze źródła nadrzędnego. Po pobraniu pakietu ze źródła nadrzędnego jego kopia zostanie zapisana w Twoim strumieniu. Gwarantuje to, że nawet jeśli źródło pierwotne stanie się niedostępne, kopia będzie nadal dostępna zarówno dla Ciebie, jak i użytkowników kanału.
Jak źródła nadrzędne konstruują zestaw dostępnych pakietów
Ponieważ kanały usługi Azure Artifacts mogą mieć inne kanały jako źródła nadrzędne, istnieje możliwość utworzenia cykli źródeł nadrzędnych, gdzie kanał A ma jako nadrzędny kanał B, który ma jako nadrzędny kanał C, a ostatecznie kanał C jako nadrzędny łączący się z powrotem do kanału A. Taki cykl, jeśli nie jest zarządzany prawidłowo, może prowadzić do problemów z żądaniami pakietów, tworząc zapętlenie, gdzie użytkownik żąda pakietu z kanału A, następnie A żąda od B, a B żąda od C, i na koniec C żąda z powrotem od 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, otrzymuje pakiety w widoku skonfigurowanym dla tych źródeł nadrzędnych. 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 jakichkolwiek pakietów z C, które zostały wcześniej zapisane przez użytkownika w usłudze B, ale nie do pełnego zestawu pakietów dostępnych w C.
Przeniesie odpowiedzialność na źródło danych B, aby upewnić się, że jej lokalne pakiety stanowią kompletny diagram 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żetów 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 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 Gadgets ani żadnej wersji Things, ponieważ te wersje pakietu nie zostały zapisane przez użytkownika Contoso w Contoso.
