pátek 22. května 2009

Proč by se vývojář neměl bát červeného světla

Setkávám se s názorem, že vývojář by měl před každým commitem pustit při nejmenším build celého projektu a všechny testy. To je přístup, který neodpovídá je v rozporu s kontinuální integrací. Proč děláme kontinuální integraci, je to proto, abychom neustále viděli zelené světlo a nebo proto, aby jsme zavčasu zjistili, že máme problém? Občas se mi zdá, že je to jenom kvůli tomu zelenému světlu a to na úkor efektivního využití zdrojů ať již lidských či technických.

Každý projekt, kterého jsem se účastnil, přerostl v určitou dobu kritickou mez, kdy přístup spustím build a testy před commitem prostě neškáloval. Kompletní build našeho HP SOA Systinet trvá na mém počítači přes dvacet minut a to se vůbec nebavím o spuštění testů. Kdyby každý vývojář toto dělal na svém počítači, tak se z toho buďto ukouše nudou a nebo nic nestihne, protože bude čekat, až mu doběhne build.

Je proto efektivnější udělat commit, který může potenciálně rozbít build. Efektivnější je to protože většina commitu ten build prostě nerozbije. Většina vývojářů totiž dělá změny lokálního charakteru, a nejčastější problémy, které těmito zásahy mohou vzniknout, odhalí IDE. Čili zůstane relativně malé množství problémů a kvůli nim se nevyplatí pouštět celý ten kafemlejnek lokálně.

Servery kontinuální integrace bývají zpravidla mnohem výkonnější něž lokální vývojářské stanice a navíc mohou dělat celou řadu optimalizací. Distribuovat build, udělat analýzu závislosti a vybuildovat jenom to co se změnilo, použít lokalní cache, buildovat dávkově a podobně. Čili věci, o kterých si vývojář se svými omezenými zdroji může jenom nechat zdát.

Rozsvícené červené světlo neznamená žádnou tragédii! Pokud tuhle hru přijmete je potřeba ji hrát s jedním pravidlem. Do rozbitého stavu by se neměly nehromadit další commity. To můžete zajistit automatickým zamknutím version control systému v případě zboření. Povoleny jsou jenom commity, které to opravují. Rozpoznávat je lze rovněž automaticky, vývojář to o nich prozradí v commit message podle předefinované šablony. Pak nehrozí situace, že vývojář rozbije build, pak ho přejede tramvaj, a už to nikdo neopraví, protože bude zamčený version control systém.

Samozřejmě existují i méně invazivní metody. Při použití distribuovaného verzovacího systému lze mít hierarchii repozitoří. Pak je možné dosáhnout toho, že se commit automaticky posouvá v hierarchii repozitoří od té týmové až po tu projektovou v závislosti, jestli se povedlo na dané úrovni vybuilldovat. Ve výsledku tak nedochází k zamykání version control systému.