🥇Sedm nejčastějších chyb při přechodu na CI/CD

Pokud vaše firma teprve zavádí DevOps nebo nástroje CI/CD, může být užitečné seznámit se s nejčastějšími chybami, abyste je nezopakovali a nevstupovali na cizí vidle.

Tým Mail.ru Cloud Solutions přeložila článek Vyhněte se těmto běžným úskalím při přechodu na CI/CD od Jasmine Chokshi s dodatky.

Nepřipravenost na změnu kultury a procesů

Pokud se podíváte na cyklický diagram DevOps, je zřejmé, že v praktikách DevOps je testování nepřetržitou prací, základní součástí každého jednotlivého nasazení.

Nekonečný cyklický diagram DevOps

Testování a zajištění kvality v procesu vývoje a dodávání jsou nedílnou součástí všeho, co dělají vývojáři. To vyžaduje změnu myšlení, aby bylo testování zahrnuto do každého úkolu.

Testování se stává součástí každodenní práce každého člena týmu. Přechod na nepřetržité testování není snadný, je nutné se na to připravit.

Nedostatek zpětné vazby

Účinnost DevOps závisí na neustálé zpětné vazbě. Nepřetržité zlepšování je nemožné, pokud není prostor pro spolupráci a komunikaci.

Firmám, které neorganizují retrospektivní schůzky, se obtížně zavádí kultura neustálé zpětné vazby v CI/CD. Retrospektivní schůzky se konají na konci každé iterace, kde účastníci skupiny diskutují o tom, co proběhlo dobře a co špatně. Retrospektivní schůzky jsou základem Scrum/Agile, ale jsou také nezbytné pro DevOps.

To je dáno tím, že retrospektivní schůzky vytvářejí návyk na výměnu názorů a zpětné vazby. Jedním z nejdůležitějších momentů na začátku je organizace opakovaných retro-schůzek, aby se staly srozumitelnými a běžnými pro celý tým.

Pokud jde o kvalitu softwaru, všichni členové týmu nesou odpovědnost za její udržení. Například vývojáři mohou psát modulové testy a také psát kód s ohledem na testovatelnost, což pomáhá snížit rizika od samého začátku.

Jedním z jednoduchých způsobů, jak odrazit změnu pohledů na testování, je nazývat testery nikoli QA, ale testerem softwaru nebo inženýrem kvality. Tato změna se může zdát příliš jednoduchá nebo dokonce hloupá. Ale pokud někoho nazveme „specialistou na zajištění kvality softwaru“, poskytuje to mylnou představu o tom, kdo nese odpovědnost za kvalitu produktu. V praktikách Agile, CI/CD a DevOps nese odpovědnost za kvalitu softwaru každý.

Dalším důležitým bodem je pochopení toho, co kvalita znamená pro celý tým a pro každého jeho člena, organizaci a zainteresované strany.

Chybné porozumění dokončení fáze

Pokud je kvalita nepřetržitým a společným procesem, je třeba mít společné porozumění dokončení fáze. Jak pochopit, že je fáze ukončena? Co se děje, když je fáze označena jako hotová na desce Trello nebo jiném kanbanovém panelu?

Definice hotové fáze (DoD) je mocným nástrojem v kontextu CD DevOps/CI. Pomáhá lépe porozumět standardům kvality toho, co a jak tým buduje.

Tým vývojářů by měl rozhodnout, co znamená „Hotovo“. Musí se posadit a sestavit seznam vlastností, které musí být splněny v každé fázi, aby mohla být považována za dokončenou.

DoD činí proces transparentnějším a usnadňuje zavádění CI/CD, pokud je jasný všem členům týmu a vzájemně dohodnutý.

Nedostatek realistických, jasně definovaných cílů

To je jeden z nejčastěji citovaných rad, ale je dobré jej zopakovat. Pro úspěch jakéhokoli vážného podniku, včetně zavádění CI/CD nebo DevOps, je třeba stanovit reálné cíle a měřit výkonnost vůči nim. Co se snažíte dosáhnout pomocí CI/CD? Umožňuje to rychlejší vydávání verzí s lepší kvalitou?

