čtvrtek 20. ledna 2005

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.