Sdílet prostřednictvím

Zrychlení spolupráce a agilního vývoje s využitím komponent

  • Článek

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

Váš produkt je úspěšný, vaše organizace roste a je čas vertikálně navýšit kapacitu základu kódu tak, aby odpovídal tomuto úspěchu. S horizontálním navýšením kapacity na více než 2 až 3 týmy pracujícími v jediném základu kódu na jednom produktu se můžete ptát například:

  • Jak můžou moje týmy efektivně sdílet opakovaně použitelné komponenty?

  • Návody umožnit týmům funkcí rychle iterovat, aniž byste museli pracovat s ostatními týmy?

  • Návody dát svým týmům autonomii iterovat tempem, které je pro ně správné?

Týmy v libovolné fázi můžou těžit z zvážení těchto otázek. Pokud jste vytvořený tým se starším základem kódu, možná se ptáte na stejné otázky, jako jste požádáni, abyste poskytovali větší hodnotu, rychleji než kdy dřív. Bez ohledu na vaši situaci vám komponentizace může pomoct vytvořit základ kódu, který se škáluje na velikost vašeho týmu a rychlost dnešního vývoje.

V tomto článku se podíváme, jak vám binární složení prostřednictvím Azure Artifacts může pomoct spravovat a sdílet externí závislosti, opensourcový software a izolované sdílené komponenty.

Komponenty a složení

Komponentizace je proces rozdělení a uspořádání produktu do různých komponent. Většina projektů .NET už má představu o komponentách ve formě projektů v rámci řešení. Například základní web se může skládat z front-endové komponenty, komponenty pro přístup k datům a modelu/datového úložiště.

Zdrojové složení

S růstem vašeho produktu může být řešení a projektový model neefektivní. Integrace změn trvá déle a sloučení je obtížnější, sestavení se zhorší a komponenty se začnou zvětšovat z jednoho projektu na více projektů. Obecně platí, že to je bod, kdy týmy začnou rozdělovat tyto sady souvisejících projektů do samostatných řešení.

Jakmile přerostnete jedno řešení, stane se z komponentizace zajímavá otázka. Začali jsme se zdrojovým složením, kde každá komponenta odkazuje prostřednictvím odkazu na projekt v sadě Visual Studio. Zdrojové složení je možné, pokud váš zdroj žije v jedné hranici složení: jediné řešení v rámci jednoho zdrojového úložiště.

Tyto odkazy na projekty se bohužel začnou rozdělit, když je zapojeno více řešení. V tomto okamžiku, když řešení A závisí na řešení B, musí odkazovat na sestavené binární binární soubory (například knihovny DLL) vytvořené řešením B - to je binární složení.

Proto je teď potřeba tyto binární soubory sestavit a zpřístupnit řešení A, aby bylo možné úspěšně sestavit. Existuje několik způsobů, jak to udělat:

  • Můžete je zkontrolovat ve správě zdrojového kódu. V závislosti na systému správy zdrojového kódu můžou binární soubory rychle zpomalovat velikost úložiště, zpomalit časy rezervace a obecný výkon úložiště. Pokud začnete pracovat ve větvích, může několik týmů nakonec zavést stejný binární soubor v různých verzích, což vede ke složitým konfliktům při slučování.

  • Alternativně je můžete hostovat ve sdílené složce, i když tento přístup má určitá omezení. Sdílené složky nemají index pro rychlé vyhledávání a neposkytují ochranu před přepsáním verze v budoucnu.

Složení balíčku

Balíčky řeší řadu problémů odkazujících na binární soubory. Místo toho, abyste je zkontrolovali do zdroje, můžete mít řešení B vytvořit binární soubory jako balíčky NuGet, které pak může využívat jiné řešení A. Pokud jsou řešení A a řešení B zachovány jako samostatné komponenty, kde jsou souběžné změny v A a B vzácné, složení balíčků je skvělý způsob, jak spravovat závislost A na B. Složení balíčků umožňuje iterovat B podle vlastního tempa, zatímco A je zdarma získat aktualizace z B, když plán A umožňuje, a umožňuje více týmům iterovat a aktualizovat řešení B, aniž by to ovlivnilo řešení A (nebo jiná řešení C nebo D).

Složení balíčků ale přináší svou vlastní sadu problémů. Zatím jsme prozkoumali jednoduchý příklad. Škálování složení balíčku až do velikosti velkého základu kódu (například Windows nebo Bing) může způsobit řadu problémů:

  • Pochopení dopadu zásadních změn v komponentě nízké v grafu závislostí je velmi náročné.

  • Závislosti kosočtverce se můžou stát významným překážkou flexibility. V závislosti kosočtverec závisí komponenty B a C na sdílené komponentě A, zatímco komponenta D závisí na B i C. Když komponenta A zavádí novou verzi s zásadními změnami, pokud B aktualizuje novou verzi, ale jazyk C ne, nemůže aktualizace B převzít bez zavedení konfliktu závislostí. V tomto jednoduchém příkladu může být konverzace s jazykem C všechna potřebná k vyřešení konfliktu. V komplexním grafu se však kosočtverce můžou rychle stát nespolehitelným.

  • Pokud je potřeba změny použít u dvou komponent, které se skládají pomocí balíčků, je cyklus iterace vývojáře výrazně pomalejší. Pokud je komponenta A aktualizovaná, vyžaduje opětovné sestavení, opětovné zabalení a opětovné publikování. Následně musí komponenta B aktualizovat na nedávno publikovanou verzi, aby ověřila změnu provedenou v komponentě A. Použití zdrojového složení, které umožňuje souběžné sestavování komponent A a B, bude vývojářům konzistentně poskytovat rychlejší cyklus iterace.

Co byste měli použít

Obecně jsme viděli, že velké týmy jsou nejúspěšnější, když používají kombinaci strategií složení. Pokud chcete zjistit, co je pro základ kódu vhodné, začněte tím, že namapujeme graf závislostí produktu a začnete seskupit komponenty do sad souvisejících komponent.

Můžete mít například kolekci komponent tvořících vaši architekturu a další sadu komponent tvořících vaši uživatelskou službu. Pak pro každou skupinu souvisejících komponent položte tyto otázky:

  • Můžu očekávat časté kontroly napříč sadami, které jsem vytvořil(a) pro své týmy?

  • Zodpovídá jeden tým za celou sadu?

  • U jedné sady existuje četnost sdílených vydaných verzí?

V naší zkušenosti jsme zjistili, že použití zdrojového složení je nejúčinnější pro související projekty zpracovávané jedním týmem nebo skupinou souvisejících týmů. Naopak binární složení je výhodné pro opensourcový software, externí závislosti (komponenty ze vzdálených nebo izolovaných týmů) a nezávislé sdílené komponenty.