Programování

5 běžných nástrah CI / CD - a jak se jim vyhnout

Devops může být jedním z nejnebezpečnějších výrazů ve vývoji softwaru, ale většina z nás souhlasí s tím, že díky devíti činnostem se devops stává tím, čím je: nepřetržitá integrace, nepřetržité doručování, cloudová infrastruktura, automatizace testů a správa konfigurace. Pokud uděláte těchto pět věcí, uděláte devops. Je zřejmé, že všech pět je důležitých pro správné rozhodnutí, ale je příliš snadné se pokazit. Zejména nepřetržitá integrace a nepřetržité doručování (CI / CD) mohou být nejobtížnějšími devopy pohyby, které je třeba zvládnout.

Kontinuální integrace (CI) je proces, při kterém vývojáři a testeři společně ověřují nový kód. Vývojáři tradičně psali kód a integrovali jej jednou za měsíc pro testování. To bylo neefektivní - chyba v kódu z doby před čtyřmi týdny by mohla vývojáře přinutit k revizi kódu napsaného před týdnem. K překonání tohoto problému závisí CI na automatizaci, aby mohla průběžně integrovat a testovat kód. Scrum týmy používající CI se dopouštějí minimálně denně, zatímco většina z nich se dopouští kódu pro každou zavedenou změnu.

Kontinuální doručování (CD) je proces nepřetržitého vytváření uvolnitelných artefaktů. Některé společnosti vydávají uživatelům jednou nebo dokonce několikrát denně, zatímco jiné vydávají software pomalejším tempem z tržních důvodů. V každém případě je schopnost uvolňování průběžně testována. Kontinuální rozvinutí je možné díky cloudovým prostředím. Servery jsou nastaveny tak, že je můžete nasadit do produkce bez nutnosti vypínání a ruční aktualizace serverů.

CI / CD je tedy proces pro nepřetržitý vývoj, testování a dodávání nového kódu. Některé společnosti jako Facebook a Netflix používají CI / CD k dokončení 10 nebo více vydání týdně. Jiné společnosti se snaží dosáhnout tohoto tempa, protože podlehnou jedné nebo více z pěti nástrah, o kterých si ještě povím.

Úskalí CI / CD # 1: Nejprve automatizujte nesprávné procesy

Tato past má tendenci udeřit organizacím, které posunuly od vývoje vodopádu k devopsům. Nové organizace mají tu výhodu, že implementují CI / CD od nuly. Stávající společnosti musí postupovat od manuálního k vysoce automatizovanému vývoji. Úplný přechod může trvat několik měsíců, což znamená, že při přijímání CI / CD musíte být iterativní.

Když se zeptáte: „Je třeba to teď automatizovat?“ projděte si následující kontrolní seznam:

  1. Jak často se postup nebo scénář opakuje?
  2. Jak dlouhý je proces?
  3. Jaké osoby a závislosti na zdrojích jsou do procesu zapojeny? Způsobují zpoždění v CI / CD?
  4. Je proces náchylný k chybám, pokud není automatizovaný?
  5. Jaká je naléhavost při automatizaci procesu?

Pomocí tohoto kontrolního seznamu můžete upřednostnit kroky implementace CI / CD. Nejdůležitější je automatizovat proces kompilace kódu. V ideálním případě integrujete kód několikrát denně (1). Ručně proces trvá několik minut až několik hodin (2). To zastaví výstup, dokud kompilátor nedokončí úkol (3). Je také náchylný k lidské chybě (4), a protože CI / CD je sen bez automatické integrace, je to naléhavé (5).

Při testování můžeme spustit stejný kontrolní seznam. Při přechodu na CI / CD by vás mohlo zajímat: Měli bychom nejprve automatizovat funkční testování nebo testování uživatelského rozhraní? Obojí se bude opakovat alespoň jednou denně (1). U středně velké aplikace může obě trvat dvě až tři hodiny (2). Ale zahrnují více závislostí (3). Pokud automatizujete funkční testování, možná nebudete muset často aktualizovat automatizační skript. Uživatelské rozhraní se na druhou stranu často mění, a proto vyžaduje časté změny skriptu. I když jsou oba náchylné k chybám (4), měli byste upřednostnit funkční testování před testováním uživatelského rozhraní, abyste co nejlépe využili své zdroje (5).

