Rychlost, přívětivost, stabilita – to jsou jen základní očekávání, která dnes máme při používání aplikací. Neodpouštíme chyby ani pomalé načítání. Ať už si prohlížíme zboží na e-shopu nebo rezervujeme ubytování, chceme plynulý a intuitivní průchod aplikací.

S tím, jak se dramaticky proměnil přístup uživatelů k používání software, začal tradiční vývoj aplikací narážet na své limity. Dlouhé vývojové cykly a nasazování velkých aktualizací brání firmám držet krok s nároky uživatelů i rychle se měnícími požadavky trhu.

Vývojový cyklus zkracuje DevOps. Tato koncepce klade důraz na lepší spolupráci mezi vývojáři a provozními týmy i efektivnější procesy. Nové funkce se díky automatizaci dostávají k uživatelům rychleji a chyby se opravují dříve, než si jich vůbec všimnou. Aplikace jsou tak spolehlivější a uživatelé spokojenější.

Co je DevOps?

DevOps propojuje dva tradičně oddělené světy – vývoj software (Development) a správu provozu (Operations, nebo též IT operations). Jeho cílem je zajistit lepší spolupráci od počátku vývojového procesu až po nasazení softwaru do produkce a zkrátit tak vývojový cyklus aplikace.

Nejedná se přitom o žádnou pevně stanovenou metodiku nebo sadu konkrétních řešení. DevOps je především kombinací postupů a pro­po­je­ním lidí s rozsáhlými znalostmi napříč technologiemi i disciplínami.

Ačkoli DevOps stojí na využití automatizačních nástrojů, jeho pod­sta­tou je změna přístupu v kultuře vývoje. Jedním z nejčastějších problémů při tradičním vývoji software totiž bývá komplikovaná komunikace a spolupráce mezi vývojáři a správci IT. Zatímco vývojáři se snaží napsat moderní kód, IT administrátoři chtějí dlouhodobě udržovat co nejstabilnější a nejbezpečnější verze. Tyto pohledy mohou jít proti sobě a vývojové cykly se tím prodlužovat.

Jak DevOps funguje

Vývoj software realizovaný v duchu principů DevOps vedle spo­lu­prá­ce mezi týmy zahrnuje i několik technických procesů, které zajišťují plynulý a automatizovaný vývoj, testování i nasazení softwaru.

CI/CD pipeline: základní stavební kámen

Základem automatizovaných procesů v rámci DevOps je tzv. CI/CD pipeline. CI znamená průběžnou integraci (Continuous Integration), zatímco CD označuje průběžné nasazování (Continuous Deployment).

V praxi to znamená, že vývojáři průběžně vytváří menší části kódu, které se automaticky sestaví, otestují a sloučí se sdíleným repozitářem. Tato fáze je součástí procesu „CI“ a slouží k rychlé identifikaci chyb a jejich opravě. Fáze „CD“ rozšiřuje proces o automatické nasazování změn kódu do produkce a zajišťuje, že se změny co nejdříve dostanou k uživatelům aplikace.

Nejčastější vyobrazení CI/CD pipeline vč. jednotlivých fází každého z procesů. CI část zahrnuje fáze plánování, kódování, sestavení a testování, zatímco součástí CD je vydání, nasazení, provoz a monitoring.

Konkrétní podoba CI/CD pipeline je pro každou organizaci individuální, a to kvůli odlišným požadavkům na vývoj a nasazení softwaru. Podobu pipeline ovlivňují:

• typ projektu: nové aplikace nasazují změny častěji než kritické systémy, které mají delší testovací cykly.
• výběr nástrojů: CI/CD pipeline reflektuje technologie projektu. Například pipeline monolitické aplikace bude jednodušší, protože změny ovlivní vždy celou aplikaci. Pipeline aplikace založené na mikroslužbách bude komplexnější, protože tato architektura umožňuje paralelní nasazování jednotlivých služeb.
• velikost organizace: při větším počtu specializovaných týmů se musí navíc počítat třeba s předáváním mezi pracovními skupinami.
• bezpečnostní požadavky: kritické aplikace obvykle zahrnují ještě kontrolu zranitelností před nasazením do produkce. Integrace bezpečnosti do DevOps procesů se označuje jako DevSecOps.

CI/CD pipeline je především technický základ pro automatizaci vývoje. V kombinaci s firemními postupy a nástroji vytváří širší DevOps framework, jehož cílem je zefektivnit celý proces vývoje a nasazení softwaru.

DevOps engineer: klíčová role vývoje

