pátek 21. ledna 2005

Nesmažeš, nesmažeš... a smažu

Taky se vám někdy stalo, že jste při mazání souboru ve Windows, obdrželi hlášku Unable to delete file? Obzvláště vypečené je to, pokud si nejste vědomi, že máte někde otevřenou aplikaci, která by mohla daný soubor držet. Někdy je to opravdu problém pokud vám smazání lépe řečeno nesmazání brzdí práci.

Naštěstí pro Windows existuje nástroj Open Handles (součást Resource Kitu), který umí vypsat procesy jenž daný soubor drží. Malou nevýhodou je to, že předtím než utilitka začne poskytovat informace, musí se systém restartnout. Pokud nechcete neustále psát cestu k utilitce, nastavte si ji na PATH.

No a jak to vypadá výstup, když utilitka zapracuje?

 
C:\Tools\Ant\bin>oh ant
0000081C TOTALCMD.EXE   File   017c \Tools\Ant\bin
00000770 CMD.EXE        File   0018 \Tools\Ant\bin
00000634 oh.exe        File   0018 \Tools\Ant\bin
 

č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.