Pojďme to udělat ještě jednou s procesem nastavení prostředí. Tento scénář se opakuje pouze často, pokud jste na nájemném řádění nebo máte silnou vířivku (1). Je to poměrně časově náročný proces, který může trvat několik hodin, ne-li dní (2). Noví členové týmu nemohou dělat nic užitečného bez prostředí, takže jasně existuje závislost a zpoždění (3). Neřekl bych, že tento proces je náchylný k chybám (4), je tedy stále urgentní (5)? Přikláním se k ano, ale nejprve bych dal přednost integraci a funkčnímu testování.

Neexistuje nic jako overautomating. Pokud byste měli neomezené zdroje, automatizovali byste všechno možné. To znamená, že ty nemůže dosáhnout úplné automatizace testů. Někdy můžete úkoly rozdělit na menší segmenty a automatizovat v opravách. Někdy byste měli jednoduše podrobně dokumentovat proces a provést jej ručně.

Úskalí CI / CD č. 2: Matoucí nepřetržité nasazení pro nepřetržité doručování

Kontinuální nasazení je koncept, že každá změna provedená v kódové základně bude nasazena téměř okamžitě do výroby, pokud budou výsledky kanálu úspěšné. To je pro většinu organizací děsivé, protože rychlé změny produktů mohou uživatele odradit.

Společnosti se domnívají, že pokud neprovádějí nepřetržité nasazování, nedělají CD. Nedokáží rozlišovat mezi nepřetržitým nasazováním a nepřetržitým doručováním.

Kontinuální doručování je koncept, že každá změna základny kódu prochází potrubím až do bodu nasazení do neprodukčních prostředí. Tým vyhledá a řeší problémy okamžitě, ne později, když plánuje vydání kódové základny.

Kódová základna je vždy na úrovni kvality, která je bezpečná pro vydání. Když uvolnit kódovou základnu do výroby je obchodní rozhodnutí.

Zatímco nepřetržité nasazení znepokojuje většinu organizací, nepřetržité doručování v nich rezonuje. Kontinuální dodávka jim dává kontrolu nad zaváděním produktu, funkčností a rizikových faktorů. Je čas na testování alfa verze, pro zákazníky verze beta, pro začátečníky atd.

Úskalí CI / CD č. 3: Nedostatek smysluplných řídicích panelů a metrik

V implementacích CI / CD může scrum tým vytvořit dashboard, než členové vědí, co potřebují sledovat. Výsledkem je, že tým propadl logickému klamu: „Toto jsou metriky, které máme, takže musí být důležité.“ Místo toho proveďte postupné hodnocení před návrh palubní desky.

Různí členové IT organizace, a dokonce i různí členové scrum týmu, mají různé priority. Například lidé v síťovém operačním středisku (NOC) milují červené, žluté a zelené indikátory. Takové řídicí panely semaforu umožňují pracovníkům NOC rozlišovat problémy bez čtení hustého textu nebo zdanění jejich analytických schopností. Semafory pomáhají spravovat stovky serverů.

Možná budete v pokušení použít řídicí panel semaforu také pro CI / CD. Zelená, jsme na správné cestě. Žlutá, jsme mimo trať, ale máme plán, jak to vyřešit. Červeně, jsme mimo trať a pravděpodobně budeme muset změnit naše cíle.

Ten dashboard je pravděpodobně užitečný pro mistra scrumů, ale co VP vývoje nebo CTO? Pokud má skrumážní tým před dvoutýdenním sprintem 350 hodin práce a jeho 10 členů odpovídá za každý 35 hodin, získal by odpovídající počet bodů příběhu. Vyšší vedení by se mohlo méně zajímat o stav příběhových bodů a více by se zajímalo o míru „burndown“: rychlost dokončení úkolu. Nosí členové týmu své náklady? Jak rychle? Zlepšují se v průběhu času?

Míra vyčerpání by bohužel mohla být zavádějící, pokud různé zúčastněné strany nerozumí dohodnutým zvykům scrum týmu. Některé týmy spálí body hned, jak jdou. Ostatní čekají, až se blíží konec sprintu, aby vypálili otevřené body. Řídicí panel by to měl vzít v úvahu.

