čtvrtek 13. ledna 2011

Build z jedné hromady vs. releasovatelné celky

Máte velký projekt? Trvá jeho build dlouho? Hodně projektů začíná tím, že máte pár zdrojových souborů, které zbuildovat znamená pár sekund. Postupem času narůstá jejich počet a vzájemné použití. Pokud je to projekt větší, nezbytný důsledek většiny softwarového vývoje, dochází k tomu, že zdrojové soubory začínáte členit do modulů s určitou odpovědností. Pokud takový projekt chcete vybuildovat, uděláte checkout z version control systému a pustíte váš buildovací systém. Tenhle přístup má kromě pár nesporných výhod i pár nevýhod, které se mohou ukázat jako docela zásadní. V tomto článku se pokusím nastínit alternativní přístup.

Build z jedné hromady

Build z jedné hromady je to co jsem popsal výše. Tedy zjednodušeně řečenou uděláte checkout a spustíte build. Tento přísup má jeden zásadní rys, to co vybuildujete přímo odpovídá tomu, co jste získali z verzovacího systému, případně lokálně upravili. Pokud máte modul A, která používá modul B, pak jakákoliv změnu, kterou uděláte v modulu B v uvozovkách pozná i modul A.

Výhody

Změna kódu na jednom místě se projeví ve všech částech zdrojových souborů, které leží na hromadě, kterou buildujeme.

Nevýhody

Pomalejší build, kvůli změně jednoho souboru musíme buildovat i zdrojové soubory, se kterými tato změna vůbec nesouvisí. Pokud modul A používá kromě modulu B navíc i modul C, pak musíte mít zkompilovaný modul C. Přestože jste tu třídu tohoto modulu léta neměnili, musíte jeh kompilovat neustále dokola. To asi znamená, že se v tom modulu pustí i testy. Tedy další zpomalení.

Náchylné k prosakujícím chybám. Mějme náš příklad s modulem A, B a C. Pokud cokoliv změníme ve modulu B nebo C, tak tím můžeme efektivně rozbít i modul A. Pokud moduly leží v části projektu, za kterou nezodpovídáme, pak jakákoliv změna může mít vedlejší efekt, o kterém nemáme ani páru.

Releasovatelné celky

Releasovatelné celky jsou proti Buildu z jedné hromady přístupem, který je založen na tom, že vybuildované a z našeho pohledu stabilní celky našich vlastních modulů/komponent používáme v podstatě jako by se jednalo o kód třetích stran, od kterého máme jenom binárku, proti které můžeme buildovat. Tento přístup odstraňuje nevýhody Buildu z jedné hromady.

Rychlost buildu. To co je stabilní a odladěné se nebuilduje, používáme existující binárku. Navíc různé verze jedné binárky lépe umožňují předcházet prosakujícím chybám. Jestliže modul A používá modul B a nějaký aktivista se pustí do jeho úprav, pak modul A může stále používat starší verzi modulu B aniž by se ho nové úpravy dotkly.

Releasovatlné celky mají oproti Buildu z jedné hromady nevýhodu v tom, že potřebujete infrastrukturu, ve které držíte binárky vlastního kódu a také něco čím řídíte závislosti mezi moduly. V případě, že používáte Apache Maven, pak vám stačí vlastní repository, ve které budete mít vlastní artefakty (binárky z modulů). Řízení závislostí artefaktů je v Mavenu implicitní. Mimochodem to ovšem znamená, že vaše stabilní a odladěné artefakty nepoužíváte jako SNAPSHOTY, ale jako konkrétní verze.

Pokud máte Maven a váš projekt má víc modulů z nichž některé se používají jako sdílené, pak bych rozhodně doporučoval použít přístup s releasovatelnými celky. Zrychlíte tím build proces včetně testů a pomůže vám to v předcházení prosakujících chyb.