Če vaše podjetje šele uvaja DevOps ali CI/CD orodja, vam bo morda koristilo, da se seznanite z najpogostejšimi napakami, da jih ne boste ponavljali in stopili na tuje grablje.
Ekipa prevedel članek .
Nepripravljenost spreminjati kulturo in procese
Pogled na diagram cikla , je jasno, da je v praksi DevOps testiranje neprekinjeno delo, temeljni del vsake posamezne uvedbe.
Diagram neskončnega cikla DevOps
Testiranje in zagotavljanje kakovosti med razvojem in dostavo je bistveni del vsega, kar počnejo razvijalci. To zahteva spremembo miselnosti, da se testiranje vključi v vsako nalogo.
Testiranje postane del vsakodnevnega dela vsakega člana ekipe. Prehod na stalno testiranje ni enostaven, na to morate biti pripravljeni.
Pomanjkanje povratnih informacij
Učinkovitost DevOps je odvisna od stalnih povratnih informacij. Nenehne izboljšave niso možne, če ni prostora za sodelovanje in komunikacijo.
Podjetja, ki ne organizirajo retrospektivnih sestankov, težko uvedejo kulturo stalnih povratnih informacij v CI/CD. Retrospektivni sestanki potekajo na koncu vsake ponovitve, kjer člani skupine razpravljajo o tem, kaj je šlo dobro in kaj narobe. Retrospektivni sestanki so temelj Scrum/Agile, vendar so bistveni tudi za DevOps.
To je zato, ker retrospektivna srečanja vcepijo navado izmenjave povratnih informacij in mnenj. Eden najpomembnejših trenutkov na začetku je organizacija ponavljajočih se retro srečanj, da postanejo razumljivi in domači celotni ekipi.
Ko gre za kakovost programske opreme, so vsi člani ekipe odgovorni za njeno vzdrževanje. Na primer, razvijalci lahko napišejo teste enot in kodo z mislijo na sposobnost testiranja, kar pomaga ublažiti tveganje od samega začetka.
Eden preprostih načinov za izražanje spreminjajočega se dojemanja testiranja je, da preizkuševalce ne imenujemo QA, temveč preizkuševalec programske opreme ali inženir kakovosti. Ta sprememba se morda zdi preveč preprosta ali celo neumna. Toda če nekoga imenujemo "strokovnjak za zagotavljanje kakovosti programske opreme", dobimo napačno predstavo o tem, kdo je odgovoren za kakovost izdelkov. V praksah Agile, CI/CD in DevOps so vsi odgovorni za kakovost programske opreme.
Druga pomembna točka je razumevanje, kaj kakovost pomeni za celotno ekipo in vsakega njenega člana, organizacijo, deležnike.
Napačno razumevanje zaključka stopnje
Če je kakovost stalen in deljen proces, je potrebno skupno razumevanje zaključka stopnje. Kako razumeti, da je odra konec? Kaj se zgodi, ko je mejnik označen kot dokončan na tabli Trello ali drugi plošči kanban?
Določanje dokončanega mejnika (DoD) je močno orodje v kontekstu CD DevOps/CI. Pomaga bolje razumeti standarde kakovosti tega, kaj in kako ekipa gradi.
Razvojna ekipa se mora odločiti, kaj pomeni "Končano". Morajo se usesti in sestaviti seznam značilnosti, ki morajo biti izpolnjene na vsaki stopnji, da se lahko šteje za popolno.
DoD naredi postopek preglednejši in olajša izvajanje CI/CD, če je to jasno vsem članom ekipe in se medsebojno strinjajo.
Pomanjkanje realnih, jasno opredeljenih ciljev
To je eden najpogosteje citiranih nasvetov, a ga velja ponoviti. Za uspeh katerega koli resnega podviga, vključno z implementacijo CI/CD ali DevOps, morate postaviti realne cilje in meriti uspešnost glede nanje. Kaj poskušate doseči s CI/CD? Ali omogoča hitrejše izdaje z boljšo kakovostjo?
Vsi zastavljeni cilji morajo biti ne le pregledni in realni, ampak tudi skladni s trenutnimi dejavnostmi podjetja. Na primer, kako pogosto vaše stranke potrebujejo nove popravke ali različice? Ni potrebe po preobremenitvi procesov in hitrejši izdaji, če uporabnikom ni dodatne koristi.
Prav tako vam ni treba vedno implementirati tako CD kot CI. Na primer, visoko regulirana podjetja, kot so banke in zdravstvene klinike, lahko delajo samo s CI.
CI je dobro izhodišče za vsako podjetje, ki izvaja DevOps. Z njeno implementacijo v podjetje se bistveno spremenijo pristopi k dostavi programske opreme. Ko obvladate CI, lahko razmišljate o izboljšavi celotnega procesa, povečanju hitrosti uvajanja in drugih spremembah.
Za mnoge organizacije zadostuje en KI, CD pa bi bilo treba uvesti le, če dodaja vrednost.
Pomanjkanje ustreznih nadzornih plošč in meritev
Ko si zastavite cilje, lahko razvojna ekipa ustvari nadzorno ploščo za merjenje KPI-jev. Pred njegovim razvojem je smiselno oceniti parametre, ki jih bomo spremljali.
Različna poročila in aplikacije so uporabne za različne člane ekipe. Scrum mojstri se bolj ukvarjajo s statusom in dosegom. Medtem ko višje vodstvo morda zanima stopnja izgorelosti strokovnjakov.
Nekatere ekipe uporabljajo tudi nadzorne plošče z rdečimi, rumenimi in zelenimi indikatorji za oceno statusa CI/CD, da razumejo, ali delajo vse pravilno ali je prišlo do napake. Rdeča pomeni, da morate biti pozorni na to, kar se dogaja.
Če pa nadzorne plošče niso standardizirane, so lahko zavajajoče. Analizirajte, katere podatke potrebuje vsak, in nato ustvarite standardiziran opis, kaj to pomeni. Ugotovite, kaj je bolj smiselno za vaše deležnike: grafika, besedilo ali številke.
Pomanjkanje ročnih testov
Avtomatizacija testiranja postavlja temelje za dober cevovod CI/CD. Toda avtomatsko testiranje na vseh stopnjah ne pomeni, da ne bi smeli izvajati ročnega testiranja.
Za izgradnjo učinkovitega cevovoda CI/CD so potrebni tudi ročni testi. Vedno bodo nekateri vidiki testiranja zahtevali človeško analizo.
Vredno je razmisliti o vključitvi ročnega testiranja v cevovod. Ko je ročno testiranje nekaterih testnih primerov končano, lahko nadaljujete na fazo uvajanja.
Ne poskušajte izboljšati testov
Učinkovit cevovod CI/CD zahteva dostop do pravih orodij, ne glede na to, ali gre za upravljanje testiranja ali integracijo in stalno spremljanje.
Cilj ustvarjanja močne, h kakovosti usmerjene kulture je , spremljajte uporabniško izkušnjo po uvedbi in spremljajte izboljšave.
Tukaj je nekaj praktičnih nasvetov, ki jih lahko preprosto uporabite:
- Prepričajte se, da so testi enostavni za pisanje in dovolj prilagodljivi, da se ne pokvarijo, ko se koda refaktorira.
- Razvojne ekipe bi morale biti vključene v postopek testiranja – oglejte si seznam uporabniških težav in zahtev, ki jih je pomembno preizkusiti med cevovodi CI.
- Morda nimate popolne pokritosti s testom, vendar vedno poskrbite, da bodo preizkušeni tokovi, ki so pomembni za UX in uporabniško izkušnjo.
Zadnja, vendar ne najmanj pomembna točka
Prehod na CI/CD se običajno začne od spodaj navzgor, na koncu pa je to preobrazba, ki zahteva sodelovanje vodstva, čas in sredstva s strani podjetja. Konec koncev je CI / CD skupek veščin, procesov, orodij in kulturnega prestrukturiranja, takšne spremembe je mogoče izvajati le sistematično.
Kaj še prebrati na to temo:
- .
- .
- .
Vir: www.habr.com