Nic se nezrodí přes noc a jinak tomu nebylo ani v případě DevOps. Na počátku devadesátých let minulého století se objevila vlaštovka v podobě denního sestavení aplikace (Daily Build). Z dnešního pohledu nic závratného, nicméně vzhledem v té době dostupným technologiím a nástrojům šlo o malou revoluci v podobě zkompilovaného a připraveného výstupu každý den, navíc otestovaného alespoň základními testy. Na konci devadesátých let jsme se již bavili o kontinuální integraci. Vše, co se do té doby dělo na konci dne, bylo možné řešit po každé změně ve verzovacím systému a mimo aplikace jednotkových testů byla zapojena i statická analýza kódu (např. nástroje typu CheckStyle, PMD, FindBugs, atd.). Na přelomu století jsme si poté zvykli i na komfort kontinuální dodávky (Continuous Delivery), tedy nejenom na připravenou aplikaci, ale i všechny nezbytné artefakty související s dodávkou, konfigurační skripty, inkrementální dodávky atd.

To vše samozřejmě předpokládá již velmi propracovanou automatizaci, nástroje, konfigurační řízení, definici postupů či procesů. Schopnost připravit software k nasazení každý den ještě neznamená, že jej lze také jednoduše (a automatizovaně) nasadit do produkce, kdykoliv je to zapotřebí. Tato schopnost již nevyžaduje pouze zapojení IT, ale také byznysu a musí být sladěna se všemi nezbytnými procesy, řízením požadavků, atd. Není tedy divu, že se některé organizace spokojí se schopností dodávat a nasazování řeší dle status quo. Nutno dodat, že v mnoha případech jde o naprosto rozumné a dostačující řešení.

Poslední evoluční krok

Touto menší oklikou se dostáváme k DevOps, zatím poslednímu evolučním krokům navazujícím na schopnost kontinuální dodávky, které jsou ještě mnohem dále. Nasazením na produkci vývoj software málokdy končí, a tedy i tento stav je nutné reflektovat v procesu vývoje. DevOps v tomto ohledu uzavírají pomyslnou smyčku pomocí kontinuálního monitoringu a silného zapojení právě Operations, které jsou dalším vstupem pro následný vývoj software. Vše výše uvedené by mělo eliminovat známé situace, kdy vývoj hlásí „perfektní dodávkou,“ kterou pouze provoz „neuměl nasadit“ nebo naopak provoz nadávající na nekvalitní vývoj. Přístup DevOps v tomto ohledu není pouze o nástrojích a procesech, ale hlavně o lidech. V týmu pracujícím v režimu DevOps musí mít odpovědnost za software všichni bez ohledu na to, kde a ve které fázi se případná chyba vyskytuje (žádné „to ne my, to oni“). Tento přístup není vhodný pro každého a někdo takto není schopen pracovat. Mimo odpovědnosti je totiž nezbytná i neustálá snaha o vylepšování a hledání optimálnějších cest.

Základem DevOps je snaha o maximální automatizaci každého kroku, přičemž jednotlivé kroky jsou dostatečně oddělené a malé, což podporuje možnost jejich znovupoužití a rychlou zpětnou vazbu v případě chyby. Vše musí být verzováno a testováno, nejde však pouze o zdrojové kódy, ale i o podpůrné skripty a v posledních letech také o verzování modelu databáze či konfiguračních dat. Z pohledu části Operations je kladen silný důraz na automatizaci nasazování, a to jedním procesem pro všechna prostředí, pouze s dostatečnou mírou konfigurace. Nasazení na produkci by mělo být stejně obtížné, jako nasazení do testovacího prostředí. Může jít o tzv. self-service, kdy úplně každý z týmu může pomocí aplikace / nástroje iniciovat sestavení aplikace a její nasazení na požadované prostředí.

Snížení nákladů na zdroje

Ve spojení s DevOps se však dříve nebo později někdo zeptá: „Zní to hezky, ale kolik mě to vlastně bude stát a co mi to přinese?“ Naprosto relevantní otázka, na kterou naštěstí lze odpovědět s pomocí dat. Jelikož jde o zkvalitnění, a v mnoha ohledech také zjednodušení vývojového i dodávkového procesu, tak lze jednoznačně očekávat snížení time-to-market. DevOps s sebou mimo jiné přinášejí vyšší nároky také na quality assurance, lze tedy očekávat snížení množství chyb ruku v ruce se zvýšením rychlosti jejich oprav, což v důsledku implikuje i snížení nákladů na zdroje na straně jak vývoje, tak i provozu. Pokud se navíc na otázku bude ptát někdo z IT, lze argumentovat i možností větší volnosti při experimentování (což v případě legacy systémů může znamenat i snižování technického dluhu), a to právě díky rychlé zpětné vazbě v případě zavlečení chyby a schopnosti operativní dodávky.

