Jak jsem “u nás” zaváděl Continuous Integration

všechno začala úplně nevinná rozprava s Vlastíkem na téma build a verzování

aplikací. Ve vývojové fázi projektu jsme vystaveni problému jak pružně vytvářet
 jednotlivé verze výsledného produktu, které putují k otestování.

• Kdo bude build provádět
• Kde bude build provádět
• Z jakých zdrojových souborů (verze) build provádět
• Jak, kdy a kam se bude build dávat k testování výsledného buildu
• Jak build verzovat

Když nad tím přemýšlím, napadá mě, že je důležité si ujasnit co je to build. Build

je proces sestaveni aplikace do výsledné podoby, která je vhodná pro distribuci. V

našem případě se jednalo o serverovou část, kterou tvořil WAR (Web Archive

Resources) a část klientskou, kterou tvoří binárky tenkých klientů.

Vlastní proces buildu, se skládá z několika kroků, vytvoření odpovídající

adresářové struktury, kompilace zdrojových souborů atd. Serverovou část, která je

javovská obstaral, antovský skript. Problém byl ten, že pokud chtěl někdo vytvořit

vlastní WAR musel mít jednak stažené všechny zdrojáky z CVS a druhak musel build

pouštět lokálně, a o kompilaci tenkých klientů si mohl nechat maximálně zdát.

Další komplikací bylo automatizované testování. Ač se povedlo celkem úspěšně

zavést psaní JUnit test, byl problém s jejich aktuálností. Slovy klasika, testy

byly, ale chyběla jejich komplexní kontrola a opakované pouštění. Nezřídka kdy se

stávalo, že na spuštění testu se jaksi při změně “střev” zapomnělo.

Všechny výše uvedené problémy nejsou ničím neobvyklým, ba naopak, jedná se

přirozený proces integrace práce mnoha desítek lidí. Vývojáři neustále rozšiřují

funkčnost, opravují nahlášené chyby a mění funkčnost starou. Jak se za danou

funkčností systému překrývá práce většího množství lidí, dochází k průniku

jednotlivých odpovědností. Tomáš pracuje na části A, na části staví Roman část B a

C, na části C staví Michal a Luděk. Luděk potřebuje změnu na C, Roman udělá změnu,

která se může dotknout Michala, který sdílí C.

Výše uvedené řádky nepopisují nic než situace, které mohou nastat při integraci

práce skupiny lidí na určitém celku. Proces integrace není ničím novým a nelze se

proto divit, že se hledají cesty, jak integraci usnadnit. Jeden z přístupů k vývoji

software, který se honosí názvem XP (eXtreme Programming), zavedl nebo definoval

postup k řešení integračních problémů. XP si tuhle praktiku pojmenoval jako

Continuous Integration.

Continuous Integration

Jak si vlastně Continuous Integration popsat?

Základní definice Continuous Integration (dále CI) by mohla znít, jedná se o

automatizovaný proces integrace jednotlivých softwarových částí. Základní

předpoklad, abychom mohli vůbec něco integrovat, tvoří prostý fakt, že máme co

integrovat a to něco je uloženo na jednom společném místě. Vlastní proces integrace

probíhá v námi definovaných časových intervalech.

Jak se něco integruje?

Existuje celá řada pohledů na to co pro daný produkt či jeho části představuje

úspěšná integrace. Na úrovni zdrojových souborů je to fakt, že jsou vůbec

zkompilovatelné. Někdy stačí změnit API a nepronést do společného úložiště všechny
změny a nebo zapomenout na nějakou knihovnu apod. Úspěšnou integraci by měly

indikovat v pořádku proběhnuvší unit a smoke testy. Další kritérium mohou

poskytnout zátěžové testy a nebo nástroje pro kontrolu struktury kódu jako PMD.

Co je výsledkem integrace?

Výsledkem integrace je celek též nazývaný build. V našem případě se jedná o výsledný softwárový

produkt, který je možné podstoupit humanoidním testerům. Samozřejmě integrace se

může a nemusí provést, pokud se nepovede, je to znamení, že se někde stala chyba.

CI nám dovoluje tuto chybu odhalit v jejím prvopočátku a ne ve chvíli, kdy nám budou

testeři zuřivě dupat po krku, a požadovat verzi k otestování, kterou nemůžeme, např.

z důvodů různých nekompatibilit, dodat. Díky CI jsme schopni plno chyb odhalit v

jejich počátcích.

Jak často integrovat?

Opět specifická otázka, dle mého soudu, záleží na vývojářské aktivitě. Pokud finišujete před verzí a co chvíli chrlí vývojáři své výplody do zdrojového repositáře, pak v hodinových intervalech. Pokud je vývoj vlažnější můžete denně formou tzv. nigtly buildu.

To je pro dnešek vše. Na příště jsem si nechal jednak nástroj Luntbuild, ve kterém jsem CI realizoval, a dále integraci s GForge aneb spamování vývojářů výsledky buildu, verzování buildu a plno dalších drobností, které mi teď hlava nebere.