Ak vaša spoločnosť len zavádza DevOps alebo nástroje CI/CD, môže byť užitočné zoznámiť sa s najbežnejšími chybami, aby ste ich nepremieňali a nezopakovane nerobily rovnaké chyby.
Tím preložila článok .
Nedostatočná pripravenosť na zmenu kultúry a procesov
Ak sa pozriete na cyklický diagram , je zjavné, že v praktikách DevOps je testovanie nepretržitou činnosťou, základnou súčasťou každého jednotlivého nasadenia.
Nekonečný cyklický diagram DevOps
Testovanie a zabezpečenie kvality v procese vývoja a dodávky sú neodmysliteľnou súčasťou všetkého, čo robia vývojári. To si vyžaduje zmenu myslenia, aby sa testovanie stalo súčasťou každého úlohy.
Testovanie sa stáva súčasťou každodennej práce každého člena tímu. Prechod na nepretržité testovanie nie je jednoduchý, je potrebné na to byť pripravený.
Nedostatok spätnej väzby
Účinnosť DevOps závisí od nepretržitej spätnej väzby. Neustále zlepšovanie je nemožné, ak neexistuje priestor na spoluprácu a komunikáciu.
Firmám, ktoré neorganizujú retrospektívne stretnutia, sa ťažko podarí zaviesť kultúru nepretržitej spätnej väzby v CI/CD. Retrospektívne stretnutia sa konajú na konci každej iterácie, kde skupinoví účastníci diskutujú o tom, čo prebehlo dobre a čo zle. Retrospektívne stretnutia sú základom Scrum/Agile, ale sú potrebné aj pre DevOps.
Je to preto, že retrospektívne stretnutia vytvárajú zvyk vymieňať si názory a spätnú väzbu. Jeden z najdôležitejších aspektov na začiatku je organizácia opakujúcich sa retro-stretnutí, aby sa stali zrozumiteľnými a bežnými pre celý kolektív.
Pokiaľ ide o kvalitu softvéru, všetci členovia tímu sú zodpovední za jej udržiavanie. Napríklad, vývojári môžu písať modulárne testy a tiež písať kód s ohľadom na testovateľnosť, čím pomáhajú znižovať riziká od samého začiatku.
Jedným z jednoduchých spôsobov, ako odrážať zmenu predstáv o testovaní, je nazývať testerov nie QA, ale testerom softvéru alebo inžinierom kvality. Táto zmena sa môže zdať príliš jednoduchá alebo dokonca hlúpa. Ale ak niekoho nazývame „špecialistom na zabezpečenie kvality softvéru“, dáva to nesprávny obraz o tom, kto je zodpovedný za kvalitu produktu. V praktikách Agile, CI/CD a DevOps nesú všetci zodpovednosť za kvalitu softvéru.
Ďalším dôležitým aspektom je pochopenie toho, čo znamená kvalita pre celý tím a každého jeho člena, organizáciu, zainteresované strany.
Nesprávne pochopenie dokončenia etapy
Ak je kvalita nepretržitým a spoločným procesom, potrebujeme spoločné pochopenie dokončenia etapy. Ako zistiť, že etapa je dokončená? Čo sa stane, keď je etapa označená ako dokončená na doske Trello alebo inej kanban doske?
Definícia dokončenej etapy (DoD) je mocným nástrojom v kontexte CD DevOps/CI. Pomáha lepšie pochopiť štandardy kvality toho, čo a ako tím vybudoval.
Tím vývojárov by mal rozhodnúť, čo znamená „Hotovo“. Musia sa posadiť a zostaviť zoznam charakteristík, ktoré musia byť splnené v každej etape, aby ju bolo možné považovať za dokončenú.
DoD robí proces transparentnejším a uľahčuje implementáciu CI/CD, ak je jasný všetkým členom tímu a navzájom dohodnutý.
Nedostatok realistických, jasne definovaných cieľov
Je to jeden z najčastejšie citovaných rád, ale stojí za to ho zopakovať. Pre úspech akejkoľvek vážnej iniciatívy, vrátane implementácie CI/CD alebo DevOps, je potrebné nastaviť reálne ciele a merať výkonnosť vo vzťahu k nim. Čo sa snažíte dosiahnuť pomocou CI/CD? Umožňuje to rýchlejšie vydávanie verzií s lepšou kvalitou?
Akékoľvek stanovené ciele musia byť nielen transparentné a realistické, ale aj zodpovedať súčasnej činnosti spoločnosti. Napríklad, ako často potrebujú vaši zákazníci nové opravy alebo verzie? Nie je potrebné preťažovať procesy a vydávať verzie rýchlejšie, ak to neprináša dodatočné výhody pre používateľov.
Okrem toho nemusíte vždy implementovať CD aj CI. Napríklad firmy s vysokou reguláciou, ako sú banky a zdravotnícke kliniky, môžu pracovať iba s CI.
CI je dobrým východiskovým bodom pre akúkoľvek spoločnosť, ktorá zavádza DevOps. Jeho implementáciou sa zásadne menia prístupy k dodávke softvéru. Po osvojení CI je možné premýšľať o zlepšení celého procesu, zrýchlení nasadenia a iných zmenách.
Pre mnohé organizácie stačí jedno CI a CD by sa malo implementovať iba v prípade, že prináša ďalšie výhody.
Nedostatok príslušných monitorovacích panelov a metrik
Akonáhle máte stanovené ciele, tím vývojárov môže vytvoriť panel na sledovanie KPI. Pred jeho vypracovaním je vhodné vykonať hodnotenie parametrov, ktoré budú sledované.
Rôzne správy a aplikácie sú užitočné pre rôznych členov tímu. Scrum masterov viac zaujíma stav a pokrytie. Zatiaľ čo vrcholovému manažmentu môže byť zaujímavá rýchlosť vyhorenia odborníkov.
Niektoré tímy tiež používajú na hodnotenie stavu CI/CD dashboardy s červenými, žltými a zelenými ukazovateľmi, aby pochopili, či všetko robia správne alebo sa vyskytla chyba. Červená znamená, že si treba dať pozor na to, čo sa deje.
Avšak, ak informačné panely nie sú štandardizované, môžu zavádzať. Analyzujte, aké dáta sú potrebné pre všetkých, a potom vytvorte štandardizovaný popis toho, čo znamenajú. Zistite, čo má pre zainteresované strany väčší zmysel: grafy, text alebo čísla.
Nedostatok manuálnych testov
Automatizácia testovania kladie základy pre dobrý CI/CD pipeline. Ale automatizované testovanie vo všetkých fázach neznamená, že by ste nemali vykonávať manuálne testovanie.
Na vybudovanie efektívneho CI/CD pipeline sú potrebné aj manuálne testy. Vždy budú určité aspekty testovania, ktoré si vyžadujú analýzu človeka.
Stojí za to uvažovať o integrácii úsilia v oblasti manuálneho testovania do pipeline. Po dokončení manuálneho testovania niektorých testovacích scénarov môžete prejsť na fázu nasadenia.
Nepokúšať sa zlepšovať testy
Efektívny CI/CD kanál vyžaduje prístup k potrebným nástrojom, či už ide o riadenie testovania alebo integráciu a neustále monitorovanie.
Vytvorenie silnej kultúry zameranej na kvalitu sa sústreďuje na , monitorovanie interakcie s klientmi po nasadení a sledovanie zlepšení.
Tu je niekoľko praktických tipov, ktoré môžete ľahko implementovať:
- Uistite sa, že testy sú jednoduché na písanie a dostatočne flexibilné, aby sa nerozbili pri refaktorovaní kódu.
- Tímy vývojárov by mali byť zapojené do procesu testovania — vidieť zoznam problémov a požiadaviek používateľov, ktoré sú dôležité na overenie počas CI kanálov.
- Nemusíte mať úplné pokrytie testami, ale vždy dbajte na to, aby tok, ktorý je dôležitý pre užívateľskú skúsenosť a interakciu s klientmi, bol otestovaný.
Posledný, ale nemenej dôležitý bod
Prechod na CI/CD je zvyčajne iniciovaný zospodu nahor, ale nakoniec je to transformácia, ktorá vyžaduje účasť vedenia, časové a zdrojové náklady zo strany spoločnosti. Predsa len, CI/CD je súbor zručností, procesy, nástroje a kultúrne prebudovanie, takéto zmeny je možné implementovať len systematicky.
Čo ďalšie si prečítať na túto tému:
- .
- .
- .
Zdroj: habr.com
