DevOps, nebo chcete-li velmi zjednodušeně zkratka pro úzkou spolupráci vývoje a provozu (Development & Operations ), je hitem posledních let. Všichni o tématu mluví, spousta firem se tuto metodu snaží zavádět. Nicméně stejně jako v případě agilního přístupu se liší názory na jednu zásadní věc – co se za DevOps doopravdy skrývá. Cílem tohoto textu rozhodně není definice té jedné jediné pravdy (která beztak neexistuje), ani přesvědčování, že DevOps vyřeší všechny problémy (protože nevyřeší). Hlavním sdělením by mělo být, že i to nejmenší vylepšení současného stavu může v důsledku pomoci a mimo času a nadšení nejsou potřeba žádné zásadní investice.
Na začátku se však pojďme podívat trochu zpátky do historie. 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ů se jednalo 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říklad 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. Vše toto samozřejmě předpokládá již velmi propracovanou automatizaci, nástroje, konfigurační řízení, definici postupů, procesů, apod.
Exkurze do Continuous Deployment
Nyní si dovolím malou odbočku k jedné oblasti, která je velmi často slučována s kontinuální dodávkou, a to kontinuální nasazování (Continuous Deployment). Ač se mohou zdát oba přístupy podobné, jedná se o značně odlišnou úroveň vyspělosti organizace. Schopnost připravit váš software k nasazení každý den ještě neznamená, že jej můžete také jednoduše (a automatizovaně) nasadit do produkce, kdykoliv se zachce. Tato schopnost již nevyžaduje pouze zapojení IT, ale také business 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 se jedná o naprosto rozumné a dostačující řešení.
Touto menší oklikou se dostáváme k DevOps, které jsou (zatím) posledním evolučním krokem a navazují na schopnost kontinuální dodávky, nicméně jdou ještě mnohem dál. 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“). Upřímně řečeno, 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.
Co mi DevOps přinese?
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, zde se však nebavíme pouze o zdrojových kódech, ale i podpůrných skriptech a v posledních letech také o verzování modelu databáze, konfiguračních dat apod. 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í apod. V tomto případě se také velmi často hovoří 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í.
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í tvrdých dat (samozřejmě za předpokladu, že je budete měřit). Jelikož se bavíme 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 sebo 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, apod.). A to právě díky rychlé zpětné vazbě v případě zavlečení chyby a schopnosti operativní dodávky.
4 faktory DevOps
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 a právě schopnost „experimentovat“. Ruku na srdce, ale typické statistiky jsou dlouhé doba cyklu dodávky s nízkou důvěrou, vysoké náklady a strach 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ě. Na novém projektu je to jednoduché. Pokud jste rozumní, stačí z rozpočtu vyčlenit 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 software, ale postačí volně dostupné (a licencí neomezené) nástroje, jmenujme například: SVN, Git, Ant, Maven, Gradle, Jenkins, SonarQube, Bugzilla atd. 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 rámci týmu, kdy se jednotliví členové s novinkami postupně sžijí a ideálně začnou sami časem zavádět další a další.
Hotovo za 2 dny
Platí, že i každá malá změna může mít obrovské pozitivní dopady. Pamatuji si na jeden integrační projekt, kde byl proces dodávky manuální úlohou. I přes precizní popis postupu byla tvorba dodávky závislá vlastně na jednom konkrétním člověku, který prostě 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 software nebo dodávky. Alespoň v jedné oblasti byla nutná jistota, a proto bylo rozhodnuto, že se dodávka zautomatizuje. Vlastní zprovoznění trvalo pouhé 2 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 software. Tyto dva dny byly ve výsledku jedním z hlavních faktorů úspěchu celého projektu.
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 vašeho projektu.
Michal Petřík
Senior Consultant, Profinit
Článek vyšel v časopise IT Systems 11/2016