Jakékoli stanovené cíle by měly být nejen transparentní a realistické, ale také odpovídat aktuálnímu jednání společnosti. Například, jak často vaši zákazníci potřebují nové opravy nebo verze? Není třeba přeplňovat procesy a vydávat verze rychleji, pokud to nepřináší žádné další výhody pro uživatele.

Kromě toho není vždy nutné implementovat jak CD, tak CI. Například společnosti s vysokou úrovní regulace, jako jsou banky a zdravotnické kliniky, mohou pracovat pouze s CI.

CI je dobrým výchozím bodem pro jakoukoli společnost zavádějící DevOps. Jeho implementace výrazně mění přístupy k dodávání softwaru. Jakmile je CI osvojen, můžete přemýšlet o zlepšení celého procesu, zrychlení nasazování a dalších změnách.

Pro mnoho organizací stačí pouze CI, a CD by mělo být implementováno pouze v případě, že přináší další výhody.

Nedostatek odpovídajících monitorovacích panelů a metrik

Jakmile stanovíte cíle, může tým vývojářů vytvořit monitorovací panel pro měření KPI. Před jeho návrhem je dobré provést hodnocení parametrů, které budou sledovány.

Různé zprávy a aplikace jsou užitečné pro různé členy týmu. Scrum máster se více zajímá o stav a pokrytí. Zatímco vrcholový management může mít zájem o rychlost vyhoření specialistů.

Některé týmy také používají pro hodnocení stavu CI/CD dashboardy s červenými, žlutými a zelenými indikátory, aby věděly, zda dělají vše správně, nebo došlo k chybě. Červená znamená, že je třeba věnovat pozornost tomu, co se děje.

Pokud však informační panely nejsou standardizovány, mohou zavádět v omyl. Analyzujte, jaká data všichni potřebují, a poté vytvořte standardizovaný popis toho, co znamenají. Zjistěte, co dává více smyslu pro zainteresované strany: grafy, text nebo čísla.

Nedostatek manuálních testů

Automatizace testování vytváří základ pro dobrý CI/CD pipeline. Ale automatizované testování na všech fázích neznamená, že byste neměli provádět manuální testování.

Pro vybudování efektivního CI/CD pipeline jsou potřebné také manuální testy. Vždy budou některé aspekty testování, které vyžadují analýzu člověkem.

Stojí za to přemýšlet o integraci úsilí manuálního testování do pipeline. Jakmile je manuální testování některých testovacích příkladů dokončeno, můžete přejít k fázi nasazení.

Nepokoušet se zlepšovat testy

Efektivní CI/CD pipeline vyžaduje přístup k potřebným nástrojům, ať už se jedná o správu testování nebo integraci a kontinuální monitorování.

Vytváření silné, na kvalitu orientované kultury se zaměřuje na implementaci testů, monitorování interakcí se zákazníky po nasazení a sledování vylepšení.

Zde je několik praktických tipů, které můžete snadno implementovat:

Ujistěte se, že testy jsou snadné na napsání a dostatečně flexibilní, aby se nezhroutily při refaktoringu kódu.
Vývojové týmy by měly být zahrnuty do procesu testování – vidět seznam uživatelských problémů a požadavků, které jsou důležité k ověření během CI pipeline.
Možná nebudete mít úplné pokrytí testy, ale vždy zajistěte, aby proudy důležité pro UX a interakci se zákazníky byly testovány.

Poslední, ale neméně důležitý bod

Přechod na CI/CD je obvykle iniciován zdola nahoru, ale nakonec je to transformace, která vyžaduje zapojení vedení, čas a zdroje ze strany společnosti. CI/CD je soubor dovedností, procesy, nástroje a kulturní přestavba, kterou lze implementovat pouze systematicky.

Co dalšího si přečíst na toto téma:

Zdroj: habr.com