neděle 1. srpna 2010

Continuous Deployment

Už jsme to téma nakousli s Filemonem Obrienem99 v podcastu 39, ale stejně bych se mu věnoval speciálně. Od té doby co nejsem jenom korporátník vidím, že svět mimo enterprise (podnikové) aplikace nabízí hodně inspirativních témat. Již jsem psal o NoSQL databazích a nebo o JavaScriptu. V GoodData se hodně bavíme o Continuous Deploymentu, tedy jak co nejrychleji dostat kód kterému věříme do produkce. Kdy měřítkem rychlosti nejsou měsíce, týdny, dny a nebo hodiny, ale minuty.

Neděláme krabicový software, nemůžete si nás koupit jako jogurt a odnést domu a pak si nás vychutnat. Produkujeme službu, kterou naši uživatelé konzumují prostým klikáním ve webovém prohlížeči. To nám přináší tu výhodu, že naše náklady spojené s releasem nenese uživatel. Oproti krabicovému softwaru je ten posun v tom, že nemusíme například podporovat heterogenní prostředí, do kterých se aplikace nasazuje a s tím spojené problémy.

O čem je Continuous Deployment

V Continuous Deploymentu jde o to, že máte prostředky a infrastrukturu, která vám umožní nasadit každý důvěryhodný commit přímo do produkce v řádech minut. Opravdu to není bláhová myšlenka, jak by se možná zdálo na první pohled. Dělá to takhle celá řada internetových služeb jako třeba Facebook. Trochu netradičně dám teď uprostřed článku pár odkazů, které vedou na skvělé povídání o Continuous Deploymentu a pak zkusím připojit pár vlastních postřehů.

Testy

Sledujete občas rallye sport? To jsou ty blázni co se řítí v závodních speciálech po úzké šotolinové cestě v rychlostech kolem dvoustovky, nejlépe s třicetimetrovou strží po obouch stranách vozovky. Piloti jsou zde vydáni absolutně do rukou navigátor, který čte z itineráře rychlostní zkoušky charakteristiku tratě - jaká je další zatáčka, profil tratě, nebezpečná místa atd. Jedna chyba a končíte nohama v lepším případě vzhůru a v horším napřed.

V Continuous Deploymentu jsou vývojáři řidičem a testy jeho navigátorem. Pokud se nemůžete absolutně spolehnout na testy, končíte podobně jako v rallye. Spolehlivé testy, kterým věříte jsou alfou a omegou celého snažení. Kromě toho, že ty testy jsou spolehlivé, musí být samozřejmě rychlé. Vzpomínám si jak jsme ještě za dob Systinetu běhali integrační testy několik hodin a jak díky složitému deploymentu nebyly spolehlivé. Kdy spolehlivost v Continuous Deploymentu popisuje Timothy Fritz z INVU následovně.

When I say reliable, I don’t mean “they can fail once in a thousand test runs.” I mean “they must not fail more often than once in a million test runs.” We have around 15k test cases, and they’re run around 70 times a day. That’s a million test cases a day. Even with a literally one in a million chance of an intermittent failure per test case we would still expect to see an intermittent test failure every day. It may be hard to imagine writing rock solid one-in-a-million-or-better tests that drive Internet Explorer to click ajax frontend buttons executing backend apache, php, memcache, mysql, java and solr

Se znalostí Javy jsem přemýšlel, jak bylo možné dosáhnout rychlosti proběhnutí testů v řádech jednotek minut (testy se pouští pro každý commit). Neexistuje jednoduchý recept, musíme kombinovat od každého trochu: paralelní spuštění testů, "share nothing" mezi testy, mockování. S tím úzce souvisí i design a návrh architektury aplikace. Aby bylo možné takto vůbec testovat, nesmí být aplikace napsaná nebo nedej bože navržená jako zapečené italské těstoviny.

Infrastruktura

Druhým klíčovým aspektem Continuous Deploymentu je infrastruktura, která automatizuje celý proces - počínaje VCS hookem, přes monitoring a konče commitem či rollbackem změny v produkčním clusteru. Nenarazil jsem na nic standardizovaného, pokud to vůbec jde, a tak to vypadá, že si to každý stlouká doma na koleni krom continuous integration serveru.

Dobrá otázka, která mě napadá na závěr. Proč bych vůbec měl chtít, aby se moje změny dostaly co nejrychleji do produkce. Je to prostě a jednoduše konkurenční výhoda. Čím rychleji to dokážeme, tím rychleji stačíme reagovat na požadavky našeho businessu. Říká se tomu schopnost dělat rychlé obrátky. Další nespornou výhodou je, že už nemusíte mít nákladné oddělení kvality, protože klikání máte zautomatizované a lidi z QA se mohou věnovat opravdu kvalitě.

Kultura a lidé

Jestli o úspěšnosti nějaké metodologie rozhoduje kultura a lidé v týmu, pak u Continuous Deploymentu to platí dvakrát tolik. Continuous Deployment je nasaditelný pouze pokud máte lidi, kteří píší testy ne protože je k tomu vede nějaké nařízení, ale protože tomu opravdu věří. Mottoem může být parafráze názvu jedné knihy "Test je mým druhým pilotem".

2.8.2010 - Obrienovo pohled na věc: