Životný cyklus DevOps

Vzhľadom ku skutočnosti, že DevOps je nikdy nekončiacim, opakovaným procesom neustáleho zlepšovania sa v praxi životný cyklus DevOps graficky znázorňuje ako nekonečná slučka, ktorá ukazuje ako jednotlivé fázy na seba nadväzujú.

Životný cyklus DevOps pozostáva z ôsmych fáz, ktoré predstavujú procesy, schopnosti a nástroje potrebné pre vývoj (development) (na ľavej strane slučky) a prevádzku (ope- rations) (na pravej strane slučky). Počas každej fázy tímy spolupracujú a komunikujú s cieľom zachovať súlad, rýchlosť a kvalitu.

Plánovanie

Fáza plánovania pokrýva všetko čo predchádza písaniu kódu vývojármi a je to časť kde produktový a projektový manažéri majú hlavné slovo. Požiadavky a spätná väzba sú zozbierané od zákazníkov a zainteresovaných strán pre vytvorenie produktového plánu, ktorý bude usmerňovať budúci vývoj. Produktový plán môže byť zaznamenávaný a sledovaný za pomoci systémov pre riadenie projektov akými sú napr. Jira, Azure Devops alebo Asana, ktoré poskytujú širokú škálu nástrojov napomáhajúce sledovaniu progresu projektu, jeho úlohami (tasks), problémami na vyriešenie (issues) alebo míľnikmi (milestones).

Projetovú mapu je ešte možné rozdeliť na epiky (epics), funkcie (features) a používateľské príbehy (User Stories), čím sa vytvorí zásobník nevyriešených úloh (backlog) presne podľa zákazníckych požiadaviek. Úlohy v zásobníku môžu a pravdepodobne budú použité na plánovanie šprintov a prideľovanie úloh tímu na začatie vývoja.

Písanie kódu

Okrem štandardnej sady nástrojov pre vývojárov softvéru, má tím vo svojich vývojových prostrediach nainštalovanú aj štandardnú sadu doplnkov (pluginov), ktoré pomáhajú vývojovému procesu, pomáhajú presadzovať konzistentný štýl kódu a vyhýbajú sa bežným bezpečnostným chybám či chybným vzorom pri písaní kódu.

Toto pomáha naučiť vývojárov správne postupy pri písaní kódu a zároveň napomáha spolupráci tým, že poskytuje určitú konzistenciu zdrojového kódu. Tieto nástroje tiež pomáhajú riešiť problémy, ktoré môžu vyústiť v zlyhanie pri testoch, čo vedie k menšiemu počtu neúspešných zostavení.

Zostavenie

Keď vývojár dokončí svoju úlohu, odošle svoj kód do zdieľaného úložiska kódu – Git repozitáru. Existuje viacero spôsobov, ako to je možné urobiť, ale zvyčajne vývojár odošle požiadavku na zapracovanie (pull request) – žiadosť o zlúčenie jeho nového kódu so zdieľaným zdrojovým kódom. Ďalší vývojár potom skontroluje zmeny, ktoré vykonal, a keď je spokojný, že sa v kóde nenachádzajú žiadne chyby a ani problémy, žiadosť o zapracovanie schváli. Táto manuálna kontrola má byť rýchla a ľahká, ale je účinná pri včasnej identifikácii chýb.

Súčasne požiadavka na zapracovanie (pull request) spustí automatizovaný proces, ktorý zostaví výsledný zdrojový kód a spustí sériu integračných a jednotkových testov na identifikáciu akýchkoľvek zhoršení. Ak zostavenie zlyhá alebo zlyhá niektorý z testov, požiadavka na zapracovanie zlyhá a vývojár dostane upozornenie, aby problém vyriešil. Nepretržitou kontrolou zmien kódu v zdieľanom úložisku a spustením zostavenia a testov sa môžu minimalizovať problémy s integráciou, ktoré vznikajú pri práci na zdieľanom zdrojovom kóde, a upozorniť tak na chyby vyskytujúce sa už začiatku životného cyklu vývoja.

Testovanie

Akonáhle je zostavenie úspešné, je automaticky nasadene do prípravného prostredia (staging) na hlbšie testovanie mimo produkciu a vývojárskeho prostredia. Predbežným prostredím môže byť existujúca hostiteľská služba (hosting service) alebo to môže byť nové prostredie poskytnuté ako súčasť procesu nasadenia. Tento postup automatického poskytovania nového prostredia v čase nasadenia sa označuje ako „Infraštruktúra ako kód (Infrastructure-as-Code – IaC)“ a je základnou súčasťou mnohých automatizovaných kanálov (pipelines) DevOps.

Po nasadení aplikácie do testovacieho prostredia sa vykoná séria manuálnych a automatických testov. Manuálne testovanie môže byť tradičným užívateľským akceptačným testovaním (User Acceptance Testing – UAT), kde testeri používajú aplikáciu tak, ako by ju používal zákazník, aby upozornili na akékoľvek problémy alebo vylepšenia, ktoré by sa mali riešiť pred nasadením do produkcie.