Funkční DevOps framework se neobejde bez člověka, který dohlédne na hladký průběh prací na všech frontách. Tím člověkem bývá DevOps engineer, což je tak trochu superman. DevOps specialista musí mít široký technologický rozhled a skvělé manažerské dovednosti. Jeho úlohou je zachovat rychlost vývoje při stabilitě prostředí. Co přesně by měl mít v malíku?

• Znalost kódu;
• skriptování;
• infrastrukturu na vyšší úrovni (servery, storage, síť, …);
• komplexní vhled do všech částí vývoje;
• návrh a implementaci CI/CD pipeline;
• komunikaci mezi týmy.

V kontextu DevOps se objevují ještě role Site Reliability Engineer (SRE), který se stará o spolehlivost a výkon produkčních aplikací, a Platform Engineer, jehož úkolem je navrhovat a udržovat infrastrukturu vývojových platforem. Ani jedna z těchto rolí však sama o sobě nedokáže naplnit podstatu DevOps.

Tradiční vývoj vs. DevOps a jeho výhody

Specializované role budou efektivní pouze tehdy, pokud budou fungovat v kontextu ostatních částí DevOps frameworku. Jedině tak se podaří využít potenciál DevOps, který přinese:

• Kratší vývojový cyklus aplikace – rychlejší přechod od návrhu k nasazení, což umožní častější aktualizace a rychlejší reakci potřeby trhu.
• Vyšší kvalitu dodávaného kódu – pravidelné testování a automatizace zajišťují včasnou identifikaci a opravu chyb; zvyšuje se spolehlivost produktu.
• Lepší kooperaci a transparentnost – propojení vývojových a provozních týmů snižuje riziko nedorozumění a zlepšuje workflow.
• Sdílení informací a dokumentaci – všichni zúčastnění mají aktuální data i kontext a mohou se rychleji rozhodovat.
• Mikrosegmentaci – rozdělení aplikace na menší samostatné komponenty umožňuje pružnější nasazení a škálování, ale i hledání bugů a izolaci problémového kódu.
• Jednoduchý rollback – díky automatizaci je snadné aplikaci vrátit do předchozího stavu v případě problémů a minimalizovat tak výpadky.

Tradiční vývoj v podobě „waterfall“ je lineární a nasazení probíhá vždy až na konci. Agilní přístup eliminuje riziko chyb, protože pracuje s kratšími vývojovými cykly (sprinty). DevOps tyto tendence posouvá ještě dále – zpětnou vazbu sbírá a reflektuje kontinuálně a propojuje vývoj s provozem.

DevOps a infrastruktura: cloud nebo on-premises?

Každá konceptuální změna ve vývoji softwaru se nutně musí promítnout do infrastruktury, která má být postavena tak, aby podporovala principy DevOps. Pokud se vývoj realizuje na on-premises infrastruktuře, tedy nad vlastním hardware ve vlastních prostorách, je nutné spravovat nejen samotné servery, ale také storage, síť, napájení a případně virtualizaci. To vše s cílem umožnit psát infrastrukturu jako kód (Infrastructure as Code). Taková infrastruktura vyžaduje zkušené správce.

S rostoucími nároky na dovednosti správců IT ale rostou i náklady. A tak není divu, že přesun do cloudu bývá nakonec logickou volbou. Většinu provozních aspektů totiž za zlomek nákladů obstará poskytovatel, protože zajišťuje infrastrukturu jako službu (Infrastructure as a Service).

Odtud už je jen krůček k Platform as a Service (PaaS), kde poskytovatel spravuje veškerou infrastrukturu, runtime prostředí a middle­ware, takže se vývojáři mohou plně soustředit na samotný kód a funkčnost aplikace. Příkladem takových služeb jsou třeba Kubernetes as a Service, Database as a Service a další, které nabízejí:

• možnosti horizontálního škálování, umožňující rozšiřování systému o další instance pro zvýšení výkonu;
• výchozí CI/CD pipeline, kterou lze dále upravovat;
• aktualizovanou, zabezpečenou a udržovanou platformu;
• automatizovanou správu a údržbu.

Osvědčené nástroje pro vývoj a automatizaci

Od infrastruktury se přesuneme k nástrojům, protože právě ty zajistí automatizaci, efektivní správu a monitoring celého vývojového procesu. Nám se nejvíce osvědčily:

Pro infrastrukturu:

• Terraform – nástroj pro definici, vytváření a správu infrastruktury jako kódu. Nasazen může být napříč cloudy i on-premises. Umožňuje automatizaci infrastruktury a funguje skvěle se CI/CD nástroji.
• OpenTofu – open source alternativa Terraformu, která umožňuje definovat infrastrukturu jako kód a automatizovat správu cloudových i on-premises zdrojů.
• Ansible – usnadňuje správu konfigurace a nasazení aplikací.

