Devops je nyní důležitý v mnoha technologických organizacích kvůli dvěma zdánlivě protichůdným misím a kulturám, které se musí spojit:
- Agilní vývojové týmy postupují rychle, aby splnily obchodní požadavky a implementovaly změny aplikací.
- Provozní týmy tvrdě pracují na tom, aby systémy fungovaly, zajistily zabezpečení výpočetního prostředí a spravovaly výpočetní prostředky.
Agilní týmy často považují provozní týmy za pomalé a rigidní, zatímco systémoví inženýři považují agilní vývojáře za nepodporující provozní potřeby a bezohlednost, když nasazení aplikací způsobí problémy s produkcí.
Jedná se o zevšeobecnění, ale tyto dvě disciplíny mají často různé motivace, terminologii a nástroje - a toto vychýlení může vytvářet obchodní problémy. Například, jak se začínající podniky zvětšují, musí vyvinout provozní postupy k zajištění stability při minimálním dopadu na jejich rychlost a agilitu vývoje. Pro velké podniky musí najít způsoby, jak rychleji dodávat aplikace pro zákazníky a vylepšení interních pracovních toků, aniž by byla ohrožena spolehlivost nebo ztráta souladu s předpisy.
Devops si klade za cíl řešit tyto konflikty kulturou, sadou provozních principů a nově vznikající sadou osvědčených postupů, které umožňují rychlost nasazení aplikací a stabilitu při jejich běhu s méně konflikty a kompromisy. To se do značné míry provádí poskytováním postupů, které automatizují provozní kroky a standardizují konfigurace:
- Pro vývojové týmy tyto postupy standardizují a automatizují kroky od vývoje kódu k testování, zabezpečení a spouštění aplikací v různých prostředích.
- V případě operací postupy automatizují konfiguraci a nasazení infrastruktury, monitorování napříč několika doménami a rychlejší řešení problémů s produkcí.
Mezi postupy Devops patří:
- Strategie řízení verzí a větvení.
- Trvalá integrace a kontinuální dodávka (CI / CD) potrubí.
- Kontejnery, které standardizují a izolují běhová prostředí aplikací.
- Infrastruktura jako kód (IAC), která umožňuje skriptování vrstvy infrastruktury.
- Monitorování vývojových kanálů a stavu spuštěných aplikací.
Devops začíná postupy a nástroji používanými při vydávání softwaru pro výpočet prostředí se základními postupy, které existují již desítky let. Zahrnují řízení verzí pro správu změn kódu napříč týmem vývojářů, rozvětvení kódové základny pro podporu různých vývojových aktivit a verze softwaru pro označování verzí před jejich odesláním do různých prostředí.
Hlavní rozdíly pro devops týmy spočívají v tom, že nástroje se snadněji používají a lépe integrují s jinými technologiemi, které automatizují vytváření a nasazování aplikací. Existuje také více standardizovaných strategií větvení a slučování kódů, které lze snáze spravovat pomocí moderních systémů pro správu verzí.
Například mnoho organizací používá Git (včetně verzí GitHub a BitBucket) a další nástroje pro správu verzí, které nabízejí více klientských aplikací, rozhraní API pro integraci a nástroje příkazového řádku pro správu častějších nebo složitějších postupů. Dnes většina vývojářů používá ve svých projektech alespoň jednu technologii řízení verzí, takže implementace standardů není tak náročná jako dřív.
Organizace využívající tyto nástroje mohou přijmout větvící strategie, jako je Gitflow, které standardizují větve pro produkci, testování a vývoj a zavádějí postupy pro vývoj nových funkcí nebo produkčních oprav. Tyto strategie větvení umožňují týmům spolupracovat na různých typech vývojových potřeb a zavádějí pouze kód, který je testován a lze jej nasadit do produkčních poboček. Týmy pak pomocí označování verzí označí všechny verze zdrojového kódu a dalších souborů, které jsou součástí vydání softwaru.
Většina organizací, které vyžadují uživatelskou podporu po produkčních verzích, a další, které jsou na počátku vývoje svých postupů devops, se často řídí tradičními postupy správy verzí, které podporují konstrukce jako hlavní a vedlejší vydání. Sofistikovanější týmy vyvíjející aplikace, které vyžadují menší podporu uživatelů, mohou procvičovat nepřetržité nasazení, když existuje automatizace, která nepřetržitě integruje a přináší změny kódu do produkčních prostředí.
Aby týmy povolily častější vydání, týmy hledají automatizaci kroků od kontroly v kódu po doručování plně testovaných aplikací do cílových výpočetních prostředí. Continuous integration (CI) is the automation to build and integrate all the software components so that they are in a deployable package. Nástroje pro nepřetržité nasazení (CD) spravují proměnné specifické pro dané prostředí a automatizují tlačící aplikace do vývojových, testovacích, produkčních a dalších výpočetních prostředí. Společně tyto nástroje tvoří kanál CI / CD.
Aby byl CI / CD efektivním automatizačním procesem, musí být implementováno průběžné testování, aby bylo zajištěno, že nový kód nezavádí vady a další problémy. Testy jednotek implementované v kanálu nepřetržité integrace zajišťují, že potvrzený kód neporušuje žádné existující testy jednotek. Další testy, které hledají problémy se zabezpečením na úrovni kódu a strukturu kódu, lze také implementovat v kroku integrace. Automatizované funkce a výkon, které vyžadují běhová prostředí, jsou často automatizovány jako součást kontinuálních dodávacích kanálů.
Tato automatizace řídí mnoho výhodných změn chování a praxe, které týmům umožňují provádět změny častěji a bezpečněji. Vede týmy k častějšímu přihlašování a testování kódu, což umožňuje rychlejší nalezení a vyřešení vad. Postupy ručního nasazení jsou náchylné k chybám, což automatizace do značné míry eliminuje. Automatizace také bere většinu režie při prosazování nových funkcí pro uživatele a umožňuje týmům nasazovat častěji.
Pokud CI / CD poskytuje automatizaci pro doručování aplikací, pak jsou kontejnery obalem operačního prostředí aplikace. Vývojáři mohou zadat operační systém, požadavky na aplikace a požadavky na konfiguraci jako kontejner pro spouštění aplikací v izolované vrstvě, která sdílí operační systém svého hostitele. Docker a Kubernetes jsou kontejnerové technologie, které vývojářům pomáhají definovat prostředí jejich aplikací konzistentním způsobem.
S kanály CI / CD pro integraci a nasazení kódu a se standardizovanými kontejnery, které izolují výpočetní potřeby každé aplikace, mají vývojáři nástroje pro výrobu aplikačních služeb bez velké režie. Vývojové týmy pak mají větší možnosti převést obchodní požadavky do mikroslužeb, které lze nasadit, škálovat a využít pro různé obchodní potřeby.
Vzhledem k tomu, že automatizace integrace a doručování kódů a kontejnerizace aplikací podporují doručování aplikací, pomáhají postupy dalšího vývoje automatizovat a standardizovat infrastrukturu a cloudové služby.
Automatizace a správa infrastruktury bývala obtížná. Jakmile byla vybrána architektura, provozní inženýři šli do různých komponent infrastruktury, aby je vytvořili a nakonfigurovali podle požadavků. Nástroje pro konfiguraci a správu aktiv používané k zachycení těchto architektur vyžadovaly kombinaci automatizovaných a manuálních kroků a byly často zastaralé nebo v nich chyběly důležité informace. Výpočtová prostředí byla také rigidní, a přestože existovaly některé nástroje pro automatizaci škálovacích prostředí, byla často izolována na konkrétní typ infrastruktury, vyžadovala různé dovednosti pro implementaci automatizace a měla přístup pouze k podmnožině provozních dat, aby určila, zda a jak škálovat.
Dnešní cloudová prostředí nabízejí uživatelská rozhraní, která inženýrům zjednodušují práci. Inženýři mohou pomocí těchto nástrojů nastavit virtuální privátní sítě, konfigurovat skupiny zabezpečení a poté spustit výpočetní techniku, úložiště a další požadované služby.
Ale týmy Devops to dělají o krok dále. Namísto použití webových rozhraní a ruční konfigurace výpočetních prostředků automatizují proces pomocí kódu. Nástroje Infrastructure as Code (IaC) umožňují provozním technikům skriptovat a automatizovat nastavení a správu infrastruktury. Konfigurace, které umožňují škálování prostředí nahoru a dolů, lze také vložit do těchto skriptů. Chef, Puppet, Ansible a Salt jsou čtyři konkurenční technologie, které pomáhají implementovat operační týmy při implementaci IaC.
Výrobní proces je jen tak dobrý jako schopnost monitorovat, varovat a zotavovat se z problémů. Totéž platí pro monitorování devops a uživatelské zkušenosti se spuštěním aplikací a služeb. Protože organizace investují do automatizace, kontejnerizace, standardizace a nasazení aplikací, je osvědčeným postupem paralelní investice do monitorování.
Přemýšlejte o monitorování na několika úrovních. Na nejnižší úrovni je monitorování infrastruktury umožňující rozpoznávání a reakce, když výpočetní zdroje nejsou zdravé nebo nedosahují dobrých výsledků. Cloudová prostředí dnes nabízejí funkce pro monitorování, výstrahu a používání elastických cloudových funkcí k řešení problémů s infrastrukturou.
Další vrstva se skládá z nástrojů pro monitorování a snímání metrik kolem automatizace devops. Tyto nástroje se stávají důležitějšími, jak se zvyšuje počet vývojářů a nasaditelných služeb. Tyto nástroje poskytují výstrahy při selhání sestavení a nástroje auditu, které pomáhají diagnostikovat problémy.
Nakonec existují nástroje, které monitorují provozuschopnost aplikace, výkon a další metriky běhového prostředí. Tyto monitorovací nástroje často testují rozhraní API a také provádějí úplné testy prohlížeče na jednotlivých koncových bodech nebo vícestupňových transakcích. Tyto monitory jsou frontální obranou, která upozorňuje týmy devops, když API nebo aplikace fungují mimo přijatelné úrovně služeb.
Existuje mnoho postupů devops a všechny vyžadují čas, aby dospěly a integrovaly se. Jejich implementace nemá předepsaný sled ani tvrdá doporučení, do jaké automatizace investovat.
Organizace by se přesto měly nejprve zaměřit na sladění kultury a myšlení kolem principů devops a poté rozpoznat, jaké postupy nejlépe odpovídají obchodním potřebám. Například organizace, které již mají špatný výkon aplikací, se mohou rozhodnout nejprve implementovat monitorování, aby pomohly rychleji vyřešit problémy a snáze identifikovat hlavní příčiny. Jiné organizace, které začínají s cloudovými migracemi, se mohou rozhodnout nasadit infrastrukturu jako kód, zatímco ty, které zavádějí standardní architektury pro vývoj aplikací, mohou investovat do kanálů CI / CD.
Technologové by měli mít na paměti, že implementace automatizace je nákladná a že ne každá organizace vyžaduje nepřetržité nasazení. Nejlepším postupem je zajistit, aby se nejprve splnily obchodní potřeby, a sladit automatizaci devops do oblastí s vysokým opakováním, kde jsou manuální snahy náchylné k chybám.