Automatizované testy môžu súčasne vykonávať bezpečnostnú kontrolu aplikácie, kontrolovať zmeny infraštruktúry a súlad s osvedčenými postupmi, testovať výkon aplikácie alebo spúšťať záťažové testy. Testovanie, ktoré sa vykonáva počas tejto fázy, závisí od organizácie a od toho, čo je relevantné pre aplikáciu, ale túto fázu možno považovať za testovaciu platformu, ktorá umožní zapojiť nové testovania, a to aj nad rámec vyššie spomenutých, bez prerušenia práce vývojárov alebo ovplyvnenia produkčného prostredia.

Vydanie

Fáza vydania je míľnikom v DevOps procese – je to bod, v ktorom môžeme povedať, že zostavený zdrojový kód je pripravený na nasadenie do produkčného prostredia. V tejto fáze každá zmena kódu prešla sériou manuálnych a automatických testov a operačný tím si môže byť istý, že akékoľvek markantné problémy alebo zhoršenia aplikácie sú nepravdepodobné.

V závislosti od zrelosti DevOps v organizácii sa môže rozhodnúť o automatickom nasadení akéhokoľvek zostavenie (build), ktorý sa dostane do tejto fázy procesu. Vývojári môžu pomocou prepínačov (flags) funkcií vypnúť nové funkcie, aby ich zákazníci nevideli, kým nie sú pripravené do ostrej prevádzky. Podľa tohto modelu sa organizáciám darí každý deň nasadzovať viaceré vydania svojich produktov.

Alternatívne môže organizácia chcieť mať pod kontrolu to, kedy budú zostavy (builds) uvoľnené do produkcie. Môžu chcieť mať pravidelný plán vydávania alebo vydať nové funkcie až po splnení míľnika (milestone). Vo fáze vydania môže byť pridaný proces manuálneho schvaľovania, ktorý umožňuje len určitým osobám v rámci organizácie autorizovať vydanie do produkcie.

Nasadenie

Napokon je zostavenie pripravené a uvedené do produkčného prostredia. Existuje niekoľko nástrojov a procesov, ktoré môžu automatizovať proces vydania, aby boli spoľahlivé a bez výpadkov.

Rovnakú infraštruktúru ako kód (IaC), ktorá vytvorila testovacie prostredie, možno nakonfigurovať na vytvorenie produkčného prostredia. Už vieme, že testovacie prostredie bolo vytvorené úspešne, takže si môžeme byť istí, že produkčné vydanie prebehne bez problémov.

Modrozelené nasadenie (Blue green deployment) 1 nám umožňuje prejsť do nového produkčného prostredia bez výpadkov. Potom je vybudované nové prostredie, ktoré existuje vedľa už existujúceho produkčného prostredia. Keď je nové prostredie pripravené, hostiteľská služba nasmeruje všetky nové požiadavky na nové prostredie. Ak sa v ktoromkoľvek bode nájde problém s novou zostavou (build), môže sa jednoducho zabezpečiť, aby požiadavky smerovali späť do starého prostredia na čas, pokým sa problém vyrieši.

Prevádzka

Nové vydanie je už v tejto fáze aktívne a zákazníci ho používajú. Operačný tím teraz zabezpečuje, aby všetko fungovalo hladko. Na základe konfigurácie hostiteľskej služby (hosting service) sa prostredie automaticky prispôsobuje záťaži (load), aby zvládlo vrcholy a poklesy v počte aktívnych používateľov.

Organizácia by taktiež mala vytvoriť spôsob, akým môžu zákazníci poskytovať spätnú väzbu o ich službách, ako aj zabezpečiť nástroje, ktoré pomáhajú zhromažďovať a triediť túto spätnú väzbu, aby pomohli formovať budúci vývoj produktu. Táto slučka spätnej väzby je dôležitá – nikto nevie, čo chce, viac ako zákazník, a zákazníci sú najlepším testovacím tímom, ktorý testovaniu aplikácie venuje oveľa viac času, ako by to kedy dokázal DevOps proces. 

Monitorovanie

„Záverečnou“ fázou DevOps cyklu je monitorovanie prostredia. To stavia na spätnej väzbe od zákazníkov poskytnutej vo fáze prevádzky zhromažďovaním údajov a poskytovaním analýzy o správaní zákazníkov, výkone, chybách a ďalších.

Môžeme tiež urobiť introspekciu a monitorovať samotný proces DevOps, monitorovať potenciálne kritické miesta (bottlenecks) v procese, ktoré spôsobujú frustráciu alebo ovplyvňujú produktivitu vývojových a prevádzkových tímov.

Všetky tieto informácie sa potom vrátia späť produktovému manažérovi a vývojovému tímu, aby sa uzavrela slučka procesu. Bolo by ľahké povedať, že tu sa slučka znova začína, ale realita je taká, že tento proces je nepretržitý. Neexistuje žiadny začiatok ani koniec, len neustály vývoj produktu počas jeho životnosti, ktorý sa končí až vtedy, keď sa projekt prestane udržiavať alebo ho už zákazníci nepotrebujú.