8 klíčových výzev při přijímání devOps: Část 2 - Řešení

V první části (zde) této dvoudílné blogové série jsem se podíval na 8 klíčových výzev, se kterými se organizace potýkají, když přijímají DevOps. Nyní se podívejme na některá řešení.

Změna je na začátku nejtěžší, nejsmutnější uprostřed a nejlepší na konci. - Robin S. Sharma

1.Výrobní funkce kultury podle principů DevOps

Vůdcové DevOps a agenti pro změnu budou muset najít způsoby, jak průběžně vzdělávat týmy a lidi v organizaci o tom, jak vypadá kultura DevOps a proč zrychluje tok hodnoty. Zde jsou některé věci, které jsem zkusil:

Učení a společenství praktik

Personál DevOps může zařídit interní školení nebo úvodní prezentace pro přijetí DevOps a vystavit kulturu DevOps. Tímto způsobem mohou propagovat a setkat se tváří v tvář se všemi v organizaci. Spolupráce tváří v tvář je upřednostňována před používáním e-mailů nebo videokonferencí, protože lidé si tímto způsobem budují důvěru rychleji, takže je-li týmy rozptýleny, doporučuje se provést roadshow s cílem setkat se s každým alespoň jedním, aby se navázaly vztahy.

Znalostní databáze DevOps a časté dotazy

Týmy DevOps mohou vytvořit databázi znalostí nebo často kladené otázky (FAQ) a sdílet je se všemi lidmi v organizaci, takže každý ví, kde získat informace o DevOps, pokud je potřebují. Viditelnost a snadný přístup k informacím, které je motivují k tomu, aby je vyhledávaly a četly samy a dokonce přispívaly. Tento druh informací lze uchovávat na platformách pro spolupráci, jako je Atlassian Confluence nebo Microsoft Teams.

Uplatňování kulturních praktik organizace Westrum

Můžeme použít kulturu v rámci organizace Westrum, abychom vytvořili generativní kulturu, která kultivuje tok dat a důvěru tím, že se podíváme na šest částí modelu hierarchické kultury Westrum a soustředíme se na postupy zjištěné v generativní kultuře;

Zde si můžete vytvořit generativní kulturu;

2.Adresace odolnosti vůči změnám

Vůdci musí očekávat, že lidé budou odolávat změnám. Podle DevOpsologistky Philippy Haleové ve svém článku o nástrojích pro mapování zúčastněných stran a diskutovala o tom, jak můžeme řešit nálady a emoce některých skupin lidí vůči změnám, můžeme použít různé strategie angažovanosti, abychom je mohli přiblížit k iniciativám DevOps. Existuje 6 „profilů chování“ a jak s nimi můžeme spolupracovat, jak je uvedeno níže;

Bez práce

Diváků

Cynici

Kritici

Nadšenci

Advokáti (mistři / experti)

Abychom to shrnuli na základě výše uvedeného, ​​můžeme vidět všechny přístupy k zapojení, které se týkají komunikace a zůstat informováni o přijetí DevOps. Musíme úzce spolupracovat se všemi skupinami a být jim viditelní a poskytnout jim pomoc, kdykoli je potřebují.

3.Výrazná jasnost pro DevOps Vision

Představení rámce DevOps CALMS může pomoci definovat plán a cíle DevOps. CALMS je koncepční rámec pro integraci vývojových a provozních (DevOps) týmů, funkcí a systémů v rámci organizace.

Vůdci DevOps musí vyvinout jasný plán vývoje DevOps s jasnými fázemi vylepšení. Musí ji sdílet a zviditelnit ji v organizaci;

4.Vytváření spolupráce napříč týmy

Vývojové a IT operační týmy se musí naučit spolupracovat. To může znamenat vytvoření týmů s více funkcemi, včetně dev a ops, ale v mnoha organizacích to nefunguje. Je to často příliš dramatická organizační změna, nebo prostě není dost lidí, kteří by se mohli obejít. Tradiční nastavení technologického oddělení také obvykle zahrnuje hluboké odborné znalosti v oblasti IT operací kolem bezpečnosti a vytváření sítí, takže je obtížné zjistit, jak sdílet tyto typy lidí napříč vývojovými nebo produktovými týmy.

Co pomáhá při pravidelném setkání vývojových a IT operačních týmů? Pokud vývojové týmy provádějí každodenní scrumy v rámci svých agilních praktik, může pozvání IT operací k účasti pomoci při odstraňování překážek. Jejich pozvání na plánování sprintu může zajistit, že tyto nefunkční požadavky budou v sprintu zohledněny, čímž se zefektivní proces doručování hodnot.

