Dacă compania dvs. implementează abia acum DevOps sau instrumente CI/CD, ar putea fi util să vă familiarizați cu cele mai frecvente greșeli, pentru a nu le repeta și a nu călca pe urmele altora.
Comanda a tradus articolul .
Lipsa de pregătire pentru schimbarea culturii și a proceselor
Dacă privim la diagrama ciclică , se observă că în practicile DevOps, testarea este o activitate continuă, o parte fundamentală a fiecărei desfășurări separate.
Diagrama ciclică infinită DevOps
Testarea și asigurarea calității în procesul de dezvoltare și livrare sunt o parte obligatorie a tot ceea ce fac dezvoltatorii. Aceasta necesită o schimbare de mentalitate pentru a include testarea în fiecare sarcină.
Testarea devine parte din munca de zi cu zi a fiecărui membru al echipei. Trecerea la testarea constantă nu este ușoară, trebuie să fiți pregătiți pentru asta.
Lipsa de feedback
Eficiența DevOps depinde de feedback-ul constant. Îmbunătățirea continuă nu este posibilă fără un spațiu pentru colaborare și comunicare.
Companiile care nu organizează întâlniri retrospective au dificultăți în a implementa o cultură de feedback continuu în CI/CD. Întâlnirile retrospective se desfășoară la sfârșitul fiecărei iterații, unde membrii grupului discută despre ceea ce a mers bine și ce a mers prost. Întâlnirile retrospective sunt fundamentale pentru Scrum/Agile, dar sunt necesare și pentru DevOps.
Acest lucru se datorează faptului că întâlnirile retrospective dezvoltă obiceiul de a face schimb de feedback și opinii. Unul dintre cele mai importante aspecte la început este organizarea de întâlniri retro repetitive, astfel încât acestea să devină clare și familiare întregului colectiv.
Când vine vorba de calitatea software-ului, toți membrii echipei sunt responsabili pentru menținerea acesteia. De exemplu, dezvoltatorii pot scrie teste modulare, precum și scrie cod având în vedere testabilitatea, ajutând la reducerea riscurilor de la bun început.
Una dintre modalitățile simple de a reflecta schimbarea percepțiilor despre testare este de a numi testerii nu QA, ci tester de software sau inginer de calitate. Această modificare poate părea prea simplă sau chiar stupidă. Dar dacă cineva este numit „specialist în asigurarea calității software”, se creează o impresie greșită despre cine este responsabil pentru calitatea produsului. În practicile Agile, CI/CD și DevOps, toți sunt responsabili pentru calitatea software-ului.
Un alt aspect important este înțelegerea a ceea ce înseamnă calitate pentru întreaga echipă și fiecare membru al acesteia, organizație, părți interesate.
Înțelegerea greșită a finalizării etapei
Dacă calitatea este un proces continuu și comun, trebuie să existe o înțelegere comună a finalizării etapei. Cum putem ști că etapa este terminată? Ce se întâmplă când etapa este marcată ca finalizată pe tabloul Trello sau pe alt tablou Kanban?
Definiția etapei finalizate (DoD) este un instrument puternic în contextul CD DevOps/CI. Ajută la o mai bună înțelegere a standardelor de calitate ale a ceea ce și cum construiește echipa.
Echipa de dezvoltare trebuie să decidă ce înseamnă „Gata”. Este necesar să se adune și să întocmească o listă de caracteristici care trebuie îndeplinite la fiecare etapă pentru a putea fi considerată finalizată.
DoD face procesul mai transparent și facilitează implementarea CI/CD, dacă este clar pentru toți membrii echipei și este convenit reciproc.
Lipsa unor obiective clare și realiste
Acesta este unul dintre cele mai frecvent citate sfaturi, dar merită repetat. Pentru succesul oricărei inițiative serioase, inclusiv implementarea CI/CD sau DevOps, este necesar să se stabilească obiective reale și să se măsoare performanța în raport cu acestea. Ce încercați să obțineți prin CI/CD? Oferă o lansare mai rapidă cu o calitate mai bună?
Orice obiective stabilite trebuie să fie nu doar transparente și realiste, ci și să se alinieze cu activitatea curentă a companiei. De exemplu, cât de des au clienții dumneavoastră nevoie de corecții sau versiuni noi? Nu este nevoie să supraîncărcați procesele și să lansați versiuni mai rapid, dacă nu există beneficii suplimentare pentru utilizatori.
În plus, nu trebuie sempre să implementați atât CD, cât și CI. De exemplu, companiile cu un grad ridicat de reglementare, cum ar fi băncile și clinicile medicale, pot funcționa doar cu CI.
CI este un punct de plecare bun pentru orice companie care împlementează DevOps. Odată cu implementarea sa, abordările de livrare a software-ului se schimbă semnificativ. După ce a fost stăpânit CI, se poate lua în considerare îmbunătățirea întregului proces, creșterea vitezei de livrare și alte modificări.
Pentru multe organizații, un singur CI este suficient, iar CD ar trebui implementat doar dacă aduce un beneficiu suplimentar.
Absența tablourilor de bord și metricilor corespunzătoare
Odată ce ați stabilit obiectivele, echipa de dezvoltare poate crea un tablou de bord pentru a măsura KPI. Înainte de a-l dezvolta, este bine să evaluați parametrii care vor fi urmăriți.
Diversele rapoarte și aplicații sunt utile pentru diferite membri ai echipei. Scrum masterii sunt mai interesați de status și acoperire. În timp ce managementul superior poate fi interesat de rata de epuizare a specialiștilor.
Unele echipe utilizează, de asemenea, tablouri de bord cu indicatori roșii, galbeni și verzi pentru a evalua statusul CI/CD, pentru a înțelege dacă fac totul corect sau dacă a apărut o eroare. Roșu înseamnă că trebuie să acorde atenție la ceea ce se întâmplă.
Cu toate acestea, dacă panourile informative nu sunt standardizate, ele pot duce la confuzie. Analizați ce date sunt necesare tuturor, apoi creați o descriere standardizată a ceea ce înseamnă acestea. Aflați ce are mai mult sens pentru părțile interesate: grafice, text sau numere.
Absența testelor manuale
Automatizarea testării pune bazele unui bun conveior CI/CD. Dar testarea automatizată în toate etapele nu înseamnă că nu trebuie să realizați teste manuale.
Pentru a construi un conveior CI/CD eficient, sunt necesare și teste manuale. Vor exista întotdeauna unele aspecte ale testării care necesită analiză de către o persoană.
Merită să luați în considerare integrarea eforturilor de testare manuală în conveior. După ce testarea manuală a unor cazuri de testare este finalizată, puteți trece la etapa de desfășurare.
Nu încercați să îmbunătățiți testele
O pipeline CI/CD eficient necesită acces la instrumentele potrivite, fie că este vorba despre gestionarea testării sau integrarea și monitorizarea continuă.
Crearea unei culturi puternice, orientate spre calitate, se concentrează pe , monitorizarea interacțiunilor cu clienții după desfășurare ș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 strica atunci când se refactorizează codul.
- Echipele de dezvoltare trebuie să fie incluse în procesul de testare — să vadă lista problemelor și solicitărilor utilizatorilor care sunt importante pentru verificare în timpul pipeline-urilor CI.
- S-ar putea să nu aveți o acoperire completă a testelor, dar asigurați-vă că fluxurile importante pentru UX și interacțiunea cu clienții sunt testate.
Ultimul, dar nu cel din urmă punct
Tranziția la CI/CD este de obicei inițiată de jos în sus, dar, în cele din urmă, reprezintă o transformare care necesită participarea managementului, timp și resurse din partea companiei. CI/CD este un set de abilități, procese, instrumente și o reorganizare culturală, iar implementarea acestor schimbări se poate face doar sistemic.
What else to read on the topic:
- .
- .
- .
Sursa: habr.com
