Plánování závislostí sestavení pro kanál

  • 10 min

V této lekci se dozvíte o balení kódu, abyste usnadnili sdílení. Zjistíte, proč byste měli vytvářet balíčky, druhy balíčků, které můžete vytvořit, kde můžete balíčky hostovat a jak k nim můžete přistupovat, když jsou hostované. Dozvíte se také o správě verzí balíčků.

Základy kódu se neustále zvětšují a jsou složitější. Je neobvyklé, že tým napíše veškerý kód, který aplikace používá. Místo toho tým obsahuje existující kód napsaný jinými vývojáři. V aplikaci může existovat mnoho těchto balíčků nebo závislostí. Je důležité aktivně spravovat tyto závislosti, aby je bylo možné správně udržovat a ujistit se, že splňují požadavky na zabezpečení.

Pojďme se vrátit se změnami a podívat se, jak tým dělá. Andy svolal tým, aby společně probrali potenciální změnu kódu, která by pomohla jinému týmu.

Týmová schůzka

Andy: Ahoj všem. Mluvil jsem s týmem, který pracuje na back-endovém systému pro Space Game. Mohli by použít modely, které používáme pro web v back-endové aplikaci, kterou plánují psát.

Amita: Co myslíte modely?

Andy: Jak víte, web Space Game je aplikace ASP.NET Core. Model-View-Controller (neboli MVC) používá k oddělení dat od způsobu zobrazení dat v uživatelském rozhraní. Myslela jsem, že bychom mohli vytvořit balíček, který obsahuje naše třídy modelů, aby je mohla používat libovolná aplikace.

Amita: Co přesně je cílem?

Andy: Oba naše týmy budou sdílet stejnou databázi. Hra odesílá výsledná skóre do databáze a my je načítáme a zobrazujeme v tabulce výsledků.

Amita: To dává smysl. Jak takový balíček vytvoříme?

Andy: Proto jsem s tebou chtěla chatovat. Máme několik možností a mně zajímají nápady.

Tim: Rád bych vám pomohl, ale nejdřív mám nějaké otázky. Tohle je pro mně nové a chci pochopit, jak to celé funguje.

Co je balíček?

Balíček obsahuje opakovaně použitelný kód, který mohou jiní vývojáři použít ve vlastních projektech, i když ho sami nenapsali.

Pro kompilované jazyky balíček obvykle obsahuje zkompilovaný binární kód, například .dll soubory v .NET nebo soubory třídy v Javě. U jazyků, které jsou interpretované (a nikoli kompilované), jako je JavaScript nebo Python, může balíček obsahovat zdrojový kód.

V obou případech jsou balíčky obvykle komprimované do formátu .zip nebo podobného formátu. Systémy balíčků často definují jedinečnou příponu souboru, například .nupkg nebo .jar, aby bylo použití balíčku jasné. Komprese může pomoct zkrátit dobu stahování a také vytvořit jeden soubor pro zjednodušení správy.

Balíčky také často obsahují jeden nebo více souborů, které poskytují metadata nebo informace o balíčku. Tato metadata můžou popisovat účel balíčku a uvádět licenční podmínky, kontaktní informace autora a verzi balíčku.

Proč je dobré vytvářet balíčky?

Oproti duplikování kódu má sestavování balíčků výhody.

Jedním z důvodů pro vytvoření balíčku namísto duplikování kódu je zabránit vzniku odchylek. Když je kód duplikován, může se každá kopie rychle rozbíhají, aby splňovala požadavky konkrétní aplikace. Pak je obtížné migrovat změny z jedné kopie do druhé. Jinými slovy ztratíte možnost vylepšovat kód tak, aby z toho mohli těžit všichni.

Balíčky se také seskupují podle funkčnosti do jednotlivých opakovaně použitelných komponent. V závislosti na programovacím jazyce může balíček poskytovat aplikacím přístup k určitým typům a funkcím a zároveň omezit přístup k podrobnostem implementace.

Dalším důvodem pro vytváření balíčků je zajištění jednotného způsobu sestavení a otestování funkcí balíčku. Když je kód duplikovaný, každá aplikace může tento kód sestavit a otestovat různými způsoby. Jedna sada testů může zahrnovat kontroly, ze kterých by mohla těžit jiná sada.

Jedním kompromisem je, že máte další základ kódu pro testování a údržbu s balíčkem. Při přidávání funkcí musíte být také opatrní. Obecně řečeno, balíček by měl obsahovat funkce, které využívají mnoho druhů aplikací. Například Json.NET je oblíbený balíček NuGet pro .NET, který umožňuje pracovat se soubory JSON. Json.NET je open source, takže komunita může navrhovat vylepšení a hlásit problémy.