Pro automatizaci:

• Jenkins – jeden z nejrozšířenějších nástrojů pro automatizaci vývoje. Podporuje různé pluginy, které umožňují integraci s dalšími nástroji.
• GitLab CI/CD – integrovaná funkce v GitLab umožňující automatizaci testování a nasazování přímo z repozitáře.
• GitHub Actions – nabízí automatizaci pracovních postupů přímo v GitHubu, což usnadňuje CI/CD procesy.
• Azure DevOps Services – platforma pro podporu DevOps procesů, která poskytuje nástroje pro správu repozitářů, CI/CD, testování a monitoring. Je vhodná pro správu celého životního cyklu aplikací.
• Argo – sada open source nástrojů pro automatizaci nasazování, správu workflow a lepší škálovatelnost aplikací běžících v Kubernetes.
• Helm – balíčkovací nástroj, který usnadňuje správu a na­sa­zo­vá­ní komplexních Kubernetes aplikací prostřednictvím šablon.

Pro kontejnerizaci:

• Docker – umožňuje vytváření, nasazování a správu aplikací v kontejnerech, což zjednodušuje nasazení a zvyšuje přenositelnost aplikací mezi prostředími.
• Kubernetes – platforma pro orchestraci kontejnerů, zajišťuje automatizaci nasazování, škálování a správu aplikací běžících v kontejnerech.

Pro monitoring a logování:

• Prometheus – nástroj pro monitoring, který shromažďuje a ukládá metriky v reálném čase.
• Grafana – vizualizuje metriky a logy, umožňuje sledování výkonu aplikací a infrastruktury.
• ELK Stack (Elasticsearch, Logstash, Kibana) – shromažďuje, analyzuje a vizualizuje logy z různých systémů.

DevOps prakticky – jak začít

Nyní už máme představu o tom, jak DevOps funguje, na jaké infrastruktuře poběží nejlépe a jaké nástroje může integrovat. Co je ale dále potřeba před zavedením udělat?

1. Vybrat automatizační nástroj pro správu infrastruktury jako kódu a ověřit, že podporuje všechny používané technologie i prostředí a poskytuje dostatečnou modularitu.
2. Definovat objekty, tedy specifikovat jednotlivé komponenty infrastruktury (servery, sítě, databáze) a jejich parametry. Pro snadnou údržbu pak doporučujeme využívat variabilní šablony jako Ansible role a další.
3. Vytvořit CI/CD pipeline pro automatizaci procesu sestavení, testování a nasazení. Jednotlivé kroky se vyplatí definovat v rámci YAML souborů v nástrojích typu GitLab CI/CD nebo Jenkins.
4. Připravit projekt v GitLab, což zahrnuje inicializaci repozitáře, nastavení CI/CD, definici prostředí (dev, staging, production) a určení rolí a oprávnění pro tým.
5. Spustit pipeline, a to buď automaticky při každé změně, nebo ručně, kdy je potřeba. Lze také nastavit pravidla podmínečného spuštění, například po schválení změn nebo nasazení do konkrétního prostředí.
6. Ověřit dokončený kód a reálný výstup nasazený v produkci ideálně včetně funkčního otestování a srovnání s očekávanými výsledky. Manuální nebo automatická validace je důležitá pro bezproblémový běh aplikace.

Časté problémy při zavedení DevOps

V praxi se opakovaně setkáváme s některými problémy s přechodem na DevOps, kterým se ovšem dá předejít. Nejčastěji jde o:

• Nedostatečnou automatizaci – Firmy se potýkají s pomalými procesy, protože vynechaly automatizaci zásadních částí CI/CD pipeline.
• Špatné nastavení CI/CD pipeline – Pipeline obsahují příliš dlouhé fáze buildování či testování nebo naopak nedostatečné testování, které vedou ke zpomalení vývoje a komplikacím při nasazování.
• Nezohledněnou bezpečnost – S myšlenkou na rychlost nasazování se často zapomíná na odstranění bezpečnostních mezer. V procesech by proto neměly chybět bezpečnostní revize.
• Komplexita nástrojů a mikroservisní architektury – Nesprávné nasazení nebo integrace různých nástrojů a nová architektura zvyšuje složitost správy a klade větší nároky na dovednosti správců a potenciálně vede k problémům při škálování a monitoringu.

Pokud jste s přechodem na DevOps úplně na začátku, doporučujeme přechod alespoň konzultovat s někým, kdo má s DevOps zkušenosti. Jedině tak přinese změna vývoje kýžené výsledky – tedy kratší vývojový cyklus a vyšší kvalitu aplikací.

Veronika Jakubová Autorka článku je PR specialistka společnosti MasterDC.