Při měření přínosů DevOps se lze zaměřit na čtyři základní faktory – trvání dodávkového cyklu; důvěru v kvalitu dodávky; náklady na dodávku; schopnost „experimentovat“. Typické statistiky jsou dlouhá doba dodání, s nízkou důvěrou ve výstupy a nesou s sebou vysoké náklady se strachem ze změny. Cílem DevOps je tento poměr otočit, tedy zkrátit délku cyklu, snížit náklady a posílit důvěru v dodávku i při zvýšené míře experimentování. Jak ale s DevOps vlastně začít? Jednoduchá odpověď je „ihned“, nicméně postupně a cíleně.

Základ úspěchu je na světě

Na novém projektu je to jednoduché. Nejprve z jeho rozpočtu vyčleníte jednotky dní na nastavení vývojového prostředí (verzovací systém, continuous integration server a build proces, nástroj pro statickou analýzu, atd.), a základ úspěchu je na světě. Ještě lepší zprávou je, že pro většinu úloh spojených s DevOps nejsou nutné veliké investice do softwaru, ale postačí volně dostupné nástroje jako SVN, Git, Ant, Maven, Gradle, Jenkins, SonarQube či Bugzilla. Pokud na některé úlohy nástroje nestačí, vždy si lze vypomoci nějakým menším skriptem – vhodných programovacích jazyků pro tento účel je spousta (Python, Groovy, Powershell, Bash).

Pokud se chystáte zavádět DevOps na běžícím projektu, dělejte menší a cílené kroky. Velice rozumné je mít informace o tom, kde je největší problém. Trápí vás množství chyb? Začněte s testy (jednotkové, GUI testy, …). Trápí vás problematické sestavení aplikace nebo nasazení na prostředí? Začněte s automatizací tvorby dodávky, upravte build skripty, zaveďte deployment pipeline, apod. Rozhodně se nesnažte vše „zlomit“ najednou. Postupné kroky jsou v tomto případě jedinou rozumnou volbou. Mimo toho, že je takto zvolený přístup mnohem bezpečnější, vám menší iterace pomohou i v týmu, kdy se jednotliví členové s novinkami postupně sžijí a ideálně začnou sami časem zavádět další a další. Platí, že i každá malá změna může mít obrovské pozitivní dopady.

Uveďme si příklad, jeden integrační projekt, kde byl proces dodávky manuální úlohou. I přes precizní popis postupu byla tvorba dodávky závislá na jednom konkrétním člověku, který přesně věděl, co má dělat. S blížícím se termínem nasazení do akceptace se zvyšoval i stres a kvality dodávek do testovacího prostředí se začaly rapidně zhoršovat, přičemž tým nevěděl, zda se jedná o chybu softwaru nebo dodávky. Alespoň v jedné oblasti byla nutná jistota, a proto bylo rozhodnuto, že se dodávka zautomatizuje. Vlastní zprovoznění trvalo dva dny, avšak po prvních dvou úspěšných a bezchybných nasazeních nabyl tým ztracené jistoty a plně se začal soustředit na vývoj vlastního softwaru. Tyto dva dny byly ve výsledku jedním z hlavních faktorů úspěchu celého projektu.

DevOps je o vůli neustále se zlepšovat

DevOps není ve výsledku o nástrojích a velkých investicích. Je o vůli chtít neustále zlepšovat a nespokojit se se stávajícím stavem. Dnes více než kdy jindy platí, že opravdu nic není nemožné (automatická konfigurace serverů, bezodstávkové nasazení, atd.), pouze je nutné chtít a začít. I malá změna může být tím pomyslným jazýčkem na misce vah mezi úspěchem projektu.

Michal Petřík Autor článku působí jako Senior Consultant ve společnosti Profinit, kde je v současné době zodpovědný za dodávky systémů převážně pro zákazníky z finančního sektoru. Mimo výše uvedeného se zaměřuje i na oblast návrhu architektury, designu, dohledu nad dodržením kvalitativních nároků vývoje a taktéž je silným zastáncem myšlenek Continuous Delivery a DevOps obecně.