Pokud může stejný kód využívat více aplikací, výhody výrazně převáží nevýhody. Staráte se jenom o jeden základ kódu, jednu sadu testů a jeden proces sestavení.

Jak můžu identifikovat závislosti?

Pokud je cílem přeuspořádat kód do samostatných komponent, musíte identifikovat ty části aplikace, které je možné odebrat, zabalit, aby bylo možné opakovaně používat, ukládat do centrálního umístění a používat verze. Můžete dokonce chtít nahradit vlastní kód komponentami třetích stran, které jsou opensourcové nebo které licencujete.

Existuje mnoho způsobů, jak identifikovat potenciální závislosti v základu kódu. Patří sem kontrola vzorů opětovného použití kódu a analýza architektury vašeho řešení. Tady je několik způsobů, jak identifikovat závislosti:

  • Duplicitní kód

    Pokud se některé části kódu zobrazí na několika místech, je to dobrý signál, že můžete kód znovu použít. Centralizovat tyto duplicitní části kódu a odpovídajícím způsobem je zabalit.

  • Vysoká soudržnost a nízká spojka.

    Druhým přístupem je hledat prvky kódu, které mají vysokou soudržnost mezi sebou a nízkou spojku s ostatními částmi kódu. Vysoká soudržnost v podstatě znamená zachování částí základu kódu, které spolu vzájemně souvisí, na jednom místě. Nízká spojka současně spočívá v rozdělení nesouvisejících částí základu kódu co nejvíce.

  • Individuální životní cyklus.

    Vyhledejte části kódu, které mají podobný životní cyklus, který můžete nasadit a vydávat jednotlivě. Pokud tento kód může udržovat samostatný tým, je dobré ho zabalit jako součást mimo řešení.

  • Stabilní díly.

    Některé části základu kódu můžou být stabilní a často se mění. Zkontrolujte úložiště kódu a vyhledejte kód s nízkou frekvencí změn.

  • Nezávislý kód a komponenty.

    Kdykoli jsou kód a komponenty nezávislé a nesouvisejí s ostatními částmi systému, můžete je potenciálně izolovat do samostatných závislostí.

Pomocí různých nástrojů můžete skenovat a zkoumat základ kódu. Jedná se o nástroje, které hledají duplicitní kód a vykreslují grafy závislostí řešení do nástrojů, které můžou vypočítat metriky pro párování a soudržnost.

Jaké druhy balíčků existují?

Každý programovací jazyk nebo architektura má vlastní způsob, jak sestavovat balíčky. Oblíbené systémy balíčků poskytují dokumentaci o tom, jak proces funguje.

Možná už znáte tyto oblíbené systémy balíčků:

  • NuGet: balíčky knihoven .NET
  • NPM: Balíčky javascriptových knihoven
  • Maven: balíčky knihoven Java
  • Docker: Balíčky softwaru v izolovaných jednotkách označovaných jako kontejnery

Kde se balíčky hostují?

Balíčky můžete hostovat ve vlastní síti nebo můžete použít hostující službu. Hostitelská služba se často nazývá úložiště balíčků nebo registr balíčků. Mnohé z těchto služeb poskytují bezplatné hostování opensourcových projektů.

Tady je několik oblíbených hostitelských služeb pro typy balíčků, které jsme právě popsali:

  • Galerie NuGet

    Balíčky NuGet se používají pro artefakty kódu .NET. Mezi tyto artefakty patří sestavení .NET a související soubory, nástroje a někdy metadata. NuGet definuje způsob vytváření, ukládání a využívání balíčků. Balíček NuGet je v podstatě komprimovaná struktura složek se soubory ve formátu ZIP a má příponu .nupkg .

  • NPM

    Balíček NPM se používá pro JavaScript. Balíček NPM je soubor nebo složka, která obsahuje javascriptové soubory a soubor package.json, který popisuje metadata balíčku. V případě node.js balíček obvykle obsahuje jeden nebo více modulů, které lze načíst po spotřebování balíčku.

  • Centrální úložiště Maven

    Maven se používá pro projekty založené na Javě. Každý balíček obsahuje soubor objektového modelu projektu, který popisuje metadata projektu, a je základní jednotkou pro definování balíčku a práci s ním.

  • Centrum Dockeru

    Balíčky Dockeru se nazývají image a obsahují kompletní samostatná nasazení. Image Dockeru nejčastěji představuje softwarovou komponentu, kterou lze hostovat a spouštět samostatně, bez jakýchkoli závislostí na jiných imagích. Image Dockeru jsou vrstvené a můžou záviset na jiných imagích.

Informační kanál balíčku odkazuje na server úložiště balíčku. Tento server může být na internetu nebo za bránou firewall ve vaší síti. Vlastní informační kanály NuGet můžete například hostovat pomocí hostitelských produktů, jako jsou Azure Artifacts a MyGet. Balíčky můžete také hostovat ve sdílené složce.

Když hostujete balíčky za bránou firewall, můžete zahrnout informační kanály k vlastním balíčkům. Balíčky, kterým důvěřujete v síti, můžete také ukládat do mezipaměti, když se vaše systémy nemůžou připojit k internetu.

Jaké prvky tvoří dobrou strategii správy závislostí?

Dobrá strategie správy závislostí závisí na těchto třech prvech:

  • Standardizace.

    Standardizace deklarování a řešení závislostí pomůže vašemu automatizovanému procesu vydávání verzí zůstat opakovatelný a předvídatelný.

  • Formáty a zdroje balení.

    Každá závislost by měla být zabalena pomocí příslušného formátu a uložená v centrálním umístění.

  • Správa verzí.

    Potřebujete mít přehled o změnách, ke kterým dochází v průběhu času v závislostech stejně jako u vlastního kódu. To znamená, že závislosti by měly být verze.

Kdo má přístup k balíčkům?

Mnoho informačních kanálů balíčků poskytuje neomezený přístup k balíčkům. Můžete si například stáhnout Json.NET z nuget.org, aniž byste se museli přihlašovat nebo ověřovat.

Jiné informační kanály balíčků vyžadují ověření. Přístup k informačním kanálům můžete ověřit několika způsoby. Některé druhy informačních kanálů vyžadují uživatelské jméno a heslo. Jiné informační kanály vyžadují přístupový token, což je obvykle dlouhá řada znaků, které identifikují, kdo jste, a k jakým prostředkům máte přístup. Přístupové tokeny můžete nastavit tak, aby vyprší po daném časovém období.

Jak se balíčkům přidělují verze?

Schéma vytváření verzí závisí na systému balíčků, který používáte.

Například balíčky NuGet používají sémantickou správu verzí.

Sémantická správa verzí je oblíbené schéma verzí. Má následující formát:

Hlavní.Podverze.Oprava[-přípona]

Každý z těchto parametrů znamená:

  • Nová Hlavní verze přináší zásadní změny. Aplikace obvykle potřebují aktualizovat způsob, jakým balíček používají k práci s novou hlavní verzí.
  • Nová podverze zavádí nové funkce, ale je zpětně kompatibilní s dřívějšími verzemi.
  • Nová oprava zavádí opravy chyb zpětně kompatibilní, ale ne nové funkce.
  • Část -přípona je volitelná a označuje příslušný balíček jako předběžnou verzi. Například verze 1.0.0-beta1 může balíček identifikovat jako první předběžné verze beta verze pro vydání verze 1.0.0.

Na balíček se odkazuje pomocí čísla verze.

Tady je příklad instalace balíčku pomocí PowerShellu a konkrétního čísla verze:

Install-Package Newtonsoft.Json -Version 13.0.1

Co se stane při změně balíčku?

Když odkazujete na balíček z aplikace, obvykle připnete (nebo zadáte) verzi tohoto balíčku, kterou chcete použít.

Mnoho architektur umožňuje určit povolené rozsahy verzí balíčků, které se mají nainstalovat. Některé také umožňují zadat zástupné cardy, které nazýváme plovoucí verzi.

Například v NuGetu znamená verze 1.0 první verzi, která je rovna nebo větší než 1.0. [1.0] určuje pouze instalaci verze 1.0 a nikoli novější verze.

Tady je několik dalších příkladů:

Zápis: Výběr:
(1.0,) První verze, která je větší než 1.0
[1.0,2.0] První verze, která je větší nebo rovna 1.0 a menší nebo rovna 2.0
(1.0,2.0) První verze, která je větší než 1.0 a menší než 2.0
[1.0,2.0) První verze, která je větší nebo rovna 1.0 a menší než 2.0

Když každý správce vydá novou verzi balíčku, můžete vyhodnotit, co se změnilo, a otestovat ji proti ní. Jakmile budete připraveni, můžete aktualizovat číslo verze balíčku v dané konfiguraci a odeslat změnu do kanálu buildu.

Tady je příklad, jak můžete do souboru projektu aplikace C# (.csproj) zahrnout balíček Newtonsoft.Json. Tento příklad určuje verzi 13.0.1 tohoto balíčku:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>