Jak jsem “u nás” zaváděl Continuous Integration II. — Luntbuild

Tímto spotem bych rád navázal na předchozí povídání o zavádění XP techniky Continuous Integration (dále CI). Podíváme se na nástroj Luntbuild, který umožňuje uvedení CI do praxe. Luntbuild toho umí více než pouhé spouštění antovských skriptů, nabízí možnost správy a řízení jednotlivých buildů.

Instalace a ovládání

Instalace je velice jednoduchá a k provozu Luntbuildu budeme potřebovat pouze Ant a 
 servletový kontejner např. Tomcat. Suma sumárum rozbalíte distribuční balíček Luntbuildu provedete deploy webového modulu s nastavením domovského adresáře Luntbuildu. To je teoreticky vše pokud používáte CVS, ale nemusíte se bát, instalace je dobře popsána v dokumentaci. Práce s Luntbuildem probíhá přes celkem intuitivní webové rozhraní, žádné bádání v konfiguračních souborech vás nečeká.

Obrázek se nepodařilo načíst. Archivní obrázek k článku Jak jsem “u nás” zaváděl Continuous Integration II. — Luntbuild, snímek 1

↗ Medium

(velký obrázek)

Struktura Luntbuildu

Nyní si musíme něco povědět o vnitřní organizaci Luntbuildu. Základní jednotkou Luntbuildu je vlastní build, ale pozor buildy jako takové jsou organizovány do větších celků. Kdybychom to vzali opačnou cestou na začátku všeho je projekt.

Projekt

Projekt má nějaké jméno, popis a má i nějaký systém pro sdílení zdrojových souborů 
 např. CVS, Subversion, Source safe atd. Kromě výše zmíněných podporuje Luntbuild 
 některé další, více je možno nalézt na stránkách Luntbuildu. Na projektu si ještě 
 nastavíme přístup do systém pro sdílení zdrojových souborů a to je vše. V rámci 
 každého projektu si můžeme definovat několik view.

View

View umožňuje definovat základní atributy buildu. V rámci projektu pak můžeme mít neomezený 
 počet view. View obecně představuje pohled z hlediska buildu na projekt. Dejme tomu, že 
 máme projekt, který má mature verzi a verzi, která bude další řadě a na 
 které se pracuje. View nám umožňuje si nastavit základní podmínky pro každou z těchto dvou verzí např. rozdílné verzování.

Pro každé view si můžeme nastavit způsob verzování např. pro mature verzi budeme 
 verzovat (měnit) pouze v rámci čísla buildu. Dále můžeme nastavit podmínku 
 pro spuštění vlastního buildu např. buildování se provede pouze pokud se 
 v CVS změnily zdrojové soubory od posledního buildu. Nastavujeme podmínku podle, které se 
 rozlišuje úspěšný build. Dále třeba specifikovat antovský soubor a target, který se bude volat
 pro vlastní build proces.

Pokud to nevyplynulo hned na začátku, tak nyní se sluší udělat malou odbočku. Vlastní build proces zůstává na nás. V antovském skriptu si nadefinujeme task, který bude Luntbuild volat a jehož pomocí se provede buildování (kompilace, vytvoření waru apod.). Diky Antu můžeme volat i externí programy, my tak například řešíme (prosté volání batch) kompilaci Tenkých klientů, kteří jsou psaní v Delphi.

V rámci View si pak můžeme nastavit notifikaci po doběhnutí buildu např. zasláním 
 mailu nebo zprávou na instantní messenger. Nebo můžeme určit antovský task, který 
 se provolá pro doběhnutí buildu. Tento tásk může například vystavit build naweb
 nebo jej deploynout na testovací server.

Module

Pakliže jeden projekt může mít několik View, pak i view se skládají 
 z elementárních částic, kterým se říká Module. Modul představuje 
 vlastní napojení na systém pro sdílení zdrojových souborů. V případě CVs tak 
 specifikujeme CVS repository path nebo branch, ze které se budou stahovat 
 zdrojové soubory. Význam modulu se dobře ilustruje na následujícím příkladu.

Máme verzi X k této verzi nám v CVS vznikla větev, kam se posílají opravy k verzi X. Můžeme si tak definovat modul, který bude stahovat zdrojové soubory pro verzi X a zároveň modul, který stáhne všechny opravené zdrojáky. Díky tomu se nám při build nestane, že bychom zapomněli šáhnout do opravné větve. Pomocí modulu tak jemně specifikujeme vlastní pravidla pro získání zdrojových souborů.

Build scheduler

V pomyslné hierarchii stojí na úrovni modulu, v rámci view, build scheduler. Scheduler definuje vlastní spuštění build procesu. Luntbuild obsahuje několik typů, Release, Nightly, Test a Continuos Integration Scheduler. Například Nigthly scheduler 
 je defautlně nastaven tak, že pustí build každý den v 1:00. V rámci scheduleru si 
 můžeme nastavit např. build type, který určuje jestli se stáhnou pouze změněné 
 zdrojáky a nebo jestli se stáhne kompletně vše na čisto.

Umožňuje specifikovat jestli se bude notifikovat po doběhnutí buildu což např. v případě testovacího buildu nepotřebujeme. Scheduler také umožňuje nastavit strategii pro označování source repository, v případě CVS můžeme například 
 chtít po Release Scheduleru, aby po každém release buildu označil dané zdrojové 
 soubory tagem.

Luntbuild koncept

Obrázek se nepodařilo načíst. Archivní obrázek k článku Jak jsem “u nás” zaváděl Continuous Integration II. — Luntbuild, snímek 2

↗ Medium

Detail buildu

Každý build má vlastní detail, kde vidíme například čas po který běžel, můžeme si prohlídnout build log, podívat se na změny, které byly od posledního buildu a nebo si výsledný produkt buildu stáhnout. Na této úrovni můžeme build smazat a nebo přesunout v rámci jednotlivých view.

Obrázek se nepodařilo načíst. Archivní obrázek k článku Jak jsem “u nás” zaváděl Continuous Integration II. — Luntbuild, snímek 3

↗ Medium

(velký obrázek)

Právě o správě jednotlivých buildů, které mohou být mazány nebo přesouvány, ale stejně tak o možnostech Luntbuildu by se dalo psát dlouze. Bohužel tolik času nemám, ale doufám, že Vám tohle malé nakouknutí pod pokličku úžasného buildovacích nástroje pomůže při vaší práci a vůbec se nemusí jednat o využití Luntbuildu v rámci XP praktiky Continuous Integration.