3 cesty k DevOps

Kniha „The Phoenix Project: A Novel About IT, Devops, and Helping Your Business Win“ vo veľkej miere zviditeľnila pojem DevOps a podrobne rozpracovala tému IT manažmentu a s ním súvisiace obchodné problémy. Stala sa hitom, ktorý poukázal na 3 hlavné cesty, ktorými využiť DevOps.   

Prvá cesta: Zľava doprava

Základným princípom rýchleho vývoja produktu je, že všetky oddelenia vo firme, ktoré sa zúčastňujú daných procesov, musia vykonávať svoju prácu najlepšie ako vedia a odovzdávať ju dokončenú ďalej. Aby bolo niečo takéto možné, každé oddelenie (jednotlivec či celá divízia) musí minimalizovať množstvo rozrobenej roboty (WIP – Work In Progress) a zamerať sa na úlohy postupne - jednu po druhej. Taktiež je dôležité, aby každý účastník prešiel celým procesom bez odhalenia akýchkoľvek nedostatkov a nedošlo tak k tomu, že niektorá z miestnych divízií spôsobí globálnu degradáciu. Každé oddelenie by malo odovzdávať všetky informácie a poznatky ďalšiemu oddeleniu, ktoré preberá jeho prácu a pokračuje v dokončovaní procesu.    

Ako znázorňuje obrázok dole, DevOps aktivuje celý tok získavania obchodnej hodnoty: od získania biznisu a identifikovania požiadaviek na produkt, cez samotný development (tvorba produktu podľa požiadaviek), cez zabezpečenie prevádzky až po jeho dodanie ku zákazníkovi.   

Druhá cesta: Sprava doľava

Na vybudovanie vysoko kvalitného produktu, ktorý bude spĺňať potreby zákazníkov, je kľúčové od nich získavať spätnú väzbu čo najrýchlejšie. Oddelenia, ktoré sme si zadefinovali vyššie (business, development, operations, customer), by mali poskytovať spätnú väzbu oddeleniu, ktoré sa nachádza v toku pred ním. Vývojársky tím by mal obchodnému oddeleniu poskytnúť informácie o časových odhadoch, technologických obmedzeniach a možných rizikách v obchode. Oddelenie prevádzky musí informovať tím vývojárov o detegovaných problémoch a zákazník by mal na oddelenie prevádzky posúvať ďalej svoj názor a postrehy v súvislosti s kvalitou produktu.      

V bode, v ktorom dochádza ku komunikácií a odovzdávaniu práce medzi vývojárskym tímom a oddelením prevádzky sa môže mnoho úkonov automatizovať. A práve toto je miesto, v ktorom sa vykonáva kontinuálna integrácia (CI – Continuous Integration) a kontinuálne nasadenie (CD – Continuous Deployment).

Kontinuálna integrácia sa môže realizovať automatizovanými procesmi, ktoré sa spúšťajú zakaždým, keď je kód nasadený do systému na riadenie verzie (VCS – Version Control System), ako je napríklad Git, alebo keď je zlúčený do (pred)produkčnej vetvy. Vývojár môže vidieť výsledok testu v priebehu niekoľkých minút a na základe neho okamžite vie, či jeho nový kód spĺňa všetko, čo vyžadujú dané testy. Tie pritom obsahujú mnoho aspektov programovania, ako sú napríklad analýza kvality kódu, testovanie častí logiky (unit testy), integračné testy na odhalenie chýb pri integrácii medzi integrovanými časťami kódu, automatické testovanie používateľského rozhrania a iné typy automatizovaných testov. Tieto testy sa môžu vykonávať pred alebo aj po vytvorení softvéru, závisí od charakteru testu.