Pokud můžete posoudit, jaká data všichni chtějí, a vytvořit standardní popis toho, co tato data znamenají, můžete navrhnout užitečný řídicí panel. Ale neobsedujte nad látkou na úkor vzhledu. Zeptejte se, jak to zainteresované strany chtějí. Byly by nejlepší grafy, text nebo čísla?

Toto jsou úvahy, které je třeba prozkoumat při postupném hodnocení. Ilustrují, jak složité je vytvořit užitečný řídicí panel CI / CD - a udělat radost každému. Nejhlasitější člen týmu proces příliš často unese a ostatní se cítí frustrovaní, že řídicí panel splňuje preference pouze jedné osoby. Poslouchejte všechny.

Úskalí CI / CD č. 4: Nedostatek koordinace mezi kontinuální integrací a nepřetržitým doručováním

Tato úskalí nás vrací zpět k naší konsensuální definici devops, která tvrdí, že nepřetržitá integrace a nepřetržité doručování jsou dvě různé položky. CI krmení CD. Implementace slušného kanálu kontinuální integrace a úplného systému nepřetržitého doručování trvá měsíce a vyžaduje spolupráci. Zajištění kvality, tým devopsů, technici ops, mistři scrumů - všichni musí přispět. Snad nejnáročnějším aspektem CI / CD je spíše tento lidský faktor než jakákoli technická výzva, o které jsme diskutovali. Stejně jako nemůžete naprogramovat zdravý vztah mezi dvěma lidmi, nemůžete automatizovat spolupráci a komunikaci.

Chcete-li měřit tuto úroveň koordinace, porovnejte svůj proces CI / CD s nejlepšími v oboru. Společnosti jako Netflix mohou dokončit integraci, testování a dodání za dvě až tři hodiny. Vytvořili systém, který předává kód z ruky do ruky bez nerozhodnosti a diskuse. Ne, není to stoprocentně automatizované, protože to je při současné technologii nemožné.

Úskalí CI / CD č. 5: Vyvážení frekvence spouštění úloh nepřetržité integrace a využití zdrojů

Úlohy kontinuální integrace se mají spouštět pro každou změnu, která je zavedena v kódu. Úspěšné úlohy umožňují projít změnami, zatímco selhání je odmítne. To povzbuzuje vývojáře, aby se přihlásili k menším částem kódu a spustili více sestavení za den. Nepotřebné úlohy nepřetržité integrace však spotřebovávají zdroje, což plýtvá časem a penězi.

Protože tento proces vyžaduje velké využití zdrojů (CPU, výkon, čas), měl by být software rozdělen na menší součásti, aby se vytvořily rychlejší kanály. Nebo by úlohy kontinuální integrace měly být navrženy tak, aby dávkové odbavení byly nejprve testovány lokálně. Cílem je najít rovnováhu mezi frekvencí provádění úloh kontinuální integrace a využíváním zdrojů.

Udržujte cíl v dohledu

Když se ponoříme do úskalí CI / CD - včetně veškeré jeho esoterické terminologie - je snadné ztratit ze zřetele proč na tom záleží. Nakonec je CI / CD zásadní, protože splňuje obchodní cíle.

Vedoucí pracovníci technologií vědí, že neustálý vývoj, rychlé opravy a kvalitní výsledky vytvářejí a udržují zákazníky. Vědí, že neúspěšné vydání zve bludgeon k recenzím App Store, a znovu získat vysoké recenze je těžší než si je ponechat. Devops může vytvořit lepší pracovní prostředí pro váš tým, ale to není důvod, proč společnosti implementují devops.

Jednoduše řečeno, nástrahy CI / CD stojí za přezkoumání, protože v sázce jsou miliardy dolarů. I když vám nedoporučuji, abyste na svůj řídicí panel CI / CD přidali burzovní lístek nebo sledovač recenzí App Store, naléhavě vás žádám, abyste toho věděli. Hodně záleží na podrobnostech CI / CD.

Zubin Irani je spoluzakladatelem a generálním ředitelem společnosti cPrime, poradenské služby v oblasti kompletních služeb, která provádí agilní transformace a poskytuje agilní řešení pro více než 50 společností ze žebříčku Fortune 100 a mnoho z největších zaměstnavatelů v Silicon Valley.

Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na [email protected].

$config[zx-auto] not found$config[zx-overlay] not found