Sdílet prostřednictvím


Grafy balíčků v Azure Artifacts

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Při vydávání balíčku je důležité zajistit, aby všechny závislosti tohoto balíčku byly dostupné ve vašem informačním kanálu tím, že je spotřebovávají z nadřazeného zdroje. Jakmile balíček z nadřazeného zdroje spotřebujete, uloží se kopie do informačního kanálu. Tím zajistíte, že i když bude nadřazený zdroj nepřístupný, bude vaše kopie dál dostupná pro uživatele informačního kanálu i vy.

Jak upstreamy sestavují sadu dostupných balíčků

Protože informační kanály Azure Artifacts můžou mít další informační kanály jako upstreamy, existuje potenciál pro vytváření cyklů upstreamových zdrojů, kde kanálY A odsílají upstreamy do kanálu B, které upstreamy do kanálu C a nakonec do kanálu A odsílají upstreamy jazyka C. Takový cyklus, pokud není spravován správně, by mohl vést k problémům s požadavky na balíčky, vytvoření nekonečné smyčky, kdy uživatel požaduje balíček z informačního kanálu A, pak žádosti od B, pak žádosti B z C a nakonec žádosti C zpět na A, které tvoří smyčku.

Upstreamové zdroje jsou navržené tak, aby těmto situacím zabránily. Když informační kanál vyhledá balíček z nadřazených zdrojů, obdrží balíčky v zobrazení nakonfigurované pro tento nadřazený zdroj. To znamená, že dotazování informačního kanálu A neaktivuje tranzitivní dotaz pro podávání C (A –> B –> C), protože zobrazení jsou jen pro čtení. V důsledku toho bude mít informační kanál A přístup ke všem balíčkům z jazyka C , které uživatel dříve uložil do B , ale ne k úplné sadě balíčků dostupných v jazyce C.

To nese odpovědnost za informační kanál B , aby se zajistilo, že místní balíčky představují kompletní graf závislostí. Uživatelé, kteří využívají balíček B prostřednictvím nadřazeného zdroje z jiného kanálu, tak můžou graf úspěšně vyřešit a nainstalovat požadovaný balíček B bez problémů.

Příklad: Vytvoření sady dostupných balíčků

Představme si tři informační kanály: Fabrikam, Contoso a AdventureWorks. Na tomto obrázku prozkoumáme dostupné balíčky informačního kanálu Fabrikam při zavádění upstreamových zdrojů.

Fabrikam zpočátku nemá žádné nadřazené zdroje, což uživatelům připojeným k Fabrikam umožňuje instalovat pouze verze 1.0.0 a 2.0.0 balíčku Widgets. Podobně contoso nemá žádné upstreamové zdroje a omezuje uživatele připojené ke společnosti Contoso jenom na instalaci verzí 1.0.0 a 3.0.0 balíčku Gizmos. Totéž platí pro informační kanál AdventureWorks, kde připojení uživatelé mohou instalovat pouze verze 1.0.0 a 2.0.0 balíčku Miniaplikace nebo verze 1.0.0 balíčku Things.

Obrázek znázorňující tři různé informační kanály bez nadřazených zdrojů

Teď se podíváme na scénář, ve kterém Contoso přidá AdventureWorks jako nadřazený zdroj. Když je uživatel připojený ke společnosti Contoso, získá přístup k širšímu rozsahu balíčků. Mohou nainstalovat libovolnou verzi Gizmos, Gadgets nebo Things. Pokud například uživatel nainstaluje Gadgets@2.0.0, uloží se tato konkrétní verze balíčku do společnosti Contoso s odkazem zpět na AdventureWorks.

Obrázek contoso, který přidává AdventureWorks jako nadřazený zdroj

Teď se podíváme na situaci, kdy informační kanál Fabrikam přidá Contoso jako nadřazený zdroj. Uživatel připojený k Fabrikam může nainstalovat libovolnou verzi widgetů, libovolnou verzi Gizmos, ale POUZE ULOŽENÉ verze Miniaplikace (2.0.0).

Obrázek společnosti Fabrikam, který přidá společnost Contoso jako nadřazený zdroj

Uživatel nebude moct nainstalovat miniaplikace verze 1.0.0 ani žádnou verzi věcí, protože tyto verze balíčků nebyly uloženy do společnosti Contoso uživatelem Společnosti Contoso.

Obrázek balíčků dostupných uživatelům Fabrikam