Komunikační nástroje napříč týmy, jako jsou Slack nebo Microsoft Teams, zde opravdu pomáhají tím, že umožňují, aby spolupráce byla nepřetržitá. Chatovací skupina nebo kanál „Alert / Notification“ musí být také řádně spravována, aby mohly být problémy směrovány na správný tým a rychle eskalovány pomocí správné akce k vyřešení problému / chyby.

Zde je několik nástrojů pro spolupráci, které můžete použít a začít spolupracovat ve své organizaci;

5.Standardizace prostředí

Prostředí je soubor zdrojů nebo cílených míst, která chcete převést z kódu na skutečný produkt potrubím. Prostředí může zahrnovat virtuální stroje (VM), databázové servery, služby třetích stran atd. Níže je uveden příklad fází prostředí s jeho použitím, uživatel / osoba a osoba odpovědná za údržbu prostředí;

Výhody dobře definovaného prostředí zahrnují následující;

  1. Záznam / historie nasazení - Všechny podrobnosti o běhu potrubí jsou zaznamenány v nástrojích CI / CD pro jeho zdroje.
  2. Sledovatelnost - Umožňuje sledovat, zda změna kódu (potvrzení) nebo oprava / oprava chyby (pracovní položky) dosáhly prostředí.
  3. Permission / Control - zabezpečené prostředí určením, který uživatel je povolen a které cílové prostředí se má nasadit.

Poskytování automatizačního prostředí je hlavním faktorem úspěchu v procesu nepřetržitého doručování. Může tým Dev požadovat nové prostředí ad-hoc a je vaše prostředí poskytováno na vyžádání jako nasazení aplikace? Aplikační prostředí lze rozdělit do 3 hlavních oblastí:

1. Infrastruktura

2. Konfigurace

3. Závislosti

Infrastruktura je místo, kde je nasazena aplikace nebo služba a aplikace bude spouštět specifické potřeby konfigurace. Zahrnuje také to, jak se závislosti musí integrovat do aplikace. K dnešnímu dni lze infrastrukturu poskytovat skriptem nebo ji nazývat „Infrastruktura jako kód“ nebo zkráceně IaC. IaC je dnes zpřístupňován prostřednictvím komplexní řady nástrojů dostupných pro automatizaci celého procesu zajišťování prostředí.

Konfigurace je dalším nejvýznamnějším aspektem aplikačního prostředí. Konfigurace určuje, jak aplikace komunikuje v dané infrastruktuře a jak infrastruktura komunikuje ve spojení s podkladovou aplikací.

Závislosti jsou všechny různé moduly nebo systémy, na kterých aplikace závisí, od knihoven po služby nebo jiné aplikace.

Výhoda použití automatizovaného poskytování prostředí následujícím způsobem;

  • Snížená složitost umožněním týmům DevOps pracovat na vyšší úrovni abstrakce.
  • Zvýšená stabilita umožněním aplikacím dynamicky reagovat na jejich nasazení.
  • Zvýšená flexibilita oddělením správy konfigurace od specifického hostitelského prostředí aplikace.

Na trhu máme mnoho nástrojů, ať už je to open-source nebo podnik, které můžeme použít k automatizaci poskytování služeb pro všechny 3 výše uvedené oblasti, například níže;

6.Standardizace DevOps Toolchain a poskytování jako samoobsluhy

Jakmile jsou definovány cíle a procesy adopce DevOps, můžeme určit sadu nástrojů potřebnou pro splnění procesů. Zajistěte, aby vývojové týmy a operační týmy IT spolupracovaly při rozhodování o nástrojích vhodných pro organizaci. S každým zavedeným novým nástrojem musí být stávající pracovníci vyškoleni. Je také nezbytné zajistit, aby nástroje splňovaly požadavky na zabezpečení a byly dobře integrovány do stávajících zdrojů a služeb.

** Stačí uvést několik nástrojů dostupných na trhu pro výše uvedené oddíly.

7. Urychlení správy verzí

Jakmile jsme řádně definovali naše prostředí, musí vůdci DevOps vytvořit řádný propouštěcí kanál, který, když potřebujeme automatickou aktivaci pro nasazení, kdy je potřeba předběžná implementační brána a když je potřeba umístit fázi QA / testování. Na následujícím obrázku je ukázáno základní uvolňovací potrubí s kombinací automatického a manuálního nasazení;

