Ako vaša tvrtka tek uvodi DevOps ili CI/CD alate, moglo bi biti korisno da se upoznate s najčešćim pogreškama kako ih ne biste ponavljali i ne stali na tuđe rake.
Momčad preveo članak .
Nespremnost na promjenu kulture i procesa
Ako pogledate ciklički dijagram , jasno je da je u DevOps praksi testiranje stalna aktivnost, temeljni dio svake pojedinačne implementacije.
DevOps grafikon beskonačnog ciklusa
Testiranje i osiguranje kvalitete tijekom razvoja i isporuke ključni su dio svega što programeri rade. To zahtijeva promjenu načina razmišljanja kako bi se testiranje uključilo u svaki zadatak.
Testiranje postaje dio svakodnevnog rada svakog člana tima. Prijelaz na stalna testiranja nije lak, na to treba biti spreman.
Nedostatak povratnih informacija
Učinkovitost DevOps-a ovisi o stalnim povratnim informacijama. Neprekidno usavršavanje nemoguće je ako nema prostora za suradnju i komunikaciju.
Tvrtke koje ne organiziraju retrospektivne sastanke teško mogu implementirati kulturu kontinuirane povratne informacije u CI/CD. Na kraju svake iteracije održavaju se retrospektivni sastanci, tijekom kojih članovi tima raspravljaju o tome što je prošlo dobro, a što loše. Retrospektivni sastanci su temelj Scrum/Agilea, ali su također neophodni za DevOps.
To je zato što retrospektivni sastanci usađuju naviku razmjene povratnih informacija i mišljenja. Jedna od najvažnijih točaka na početku je organiziranje ponavljajućih retro sastanaka kako bi postali razumljivi i poznati cijelom timu.
Što se tiče kvalitete softvera, svi članovi tima odgovorni su za njezino održavanje. Na primjer, programeri mogu pisati jedinične testove i također pisati kod imajući na umu sposobnost testiranja, pomažući smanjiti rizik od samog početka.
Jedan jednostavan način da se odrazi promjena u razmišljanju o testiranju jest da se testeri ne nazovu QA-om, već testerom softvera ili inženjerom kvalitete. Ova se promjena može činiti prejednostavnom ili čak glupom. Ali nazvati nekoga "osobom za osiguranje kvalitete softvera" daje krivu ideju o tome tko je odgovoran za kvalitetu proizvoda. U praksi Agile, CI/CD i DevOps svatko je odgovoran za kvalitetu softvera.
Još jedna važna stvar je razumjeti što kvaliteta znači za cijeli tim i svakog njegovog člana, organizaciju i dionike.
Nesporazum završetka faze
Ako je kvaliteta kontinuiran i opći proces, potrebno je zajedničko razumijevanje završetka faze. Kako znaš da je pozornica gotova? Što se događa kada je korak označen kao dovršen na Trello ili drugoj Kanban ploči?
Definicija gotovog (DoD) moćan je alat u kontekstu CD DevOps/CI. Pomaže boljem razumijevanju standarda kvalitete onoga što i kako tim gradi.
Razvojni tim mora odlučiti što znači "Gotovo". Trebaju sjesti i napraviti popis karakteristika koje moraju biti zadovoljene u svakoj fazi da bi se smatrala potpunom.
DoD čini proces transparentnijim i olakšava implementaciju CI/CD-a ako ga svi članovi tima razumiju i s njim se međusobno slažu.
Nedostatak realnih, jasno definiranih ciljeva
Ovo je jedan od najčešće citiranih savjeta, ali vrijedi ga ponoviti. Da biste uspjeli u bilo kojem većem pothvatu, uključujući CI/CD ili DevOps, trebate postaviti realne ciljeve i mjeriti izvedbu prema njima. Što pokušavate postići s CI/CD? Omogućuje li to brža izdanja s boljom kvalitetom?
Svi postavljeni ciljevi ne samo da moraju biti transparentni i realni, već moraju biti i usklađeni s trenutnim aktivnostima tvrtke. Na primjer, koliko često vaši kupci trebaju nove zakrpe ili verzije? Nema potrebe preopteretiti procese i izdati brže ako nema dodatne koristi za korisnike.
Osim toga, ne morate uvijek implementirati i CD i CI. Na primjer, visoko regulirane tvrtke poput banaka i medicinskih klinika mogu raditi samo s CI-jem.
CI služi kao dobra polazna točka za svaku tvrtku koja implementira DevOps. Kada se implementira, pristupi tvrtki isporuci softvera značajno se mijenjaju. Nakon što svladate CI, možete razmišljati o poboljšanju cijelog procesa, povećanju brzine uvođenja i drugim promjenama.
Za mnoge organizacije dovoljan je sam CI, a CD treba implementirati samo ako dodaje vrijednost.
Nedostatak odgovarajućih nadzornih ploča i metrika
Nakon što postavite svoje ciljeve, razvojni tim može izraditi nadzornu ploču za mjerenje KPI-ja. Prije njegovog razvoja vrijedi procijeniti parametre koji će se pratiti.
Različita izvješća 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 zainteresiran za stopu izgaranja stručnjaka.
Neki timovi također koriste nadzorne ploče s crvenim, žutim i zelenim indikatorima za procjenu statusa CI/CD kako bi shvatili rade li sve kako treba ili je došlo do pogreške. Crveno znači da trebate obratiti pozornost na ono što se događa.
Međutim, ako nadzorne ploče nisu standardizirane, mogu dovesti u zabludu. Analizirajte koji podaci su svima potrebni, a zatim izradite standardizirani opis onoga što oni znače. Saznajte što dionicima ima više smisla: grafika, tekst ili brojevi.
Nema ručnih testova
Automatizacija testiranja postavlja temelje za dobar CI/CD cjevovod. Ali automatizirano testiranje u svim fazama ne znači da ne biste trebali provoditi ručno testiranje.
Za izgradnju učinkovitog CI/CD cjevovoda potrebni su vam i ručni testovi. Uvijek će postojati neki aspekti testiranja koji zahtijevaju ljudsku analizu.
Vrijedno je razmisliti o integraciji napora ručnog testiranja u svoj cjevovod. Nakon što se završi ručno testiranje nekih testnih slučajeva, možete prijeći na fazu postavljanja.
Ne pokušavajte poboljšati testove
Učinkovit CI/CD cjevovod zahtijeva pristup pravim alatima, bilo da se radi o upravljanju testiranjem ili integraciji i stalnom praćenju.
Stvaranje snažne kulture usmjerene na kvalitetu ima za cilj , praćenje interakcija s korisnicima nakon implementacije i praćenje poboljšanja.
Evo nekoliko praktičnih savjeta koje možete jednostavno primijeniti:
- Provjerite jesu li vaši testovi jednostavni za pisanje i dovoljno fleksibilni da se ne pokvare kada refaktorirate kod.
- Razvojni timovi trebaju biti uključeni u proces testiranja - pogledajte popis korisničkih problema i zahtjeva koji su važni za testiranje tijekom CI cjevovoda.
- Možda nemate potpunu pokrivenost testiranjem, ali uvijek provjerite da su tokovi koji su važni za UX i korisničko iskustvo testirani.
Posljednja, ali ne i najmanje važna točka
Prijelaz na CI/CD obično se pokreće odozdo prema gore, ali u konačnici to je transformacija koja zahtijeva vodstvo, vrijeme i resurse tvrtke. Uostalom, CI/CD je skup vještina, procesa, alata i kulturnog restrukturiranja; takve se promjene mogu provoditi samo sustavno.
Što još pročitati na temu:
- .
- .
- .
Izvor: www.habr.com