Predstavte si, že by ste počas jedného dňa robili viacero zmien a chceli by ste ich mal ihneď integrované. Čo by to znamenalo? Vývojár by musel zakaždým poslať softvér testovaciemu oddeleniu (QA – Quality Assurance), tí by museli znova vykonať všetky testy a nakoniec aj otestovať celý integrovaný systém. Toto všetko však môže byť automatizované v CI, čo znamená, že QA potom testuje celé systémy až po tom, čo sú úspešne nasadené do vývojárskeho prostredia alebo (pred)produkčného prostredia.

Ďalšou skvelou črtou kontinuálnej integrácie je automatické buildovanie. Znamená to, že tvorba softvéru sa generuje automaticky po poslaní kódu do VCS alebo na základe konkrétneho času. Ak buildovanie zlyhá, automaticky sa deteguje chyba. Vďaka tomu to vývojár nezistí až v „deň D“, kedy má ísť softvér oficiálne von.

Výsledkom celej integrácie v CI je, že buď vývojár získa spätnú väzbu na tie veci, ktoré by mal opraviť, alebo získa skontrolovaný a spustiteľný softvér, ktorý je pripravený na nasadenie. Následne po tom začína proces kontinuálnej dodávky CD, kedy sa softvér dodáva do reálneho prostredia na testovanie a používanie.

Existujú 2 typy CD reťazcov: Kontinuálna dodávka (Continuous Delivery) a Kontinuálne nasadenie (Continuous Deployment). Sú veľmi podobné, len s jedným zásadným rozdielom – pri kontinuálnej dodávke musí byť nasadenie do produkcie manuálne naplánované či dokonca manuálne vykonané. Pri kontinuálnom nasadení je celý proces plne automatizovaný a dá sa mu zabrániť iba tým, že neprejde testovaním.

Oba tieto CD reťazce sú určené na dodávanie malých iteratívnych zmien do produkcie, pri ktorých je ľahké identifikovať chyby a v prípade potreby ich vrátiť naspäť. Každá zo zmien musí vždy prejsť sériou automatizovaných testov, ktoré výrazne znižujú riziko výskytu porúch po nasadení.

Veľkou výhodou použitia CI/CD je, že neexistujú žiadne „dni vydania“ (release date), pretože každý deň je malým dňom vydania. Tejto veci sa teší najmä vývojársky tím a oddelenie prevádzky, pretože práve oni majú tendenciu robiť zmeny na poslednú chvíľu a tie veľakrát končia v neúspešných vydaniach.

Proces CI/CD závisí vo veľkej miere na nástrojoch na testovanie, integráciu a nasadenie. Mnoho projektov v oblasti infraštruktúry sa distribuuje vývojárom, nakoľko virtuálne kontajnery sa používajú na simuláciu produkčného prostredia na lokálnom počítači, vo vývojovom prostredí a v (pred)produkčnom prostredí. Toto tiež zabraňuje tomu, aby sa tak často nevyskytovali chyby špecifické pre daný systém.

Vďaka týmto technikám je spoločnosť Facebook schopná vykonávať tisícky nasadení každý jeden deň, testovať ich, šíriť ich medzi zamestnancami, rozširovať ich najprv na niekoľko používateľov a nakoniec sprístupňovať všetkým používateľom. Tieto zmeny je možné kedykoľvek zastaviť automatizovanými testami alebo spätnou väzbou od ľudí, ktorí ich už používajú.

Tretia cesta

Tretia cesta je o kultúrnom posune priamo v organizácii. Ľudia sa nemusia báť riskovať a experimentovať. Ak to nefunguje, automatizované testy by mali zastaviť nasadzovanie. Ak to funguje, tím niečo vyskúšal a naučil sa vďaka tomu niečo nové. V oboch prípadoch – úspech alebo zlyhanie – sa ľudia niečo naučia a získajú nové skúsenosti. Tím by však mal mať v zálohe aj nejaký náhradný plán, ktorý by mohol byť užitočný v budúcnosti pri zlyhaní produkcie.   

Experimentovanie a riskovanie sú jediným spôsobom, ako posunúť inovácie dopredu a dosiahnuť nové hranice.