Technologie

Jul 19. 2018

3 cesty k DevOps

devops

Kniha "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win" ve velké míře zviditelnila pojem DevOps a podrobně rozpracovala téma IT managementu a s ním související obchodní problémy. Stala se hitem, který poukázal na 3 hlavní cesty, kterými využít DevOps.

 

První cesta: Zleva doprava

Základním principem rychlého vývoje produktu je, že všechna oddělení ve firmě, které se účastní daných procesů, musí vykonávat svou práci nejlépe jak umí a předávat ji dokončenou dále. Aby bylo něco takového možné, každé oddělení (jednotlivec či celá divize) musí minimalizovat množství rozdělané roboty (WIP - Work In Progress) a zaměřit se na úkoly postupně - jednu po druhé. Také je důležité, aby každý účastník prošel celým procesem bez odhalení jakýchkoli nedostatků a nedošlo tak k tomu, že některá z místních divizí způsobí globální degradaci. Každé oddělení by mělo předávat všechny informace a poznatky dalšímu oddělení, které přebírá jeho práci a pokračuje v dokončování procesu.

 

Jak znázorňuje obrázek dole, DevOps aktivuje celý tok získávání obchodní hodnoty: od získání byznysu a identifikace požadavků na produkt, přes samotný development (tvorba produktu dle požadavků), přes zajištění provozu až po jeho dodání k zákazníkovi.

 

devops

 

Druhá cesta: Zprava doleva

Na vybudování vysoce kvalitního produktu, který bude splňovat potřeby zákazníků, je klíčové od nich získávat zpětnou vazbu co nejrychleji. Oddělení, které jsme si definovali výše (business, development, operations, customer), by měly poskytovat zpětnou vazbu oddělení, které se nachází v toku před ním. Vývojářský tým by měl obchodnímu oddělení poskytnout informace o časových odhadech, technologických omezeních a možných rizicích v obchodě. Oddělení provozu musí informovat tým vývojářů o detekovaných problémech a zákazník by měl na oddělení provozu posouvat dále svůj názor a postřehy v souvislosti s kvalitou produktu.

 

devops

 

V bodě, kde dochází ke komunikaci a předávání práce mezi vývojářským týmem a oddělením provozu lze mnoho úkonů automatizovat. A právě toto je místo, ve kterém se provádí kontinuální integrace (CI - Continuous Integration) a kontinuální nasazení (CD - Continuous Deployment).

 

Kontinuální integrace lze realizovat automatizovanými procesy, které se spouštějí pokaždé, když je kód nasazen do systému pro řízení verze (VCS - Version Control System), jako je například Git nebo když je sloučen do (před)produkční větve. Vývojář může vidět výsledek testu během několika minut a na základě něj okamžitě ví, zda jeho nový kód splňuje vše, co vyžadují dané testy. Ty přitom obsahují mnoho aspektů programování, jako jsou například analýza kvality kódu, testování částí logiky (unit testy), integrační testy na odhalení chyb při integraci mezi integrovanými částmi kódu, automatické testování uživatelského rozhraní a jiné typy automatizovaných testů. Tyto testy se mohou provádět před nebo i po vytvoření softwaru, závisí na charakteru testu.

 

Představte si, že byste během jednoho dne dělali řadu změn a chtěli byste je měl ihned integrovány. Co by to znamenalo? Vývojář by musel pokaždé poslat software testovacímu oddělení (QA - Quality Assurance), ti by museli znovu provést všechny testy a nakonec i otestovat celý integrovaný systém. To vše však může být automatizované v CI, což znamená, že QA potom testuje celé systémy až po tom, co jsou úspěšně nasazeny do vývojářského prostředí nebo (před)produkčního prostředí.

 

Další skvělou vlastností kontinuální integrace je automatické buildovanie. Znamená to, že tvorba softwaru se generuje automaticky po posláni kódu do VCS nebo na základě konkrétního času. Pokud buildovanie selže, automaticky se detekuje chyba. Díky tomu to vývojář nezjistí až v "den D", kdy má jít software oficiálně ven.

 

Výsledkem celé integrace v CI je, že buď vývojář získá zpětnou vazbu na ty věci, které by měl opravit, nebo získá zkontrolován a spustitelný software, který je připraven na nasazení. Poté začíná proces kontinuální dodávky CD, kdy se software dodává do reálného prostředí pro testování a používání.

 

Existují 2 typy CD řetězců: Kontinuální dodávka (Continuous Delivery) a Kontinuální nasazení (Continuous Deployment). Jsou velmi podobné, jen s jedním zásadním rozdílem - při kontinuální dodávce musí být nasazení do produkce manuálně naplánované či dokonce manuálně provedeny. Při kontinuálním nasazení je celý proces plně automatizovaný a dá se mu zabránit pouze tím, že neprojde testováním.

 

devops kontinualna integracia

 

Oba tyto CD řetězce jsou určeny k dodávání malých iterativní změn do produkce, při kterých je snadné identifikovat chyby a v případě potřeby je vrátit zpět. Každá ze změn musí vždy projít sérií automatizovaných testů, které výrazně snižují riziko výskytu poruch po nasazení.

 

Velkou výhodou použití CI/CD je, že neexistují žádné "dny vydání" (release date), protože každý den je malým dnem vydání. Této věci se těší zejména vývojářský tým a oddělení provozu, protože právě oni mají tendenci dělat změny na poslední chvíli a ty mnohdy končí v neúspěšných vydáních.

 

Proces CI/CD závisí ve velké míře na nástrojích pro testování, integraci a nasazení. Mnoho projektů v oblasti infrastruktury se distribuuje vývojářům, nakolik virtuální kontejnery se používají k simulaci produkčního prostředí na lokálním počítači, ve vývojovém prostředí a v (před) produkčním prostředí. Toto také zabraňuje tomu, aby se tak často nevyskytovaly chyby specifické pro daný systém.

 

Díky těmto technikám je společnost Facebook schopna provádět tisíce nasazení každý jeden den, testovat je šířit mezi zaměstnanci, rozšiřovat je nejprve na několik uživatelů a nakonec zpřístupňovat všem uživatelům. Tyto změny je možné kdykoliv zastavit automatizovanými testy nebo zpětnou vazbou od lidí, kteří je již používají.

 

Třetí cesta

Třetí cesta je o kulturním posunu přímo v organizaci. Lidé se nemusí bát riskovat a experimentovat. Pokud to nefunguje, automatizované testy by měly zastavit nasazování. Pokud to funguje, tým něco vyzkoušel a naučil se díky tomu něco nového. V obou případech - úspěch nebo selhání - se lidé něco naučí a získají nové zkušenosti. Tým by však měl mít v záloze i nějaký náhradní plán, který by mohl být užitečný v budoucnu při selhání produkce.

Experimentování a riskování jsou jediným způsobem, jak posunout inovace dopředu a dosáhnout nové hranice.

 

devops tretia cesta

 

______________________________________________________________________

Přečtěte si také článek ↓
Na jakých 3 hlavních pilířích je postaven DevOps? 

Viktor

Viktor Šulák

Partner, Lead Backend Developer

Štítky: