Dacă compania dvs. tocmai introduce instrumente DevOps sau CI/CD, vă poate fi util să vă familiarizați cu cele mai frecvente greșeli pentru a nu le repeta și a nu călca pe rake altcuiva.
Echipă a tradus articolul .
Nepregătirea de a schimba cultura și procesele
Dacă te uiți la diagrama ciclică , este clar că în practicile DevOps testarea este o activitate continuă, o parte fundamentală a fiecărei implementări.
Diagrama de ciclu infinit DevOps
Testarea și asigurarea calității în timpul dezvoltării și livrării sunt o parte esențială a tot ceea ce fac dezvoltatorii. Acest lucru necesită o schimbare de mentalitate pentru a include testarea în fiecare sarcină.
Testarea devine parte din munca zilnică a fiecărui membru al echipei. Trecerea la testarea constantă nu este ușoară, trebuie să fii pregătit pentru asta.
Lipsa de feedback
Eficacitatea DevOps depinde de feedback constant. Îmbunătățirea continuă este imposibilă dacă nu există loc pentru colaborare și comunicare.
Companiile care nu organizează întâlniri retrospective le este dificil să implementeze o cultură a feedback-ului continuu în CI/CD. Întâlnirile retrospective au loc la sfârșitul fiecărei iterații, în timpul cărora membrii echipei discută ce a mers bine și ce a mers prost. Întâlnirile retrospective sunt fundamentul Scrum/Agile, dar sunt necesare și pentru DevOps.
Acest lucru se datorează faptului că întâlnirile retrospective insuflă obiceiul de a face schimb de feedback și opinii. Unul dintre cele mai importante puncte de la început este organizarea de întâlniri retro recurente, astfel încât acestea să devină înțelese și familiare întregii echipe.
Când vine vorba de calitatea software-ului, toți membrii echipei sunt responsabili pentru menținerea acestuia. De exemplu, dezvoltatorii pot scrie teste unitare și, de asemenea, pot scrie cod având în vedere capacitatea de testare, ajutând la reducerea riscului de la început.
O modalitate simplă de a reflecta schimbarea gândirii despre testare este să apelați testeri nu QA, ci testeri de software sau inginer de calitate. Această schimbare poate părea prea simplă sau chiar stupidă. Dar a numi pe cineva „persoană de asigurare a calității software” dă o idee greșită despre cine este responsabil pentru calitatea produsului. În practicile Agile, CI/CD și DevOps, toată lumea este responsabilă pentru calitatea software-ului.
Un alt punct important este să înțelegem ce înseamnă calitatea pentru întreaga echipă și pentru fiecare dintre membrii acesteia, organizație și părțile interesate.
Neînțelegere a finalizării etapei
Dacă calitatea este un proces continuu și general, este necesară o înțelegere comună a finalizării etapei. De unde știi când s-a terminat o etapă? Ce se întâmplă când un pas este marcat ca finalizat pe o placă Trello sau alt Kanban?
Definition of Done (DoD) este un instrument puternic în contextul CD DevOps/CI. Ajută la o mai bună înțelegere a standardelor de calitate a ceea ce și cum construiește echipa.
Echipa de dezvoltare trebuie să decidă ce înseamnă „Terminat”. Ei trebuie să se așeze și să facă o listă de caracteristici care trebuie îndeplinite în fiecare etapă pentru ca aceasta să fie considerată completă.
DoD face procesul mai transparent și facilitează implementarea CI/CD dacă este înțeles de toți membrii echipei și convenit de comun acord.
Lipsa unor obiective realiste, clar definite
Acesta este unul dintre sfaturile cele mai des citate, dar merită repetat. Pentru a reuși în orice efort major, inclusiv CI/CD sau DevOps, trebuie să stabiliți obiective realiste și să măsurați performanța în raport cu acestea. Ce încerci să obții cu CI/CD? Acest lucru permite lansări mai rapide, cu o calitate mai bună?
Orice obiective stabilite nu trebuie doar să fie transparente și realiste, ci și să fie în concordanță cu activitățile curente ale companiei. De exemplu, cât de des au clienții dumneavoastră nevoie de noi patch-uri sau versiuni? Nu este nevoie să supraîncărcați procesele și să eliberați mai repede dacă nu există niciun beneficiu suplimentar pentru utilizatori.
În plus, nu trebuie întotdeauna să implementați atât CD, cât și CI. De exemplu, companiile foarte reglementate, cum ar fi băncile și clinicile medicale, pot lucra numai cu CI.
CI servește ca un bun punct de plecare pentru orice companie care implementează DevOps. Când este implementat, abordările companiilor cu privire la livrarea de software se schimbă semnificativ. Odată ce CI este stăpânit, vă puteți gândi la îmbunătățirea întregului proces, la creșterea vitezei de lansare și la alte modificări.
Pentru multe organizații, doar CI este suficient, iar CD-ul ar trebui implementat doar dacă adaugă valoare.
Lipsa tablourilor de bord și a valorilor adecvate
Odată ce v-ați stabilit obiectivele, echipa de dezvoltare poate crea un tablou de bord pentru a măsura KPI-urile. Înainte de dezvoltarea sa, merită să evaluați parametrii care vor fi monitorizați.
Diferite rapoarte și aplicații sunt utile pentru diferiți membri ai echipei. Scrum Master este mai interesat de statut și de acoperire. În timp ce managementul superior poate fi interesat de rata de epuizare a specialiștilor.
Unele echipe folosesc, de asemenea, tablouri de bord cu indicatori roșii, galbeni și verzi pentru a evalua starea CI/CD pentru a înțelege dacă fac totul corect sau dacă există o eroare. Roșu înseamnă că trebuie să fii atent la ceea ce se întâmplă.
Cu toate acestea, dacă tablourile de bord nu sunt standardizate, acestea pot induce în eroare. Analizați de ce date au nevoie toată lumea și apoi creați o descriere standardizată a ceea ce înseamnă. Aflați ce are mai mult sens pentru părțile interesate: grafică, text sau numere.
Fără teste manuale
Automatizarea testelor pune bazele unei bune conducte CI/CD. Dar testarea automată în toate etapele nu înseamnă că nu ar trebui să efectuați testarea manuală.
Pentru a construi o conductă CI/CD eficientă, aveți nevoie și de teste manuale. Vor exista întotdeauna unele aspecte ale testării care necesită analiză umană.
Merită să luați în considerare integrarea eforturilor de testare manuală în conducta dvs. Odată ce testarea manuală a unor cazuri de testare este finalizată, puteți trece la faza de implementare.
Nu încercați să îmbunătățiți testele
O pipeline CI/CD eficientă necesită acces la instrumentele potrivite, fie că este vorba de managementul testelor sau integrarea și monitorizarea continuă.
Crearea unei culturi puternice, orientate spre calitate are ca scop , monitorizarea interacțiunilor cu clienții după implementare și urmărirea îmbunătățirilor.
Iată câteva sfaturi practice pe care le puteți implementa cu ușurință:
- Asigurați-vă că testele sunt ușor de scris și suficient de flexibile pentru a nu se sparge atunci când refactorizați codul.
- Echipele de dezvoltare ar trebui să fie incluse în procesul de testare - vedeți o listă de probleme și solicitări ale utilizatorilor care sunt importante de testat în timpul conductelor CI.
- Este posibil să nu aveți o acoperire completă a testelor, dar asigurați-vă întotdeauna că fluxurile care sunt importante pentru UX și experiența clienților sunt testate.
Ultimul punct, dar nu în ultimul rând important
Tranziția la CI/CD este de obicei condusă de jos în sus, dar în cele din urmă este o transformare care necesită implicarea liderului, timp și resurse din partea companiei. La urma urmei, CI/CD este un set de competențe, procese, instrumente și restructurare culturală; astfel de schimbări pot fi implementate doar sistematic.
Ce să mai citești pe subiect:
- .
- .
- .
Sursa: www.habr.com