Jakmile budete mít řádný systém uvolňování, automatizaci budov, integraci, testování a dodávku a další procesy, sníží to lidské činnosti v každém vydání, jakož i množství potřebné správy a koordinace.

Protože se zrychlení vývoje stalo konkurenční výhodou, tým DevOps se snažil umožnit kontinuální integraci a kontinuální distribuci (CI / CD). CI / CD pomáhá vývojářům a IT operacím překonat obrovský problém s vývojem a testováním softwaru. V průběhu let se vývoj softwaru přesunul z podnikové úrovně, kde existují velké zdroje, na menší vývojové týmy, které závodí, aby udržely krok s poptávkou generovanou miliardami chytrých telefonů a dalších mobilních spotřebitelských zařízení a platforem. Níže je uveden příklad potrubí CI / CD s kombinací dostupných nástrojů;

V našem případě jsme se rozhodli použít kombinaci nástrojů, protože se zdá, že poskytují nejlepší řešení pro naše složité potřeby. Většina týmů vyvíjejících podnikové produkty by měla z takového přístupu založeného na výhodách. Náš zásobník nástrojů se skládá z:

  1. Atlassian JIRA - nástroj pro týmovou spolupráci z produktového backlogu, plánování sprintu a zprávy o uvolnění a jak dobře se agilnímu týmu daří v každém sprintu.
  2. Github - distribuovaný systém pro správu verzí (DVCS), kde vývojář komunikuje mezi sebou a spolupracuje, aby vylepšil kód funkce produktu a zviditelnil změny a verze kódů. Jakékoli změny musí být zkontrolovány jinými vývojáři nebo revizory kódu, díky kterým byl kód čistší a méně chyb / chyb.
  3. Azure DevOps - je to nástroj, který používáme k organizování našeho plynovodu CI / CD a je to také místo, kde je více spolupráce mezi DevOps Engineer, Developer, Release Manager a týmem QA. Je to také místo, kde dochází k integraci za účelem dodání produktu s dobrou kvalitou, a proto před provedením implementace do produkčního prostředí máme bezpečnostní analýzu a testování kvality.
  4. Datadog - Jedná se o monitorovací nástroj, který s Datadogem můžete monitorovat servery, mraky, metriky, aplikace, tým společně. Je to jako one-stop pro všechny druhy monitorů pro vaše prostředí a produkty.

Efektivní plynovod CI / CD může významně zlepšit čas na uvedení na trh a může přispět k zachování stability a kvality softwaru.

8. Automatické testování

DevOps podporuje automatizaci a jeho cílem je dělat co nejvíce automatizace ze všech každodenních úkolů, které nevyžadují lidské zásahy. Přidání odborníků QA do složení týmu DevOps pomůže týmu rozhodnout o nejlepším přístupu nebo mohou být automatizovány testovací nástroje. Nástroje pro automatizaci obecně fungují, pokud jde o testování chyb aplikací nebo systému, ale testování QA dělá mnohem lepší práci při testování použitelnosti a připravenosti na vydání.

Integrace automatizovaného nepřetržitého testování do vašeho potrubí CI / CD vyžaduje implementaci testování aplikací, která se snadno integruje do sestavení, automatizace testování a implementace CI / CD, které již používáte a která má rozsáhlou podporu webového rozhraní API. Výhoda použití automatického průběžného testování následovně:

Stabilita. Pomáhá vám důsledněji aplikovat požadavky na kvalitu a zabezpečení. Pokud zaznamenáte ruční test zabezpečení a poté jej automatizujete, stane se z toho bezpečnostní požadavek, který můžete vynutit při každém sestavení.

Rychlost. Díky automatickému kontinuálnímu testování využívajícímu škálovatelné nástroje mohou vývojáři najít a doladit problémy v pravém čase v celé SDLC. Urychlí to vývoj aplikací a vyhnete se chybám běžným pro ruční testování.

Stupnice. Chcete-li změnit měřítko ručního testování, potřebujete více ručních testerů. K měřítku automatizovaného testování potřebujete k testování pouze více aplikací a sestav.

Závěr

DevOps Adoption je cesta, která by měla začít analýzou architektury a cílů organizace. Řešení těchto společných výzev v DevOps Adoption způsobí, že transformace bude mnohem plynulejší. Po určité době si každý tým nebo osoba v organizaci zvykne na změny DevOps a přizpůsobí se průběžným procesům učení. Jakmile se týmy pro vývoj, provoz a řízení naučí, jak spolupracovat, automaticky si navzájem pomáhají a úzce spolupracují při archivaci cílů přijetí DevOps.