Če vaša podjetja šele uvajajo DevOps ali orodja CI/CD, vam lahko koristi, da se seznanite z najpogostejšimi napakami, da se jim izognete in se ne spotikate ob iste kamne.
Komanda prevedel članek .
Nezmožnost prilagajanja kulturi in procesom
Če pogledamo na ciklično shemo , lahko vidimo, da je testiranje v praksi DevOps nenehno delo, temelji na vsakem posameznem uvodu.
Neskončna ciklična shema DevOps
Testiranje in zagotavljanje kakovosti v razvojnem in dostavnem procesu sta obvezni del vsega, kar počnejo razvijalci. To zahteva spremembo mišljenja, da se testiranje vključi v vsak posamezen korak.
Testiranje postane del vsakodnevnega dela vsakega člana ekipe. Prehod na stalno testiranje ni enostaven in potreben je pripravljenost na to.
Pomanjkanje povratnih informacij
Učinkovitost DevOps-a temelji na stalnih povratnih informacijah. Nenehno izboljševanje ni mogoče brez prostora za sodelovanje in komunikacijo.
Podjetjem, ki ne organizirajo retrospektivnih srečanj, je težko uvesti kulturo nenehnih povratnih informacij v CI/CD. Retrospektivna srečanja se izvajajo ob koncu vsake iteracije, kjer člani skupine razpravljajo o tem, kaj je šlo dobro in kaj slabo. Retrospektivna srečanja so temelj Scrum/Agile, vendar so potrebna tudi za DevOps.
To je zato, ker retrospektivna srečanja vzgajajo navado izmenjave povratnih informacij in mnenj. Eden najpomembnejših vidikov pri pričetku je organizacija ponavljajočih se retro-srečanj, da postanejo jasni in običajni za celotno ekipo.
Ko gre za kakovost programske opreme, vsak član ekipe nosi odgovornost za njeno ohranjanje. Na primer, razvijalci lahko pišejo enotne teste in tudi pišejo kodo z mislija na testabilnost, kar pomaga zmanjšati tveganja že na začetku.
Eden od preprostih načinov za odražanje sprememb v dojemanju testiranja je, da testere imenujemo ne QA, temveč kot testerje programske opreme ali inženirje kakovosti. Ta sprememba se morda zdi preprosta ali celo neumna. Vendar pa, če nekoga imenujemo 'specialist za zagotavljanje kakovosti programske opreme', to daje napačno predstavo o tem, kdo je odgovoren za kakovost izdelka. V praksi Agile, CI/CD in DevOps so vsi odgovorni za kakovost programske opreme.
Drug pomemben vidik je razumevanje, kaj kakovost pomeni za celotno ekipo in vsakega njenega člana, organizacijo ter zainteresirane strani.
Napačno razumevanje zaključka faze
Če je kakovost nenehen in skupen proces, je potrebno splošno razumevanje zaključka faze. Kako razumeti, da je faza končana? Kaj se zgodi, ko je faza označena kot zaključena na tabli Trello ali drugi kanban tabli?
Definicija zaključene faze (DoD) je močno orodje v kontekstu CD DevOps/CI. Pomaga bolje razumeti standarde kakovosti tega, kar in kako gradi ekipa.
Ekipa razvijalcev se mora odločiti, kaj pomeni 'končano'. Morajo sedeti in napisati seznam značilnosti, ki morajo biti izpolnjene v vsaki fazi, da jo lahko štejemo za zaključeno.
DoD proces naredi bolj pregleden in olajša uvedbo CI/CD, če je vsem članom ekipe jasen in medsebojno dogovorjen.
Pomanjkanje realističnih, jasno opredeljenih ciljev
To je eden najbolj pogosto citiranih nasvetov, a ga je vredno ponoviti. Za uspeh katere koli resne pobude, vključno z uvajanjem CI/CD ali DevOps, je potrebno postaviti realne cilje in meriti uspešnost glede na njih. Kaj želite doseči s CI/CD? Ali to omogoča hitrejše izdaje z boljšo kakovostjo?
Vsaki postavljeni cilji morajo biti ne le pregledni in realistični, ampak tudi skladni z trenutnim delovanjem podjetja. Na primer, kako pogosto vaši kupci potrebujejo nove popravke ali različice? Nič ni narobe, če zakomplicirate procese in izdajate hitreje, če to ne prinaša dodatnih koristi za uporabnike.
Poleg tega vam ni vedno treba izvajati tako CD kot CI. Na primer, podjetja z visoko stopnjo regulacije, kot so banke in medicinski klinični centri, lahko delujejo le s CI.
CI je dober izhodiščni poudarek za vsako podjetje, ki uvaja DevOps. Z uvajanjem CI se v podjetju bistveno spremenijo pristopi k dobavi programske opreme. Ko se CI obvlada, lahko razmislite o izboljšavah celotnega procesa, povečanju hitrosti in drugih spremembah.
Za mnoge organizacije je dovolj le en CI, CD pa je treba izvesti le, če prinaša dodatne koristi.
Pomanjkanje ustreznih nadzornih plošč in metrik
Ko enkrat postavite cilje, lahko ekipa razvijalcev ustvari nadzorno ploščo za merjenje KPI. Pred njeno oblikovanjem je vredno oceniti kazalnike, ki jih bomo spremljali.
Različna poročila in aplikacije so koristna za različne člane ekipe. Scrum mojstre bolj zanima status in pokritost, medtem ko višje vodstvo morda zanima hitrost izgorevanja strokovnjakov.
Nekatere ekipe tudi uporabljajo nadzorne plošče s rdečimi, rumenimi in zelenimi indikatorji za oceno statusa CI/CD, da bi razumeli, ali vse upravljajo pravilno ali je prišlo do napake. Rdeča barva pomeni, da je treba pozornost usmeriti na dogajanje.
Vendar pa, če nadzorne plošče niso standardizirane, lahko zmedejo. Analizirajte, katere podatke vsi potrebujejo, nato pa ustvarite standardiziran opis, kar pomenijo. Ugotovite, kaj ima več smisla za zainteresirane strani: grafi, besedilo ali številke.
Pomanjkanje ročnih testov
Avtomatizacija testiranja postavlja podlago za dober CI/CD sistem. Vendar pa avtomatizirano testiranje na vseh stopnjah ne pomeni, da ne bi smeli izvajati ročnih testov.
Za zgraditev učinkovitega CI/CD sistema so potrebni tudi ročni testi. Vedno bodo nekateri vidiki testiranja, ki zahtevajo analizo človeka.
Valja razmisliti o integraciji prizadevanj za ročno testiranje v sistem. Ko so nekateri testni primeri uspešno zaključeni, lahko preidete na stopnjo uvajanja.
Ne poskušajte izboljšati testov
Učinkovit CI/CD proces zahteva dostop do pravih orodij, bodisi za upravljanje testiranjem bodisi za integracijo in nenehno spremljanje.
Ustvarjanje močne, kakovostni osredotočene kulture je usmerjeno na , spremljanje interakcij s strankami po uvedbi in spremljanje izboljšav.
Tukaj je nekaj praktičnih nasvetov, ki jih lahko enostavno uresničite:
- Poskrbite, da bodo testi enostavni za pisanje in dovolj fleksibilni, da se ne pokvarijo pri refaktoringu kode.
- Razvojne ekipe morajo biti vključene v postopek testiranja — morajo videti seznam uporabniških težav in zahtev, ki so pomembne za preverjanje med CI cevovodi.
- Morda ne boste imeli popolnega pokritja s testi, vendar vedno pazite, da so tokovi, pomembni za UX in interakcijo s strankami, testirani.
Zadnja, a nič manj pomembna točka
Prehod na CI/CD se običajno začne od spodaj navzgor, vendar gre na koncu za preobrazbo, ki zahteva sodelovanje vodstva, časovne in materialne vire podjetja. Konec koncev, CI/CD je skupek veščin, procesov, orodij in kulturne preobrazbe, take spremembe je mogoče uvesti le sistematično.
Kaj še prebrati o temi:
- .
- .
- .
Izvor: habr.com
