Jei jūsų įmonė dar tik pristato DevOps ar CI/CD įrankius, jums gali būti naudinga susipažinti su dažniausiai daromomis klaidomis, kad jos nepasikartotų ir neužliptumėte ant kažkieno grėblio.
Komanda išvertė straipsnį .
Nepasirengimas keisti kultūrą ir procesus
Jei pažvelgsite į ciklinę diagramą , aišku, kad DevOps praktikoje testavimas yra nuolatinė veikla, esminė kiekvieno diegimo dalis.
„DevOps“ begalinio ciklo diagrama
Testavimas ir kokybės užtikrinimas kūrimo ir pristatymo metu yra esminė visko, ką kūrėjai daro, dalis. Tam reikia pakeisti mąstymą, kad bandymai būtų įtraukti į kiekvieną užduotį.
Testavimas tampa kiekvieno komandos nario kasdienio darbo dalimi. Perėjimas prie nuolatinio testavimo nėra lengvas, reikia tam pasiruošti.
Atsiliepimų trūkumas
„DevOps“ efektyvumas priklauso nuo nuolatinio grįžtamojo ryšio. Nuolatinis tobulėjimas neįmanomas, jei nėra vietos bendradarbiavimui ir bendravimui.
Įmonėms, kurios nerengia retrospektyvinių susitikimų, sunku įgyvendinti nuolatinio grįžtamojo ryšio kultūrą CI/CD. Kiekvienos iteracijos pabaigoje vyksta retrospektyviniai susitikimai, kurių metu komandos nariai aptaria, kas sekėsi gerai, o kas – blogai. Retrospektyvūs susitikimai yra „Scrum/Agile“ pagrindas, tačiau jie taip pat būtini „DevOps“.
Taip yra todėl, kad retrospektyvūs susitikimai įskiepija įprotį keistis atsiliepimais ir nuomonėmis. Vienas iš svarbiausių momentų pradžioje – pasikartojančių retro susitikimų organizavimas, kad jie taptų suprantami ir pažįstami visai komandai.
Kalbant apie programinės įrangos kokybę, už jos palaikymą atsakingi visi komandos nariai. Pavyzdžiui, kūrėjai gali rašyti vienetų testus ir taip pat parašyti kodą, turėdami omenyje testuojamumą, taip padedant sumažinti riziką nuo pat pradžių.
Vienas paprastas būdas atspindėti mąstymo apie testavimą pokyčius – testuotojus vadinti ne QA, o programinės įrangos testuotoju ar kokybės inžinieriumi. Šis pakeitimas gali atrodyti pernelyg paprastas ar net kvailas. Tačiau ką nors pavadinant „programinės įrangos kokybės užtikrinimo asmeniu“, susidaro klaidinga nuomonė apie tai, kas atsakingas už produkto kokybę. Agile, CI/CD ir DevOps praktikose kiekvienas yra atsakingas už programinės įrangos kokybę.
Kitas svarbus momentas – suprasti, ką kokybė reiškia visai komandai ir kiekvienam jos nariui, organizacijai ir suinteresuotoms šalims.
Neteisingas etapo užbaigimo supratimas
Jei kokybė yra nenutrūkstamas ir bendras procesas, reikia bendro supratimo apie etapo užbaigimą. Kaip žinoti, kada etapas baigėsi? Kas atsitiks, kai „Trello“ ar kitoje „Kanban“ lentoje žingsnis pažymimas kaip atliktas?
Atlikto apibrėžimas (DoD) yra galingas įrankis CD DevOps/CI kontekste. Tai padeda geriau suprasti kokybės standartus, ką ir kaip kuria komanda.
Kūrimo komanda turi nuspręsti, ką reiškia „Atlikta“. Jie turi susėsti ir sudaryti savybių, kurių turi būti laikomasi kiekviename etape, sąrašą, kad jis būtų laikomas užbaigtu.
DoD daro procesą skaidresnį ir palengvina CI/CD įgyvendinimą, jei jį supranta visi komandos nariai ir dėl to susitaria abipusiai.
Realių, aiškiai apibrėžtų tikslų trūkumas
Tai vienas iš dažniausiai cituojamų patarimų, tačiau verta jį kartoti. Kad pasisektų bet kokia svarbi veikla, įskaitant CI/CD ar DevOps, turite išsikelti realius tikslus ir įvertinti našumą pagal juos. Ką bandote pasiekti su CI/CD? Ar tai leidžia greičiau išleisti geresnę kokybę?
Bet kokie keliami tikslai turi būti ne tik skaidrūs ir realūs, bet ir derėti su dabartine įmonės veikla. Pavyzdžiui, kaip dažnai jūsų klientams reikia naujų pataisų ar versijų? Nereikia perkrauti procesų ir greičiau išleisti, jei nėra papildomos naudos vartotojams.
Be to, ne visada reikia įdiegti ir CD, ir CI. Pavyzdžiui, griežtai reguliuojamos įmonės, tokios kaip bankai ir medicinos klinikos, gali dirbti tik su KI.
CI yra geras atspirties taškas bet kuriai „DevOps“ diegiančiajai įmonei. Jį įgyvendinus, įmonių požiūris į programinės įrangos pristatymą labai pasikeičia. Įvaldę CI, galite galvoti apie viso proceso tobulinimą, diegimo greičio didinimą ir kitus pakeitimus.
Daugeliui organizacijų pakanka vien CI, o CD reikėtų diegti tik tuo atveju, jei tai sukuria pridėtinę vertę.
Trūksta tinkamų prietaisų skydelių ir metrikos
Kai nustatysite savo tikslus, kūrimo komanda gali sukurti informacijos suvestinę KPI matuoti. Prieš kuriant, verta įvertinti parametrus, kurie bus stebimi.
Įvairios ataskaitos ir programos yra naudingos skirtingiems komandos nariams. „Scrum Master“ labiau domisi statusu ir pasiekiamumu. Nors vyresnioji vadovybė gali būti suinteresuota specialistų perdegimo rodikliu.
Kai kurios komandos taip pat naudoja prietaisų skydelius su raudonais, geltonais ir žaliais indikatoriais, kad įvertintų CI/CD būseną, kad suprastų, ar viską daro teisingai, ar nėra klaidų. Raudona reiškia, kad reikia atkreipti dėmesį į tai, kas vyksta.
Tačiau jei prietaisų skydeliai nėra standartizuoti, jie gali klaidinti. Išanalizuokite, kokių duomenų kiekvienam reikia, tada sukurkite standartizuotą jų reikšmę. Sužinokite, kas suinteresuotosioms šalims yra prasmingesnė: grafika, tekstas ar skaičiai.
Jokių rankinių testų
Bandymų automatika sudaro gero CI/CD dujotiekio pagrindą. Tačiau automatizuotas testavimas visuose etapuose nereiškia, kad neturėtumėte atlikti rankinio testavimo.
Norint sukurti efektyvų CI/CD dujotiekį, taip pat reikia atlikti rankinius testus. Visada bus kai kurie bandymų aspektai, kuriems reikia žmogaus analizės.
Verta apsvarstyti galimybę į savo dujotiekį integruoti rankinio testavimo pastangas. Baigę rankinį kai kurių bandomųjų atvejų testavimą, galite pereiti prie diegimo etapo.
Nebandykite tobulinti testų
Veiksmingam CI / CD vamzdynui reikia prieigos prie tinkamų įrankių, nesvarbu, ar tai būtų testų valdymas, ar integravimas ir nuolatinė stebėsena.
Kurti stiprią, į kokybę orientuotą kultūrą siekiama , stebėti klientų sąveiką po įdiegimo ir sekti patobulinimus.
Štai keletas praktinių patarimų, kuriuos galite lengvai įgyvendinti:
- Įsitikinkite, kad jūsų testai yra lengvai rašomi ir pakankamai lankstūs, kad nesugadintumėte pertvarkydami kodą.
- Kūrimo komandos turėtų būti įtrauktos į testavimo procesą – žr. vartotojų problemų ir užklausų, kurias svarbu išbandyti atliekant CI konvejerių, sąrašą.
- Galbūt neturėsite visos testavimo aprėpties, bet visada įsitikinkite, kad srautai, svarbūs UX ir klientų patirčiai, būtų išbandyti.
Paskutinis, bet ne mažiau svarbus momentas
Perėjimas prie CI/CD paprastai vyksta iš apačios į viršų, tačiau galiausiai tai yra transformacija, kuriai reikia įmonės vadovavimo, laiko ir išteklių. Juk CI/CD yra įgūdžių, procesų, įrankių ir kultūrinio pertvarkymo visuma, tokius pokyčius galima įgyvendinti tik sistemingai.
Ką dar skaityti šia tema:
- .
- .
- .
Šaltinis: www.habr.com