Ako vaša kompanija tek uvodi DevOps ili CI/CD alate, možda će vam biti korisno da se upoznate sa najčešćim greškama kako ih ne biste ponovili i ne zgazili tuđe grablje.
tim preveo članak .
Nespremnost za promjenu kulture i procesa
Ako pogledate ciklički dijagram , jasno je da je u DevOps praksama testiranje kontinuirana aktivnost, temeljni dio svake pojedinačne implementacije.
DevOps grafikon beskonačnog ciklusa
Testiranje i osiguranje kvaliteta tokom razvoja i isporuke su suštinski dio svega što programeri rade. Ovo zahtijeva promjenu načina razmišljanja kako bi se testiranje uključilo u svaki zadatak.
Testiranje postaje dio svakodnevnog rada svakog člana tima. Prelazak na konstantno testiranje nije lak, na to morate biti spremni.
Nedostatak povratnih informacija
DevOps efikasnost zavisi od stalnih povratnih informacija. Kontinuirano poboljšanje je nemoguće ako nema prostora za saradnju i komunikaciju.
Kompanije koje ne organizuju retrospektivne sastanke smatraju da je teško implementirati kulturu kontinuiranih povratnih informacija u CI/CD. Retrospektivni sastanci se održavaju na kraju svake iteracije, tokom kojih članovi tima razgovaraju o tome šta je prošlo dobro, a šta loše. Retrospektivni sastanci su temelj Scrum/Agile-a, ali su neophodni i za DevOps.
To je zato što retrospektivni sastanci usađuju naviku razmjene povratnih informacija i mišljenja. Jedna od najvažnijih tačaka na početku je organiziranje ponavljajućih retro sastanaka kako bi postali razumljivi i poznati cijelom timu.
Kada je u pitanju kvalitet softvera, svi članovi tima su odgovorni za njegovo održavanje. Na primjer, programeri mogu pisati jedinične testove i također pisati kod imajući na umu mogućnost testiranja, pomažući u smanjenju rizika od samog početka.
Jedan jednostavan način da se odrazi promjena u razmišljanju o testiranju je pozivanje testera ne QA, već testera softvera ili inženjera kvaliteta. Ova promjena može izgledati previše jednostavna ili čak glupa. Ali nazivanje nekoga "osobom za osiguranje kvaliteta softvera" daje pogrešnu ideju o tome ko je odgovoran za kvalitet proizvoda. U Agile, CI/CD i DevOps praksama svi su odgovorni za kvalitet softvera.
Još jedna važna stvar je razumjeti šta kvalitet znači za cijeli tim i svakog njegovog člana, organizaciju i dionike.
Nerazumijevanje završetka faze
Ako je kvalitet kontinuiran i opći proces, potrebno je zajedničko razumijevanje završetka faze. Kako znate kada je faza gotova? Šta se događa kada je korak označen kao završen na Trello ili drugoj Kanban ploči?
Definicija gotovog (DoD) je moćan alat u kontekstu CD DevOps/CI. Pomaže da se bolje razumiju standardi kvaliteta onoga što i kako tim gradi.
Razvojni tim mora odlučiti šta znači "Gotovo". Oni treba da sjednu i naprave listu karakteristika koje moraju biti ispunjene u svakoj fazi da bi se ona smatrala potpunom.
DoD čini proces transparentnijim i olakšava implementaciju CI/CD-a ako ga razumiju svi članovi tima i međusobno se slažu.
Nedostatak realnih, jasno definisanih ciljeva
Ovo je jedan od najčešće citiranih savjeta, ali ga vrijedi ponoviti. Da biste uspjeli u bilo kojem velikom poduhvatu, uključujući CI/CD ili DevOps, morate postaviti realne ciljeve i mjeriti učinak u odnosu na njih. Šta pokušavate postići sa CI/CD? Omogućuje li to brža izdanja s boljim kvalitetom?
Svi postavljeni ciljevi moraju biti ne samo transparentni i realni, već i u skladu sa trenutnim aktivnostima kompanije. Na primjer, koliko često vašim klijentima trebaju nove zakrpe ili verzije? Nema potrebe za preopterećenjem procesa i bržim oslobađanjem ako nema dodatne koristi za korisnike.
Osim toga, ne morate uvijek implementirati i CD i CI. Na primjer, visoko regulirane kompanije kao što su banke i medicinske klinike mogu raditi samo s CI.
CI služi kao dobra polazna tačka za svaku kompaniju koja implementira DevOps. Kada se implementira, pristupi kompanija u isporuci softvera značajno se mijenjaju. Kada se CI savlada, možete razmišljati o poboljšanju cijelog procesa, povećanju brzine uvođenja i drugim promjenama.
Za mnoge organizacije dovoljan je samo CI, a CD treba implementirati samo ako dodaje vrijednost.
Nedostatak odgovarajućih kontrolnih tabli i metrike
Nakon što postavite svoje ciljeve, razvojni tim može kreirati kontrolnu tablu za mjerenje KPI-ja. Prije njegovog razvoja vrijedi procijeniti parametre koji će se pratiti.
Različiti izvještaji i aplikacije korisni su za različite članove tima. Scrum Mastera više zanima status i doseg. Dok viši menadžment može biti zainteresovan za stopu sagorevanja stručnjaka.
Neki timovi također koriste kontrolne ploče s crvenim, žutim i zelenim indikatorima kako bi procijenili status CI/CD-a kako bi shvatili da li sve rade kako treba ili postoji greška. Crvena znači da morate obratiti pažnju na ono što se dešava.
Međutim, ako kontrolne ploče nisu standardizirane, mogu dovesti u zabludu. Analizirajte koji su podaci svima potrebni, a zatim kreirajte standardizirani opis onoga što oni znače. Saznajte šta ima više smisla za zainteresovane strane: grafika, tekst ili brojevi.
Nema ručnih testova
Automatizacija testiranja postavlja temelje za dobar CI/CD cevovod. Ali automatsko testiranje u svim fazama ne znači da ne biste trebali provoditi ručno testiranje.
Da biste izgradili efikasan CI/CD cevovod, potrebni su vam i ručni testovi. Uvijek će postojati neki aspekti testiranja koji zahtijevaju analizu ljudi.
Vrijedi razmisliti o integraciji pokušaja ručnog testiranja u vaš cjevovod. Kada se završi ručno testiranje nekih test slučajeva, možete prijeći na fazu implementacije.
Ne pokušavajte poboljšati testove
Efikasan CI/CD cevovod zahteva pristup pravim alatima, bilo da se radi o upravljanju testovima ili integraciji i stalnom praćenju.
Stvaranje jake kulture orijentirane na kvalitetu ima za cilj , praćenje interakcije korisnika nakon implementacije i praćenje poboljšanja.
Evo nekoliko praktičnih savjeta koje možete lako primijeniti:
- Provjerite jesu li vaši testovi laki za pisanje i dovoljno fleksibilni da se ne pokvare kada refaktorirate kod.
- Razvojni timovi bi trebali biti uključeni u proces testiranja - pogledajte listu korisničkih problema i zahtjeva koje je važno testirati tokom CI cevovoda.
- Možda nemate potpunu pokrivenost testom, ali uvijek osigurajte da se testiraju tokovi koji su važni za UX i korisničko iskustvo.
Posljednja, ali ne i najmanje važna stvar
Prelazak na CI/CD obično se pokreće odozdo prema gore, ali u konačnici to je transformacija koja zahtijeva podršku vodstva, vrijeme i resurse kompanije. Na kraju krajeva, CI/CD je skup vještina, procesa, alata i kulturnog restrukturiranja; takve promjene se mogu provoditi samo sistematski.
Šta još pročitati na temu:
- .
- .
- .
izvor: www.habr.com