Ați auzit CI/CD, dar nu sunteți sigur ce este?
În mod ideal, inginerii de software sunt angajați pentru a scrie codul care trebuie să fie expediat într-un mediu de producție, astfel încât compania care are nevoie de produs să îl poată utiliza. Pentru a satisface afacerea (denumită adesea utilizatori/clienți), este esențial ca produsele să nu aibă erori.
Abordarea tipică urmată de inginerii de software este să lucreze în ramuri și să creeze o cerere de extragere care actualizează ramura principală cu noua actualizare care a fost făcută. Am adoptat practica scrierii de teste ca mijloc de a ne asigura că noile modificări nu introduc erori. Când dezvoltatorii lucrează la o caracteristică în cele mai multe cazuri, adesea nu creează o cerere de extragere până când nu termină complet cu caracteristica. Ce se întâmplă când sunt gata este că;
- Ei petrec mult timp încercând să-și actualizeze baza de cod cu modificările care au avut loc în ramura de producție în timp ce lucrau.
- În acest sens, ei trebuie să remedieze o serie de conflicte de îmbinare.
- Există și posibilitatea ca aceștia să rupă ramura de producție, ceea ce îi afectează pe cei care trag din ramură înainte ca problema să fie văzută și remediată.
Dacă ați fost vreodată în această situație, veți fi de acord că poate fi o durere – nimănui nu-i place să-și petreacă ziua de lucru așa.
Care este soluția?
Cuprins
Integrare continuă
Pentru a preveni scenariile pe care le-am enunțat mai sus; echipele de inginerie pot adopta practica numită integrare continuă – după cum sugerează și numele, aceasta implică integrarea continuă a modificărilor de cod făcute de dezvoltatori în ramura/repozitivul partajat. Codul care urmează să fie integrat trebuie să fie supus unui test verificat pentru a se asigura că nu întrerupe aplicația. Numai când testul trece este integrat
Pentru a înțelege acest lucru, să ne imaginăm un scenariu real în care există o echipă de 10 dezvoltatori. Acești dezvoltatori creează o ramură local în care scriu cod pentru implementarea anumitor caracteristici. În loc să trimită solicitări de extragere când au terminat în întregime funcția, ei optează să trimită solicitări de extragere deoarece fac mici modificări. Un exemplu de astfel de schimbare va fi crearea unui nou mod, presupunând că dezvoltatorul lucrează la o caracteristică care permite utilizatorilor să gestioneze sarcini individuale în aplicație. În loc să aștepte până când caracteristica sarcinii este finalizată, pentru a adera la un model de integrare continuă, dezvoltatorul împinge această mică schimbare (în comparație cu ceea ce lucrează) și creează o cerere de extragere pentru a fuziona cu codul.
Înainte ca această nouă schimbare să fie integrată, trebuie să ruleze o serie de teste.
Echipele de inginerie software folosesc instrumente precum Travis CI pentru a crea aceste procese și teste de integrare. Cu instrumente ca acestea, testele sunt automatizate, astfel încât să ruleze de îndată ce o cerere de extragere este trimisă la ramura țintă selectată în timpul configurării.
Rezultatele testelor sunt generate, iar dezvoltatorul care a creat cererile de extragere poate vedea rezultatele și poate face modificările necesare. Beneficiile de a rămâne la acest model de integrare a codului cât mai puțin posibil și de a avea un test verificat de rulat sunt:
- Devine posibil pentru echipa implicată să știe ce a cauzat eșecul procesului de construire sau testului. Acest lucru reduce posibilitatea de a trimite un bug la producție.
- Dacă echipa automatizează procesul, va avea luxul de a se concentra pe productivitate.
Lucrul important de remarcat în această practică este că încurajează echipa să împingă frecvent codul către ramura principală. Acest lucru va fi ineficient dacă alți membri ai echipei nu se trag din ramura principală pentru a-și actualiza depozitul local.
Tipuri de teste
În testele scrise care vor face parte din procesul de integrare, iată câteva care pot fi implementate în proces:
- Integrare – combină unități individuale ale software-ului și le testează ca grup.
- Unitate – testează unități sau componente individuale ale software-ului, cum ar fi metode sau funcții.
- UI – afirmă că software-ul funcționează bine din perspectiva utilizatorului.
- Acceptare – testează dacă software-ul îndeplinește cerințele de afaceri.
Este important să rețineți că nu trebuie să testați toate acestea, deoarece o mână dintre ele ar putea fi deja acoperite în codul scris de dezvoltator.
Instrumente de integrare continuă
Fără a intra în profunzime, iată instrumente pe care le puteți începe să le utilizați în proiectele actuale sau noi;
- Travis CI – cunoscut în lumea open-source și vă promite să vă testați codul fără probleme în câteva minute.
- Cercul CI – vă oferă putere, flexibilitate și control pentru a vă automatiza conducta de la control până la implementare.
- Jenkins – oferă sute de pluginuri pentru a sprijini construirea, implementarea și automatizarea oricărui proiect.
Dacă ești nou în Jenkins, aș sugera să iei asta curs Udemy pentru a învăța CI cu Java și .NET.
Implementare continuă
La ce va fi de folos dacă caracteristica pe care o construiți rămâne în depozit timp de săptămâni sau luni înainte de a fi implementată în mediul de producție. Oricât de mult echipele de ingineri pot lucra pentru a integra mici schimbări în ramura principală pe măsură ce se întâmplă, ele pot, de asemenea, să împingă aceste schimbări în mediul de producție cât mai curând posibil.
Obiectivul când se practică implementarea continuă este de a aduce modificările efectuate către utilizatori de îndată ce dezvoltatorii integrează aceste modificări în ramura principală.
Ca și în cazul integrării continue, atunci când se utilizează implementarea continuă, testele și verificările automate sunt configurate pentru a se asigura că modificările nou integrate sunt verificate. Implementarea are loc numai când aceste teste trec.
Pentru ca o echipă să beneficieze de practica de desfășurare continuă, trebuie să aibă următoarele:
- Testarea automată este coloana vertebrală esențială a tuturor practicilor continue de inginerie. În cazul implementării continue, codul care urmează să fie implementat trebuie să corespundă standardului pe care echipa l-a pus în aplicare pentru ceea ce intenționează să transmită utilizatorilor finali. În mod ideal, dacă o nouă modificare este sub prag, testul ar trebui să eșueze și să nu fie integrat. Altfel, devine integrat.
- În ciuda faptului că au teste automatizate consecutive, este posibil ca unele erori să se strecoare în mediul de producție. Pentru aceasta, este necesar ca echipa să poată anula o modificare care a fost făcută – anulează o implementare. Acest lucru ar trebui să revină codul de producție la ceea ce era înainte de a fi făcută noua modificare.
- Sunt necesare sisteme de monitorizare pentru a ține evidența schimbărilor care au fost împinse în mediul de producție. Acesta este modul în care echipa poate fi capabilă să urmărească erorile pe care le întâmpină utilizatorii atunci când folosesc modificările implementate.
Instrumentele menționate pentru integrarea continuă vă oferă, de asemenea, funcționalitatea de a configura un sistem de implementare continuă. Există multe dintre ele pe care le puteți citi.
Concluzie
Productivitatea unei echipe de dezvoltare este vitală pentru succesul afacerii. Pentru a se asigura că sunt productivi, trebuie adoptate practici care încurajează acest lucru. Integrarea și implementarea continuă sunt exemple de astfel de practici.
Cu integrarea continuă, echipele pot împinge cât mai mult cod posibil zilnic. Odată cu acest lucru, devine ușor să implementați noile modificări adăugate utilizatorului cât mai curând posibil. Implementarea acestor modificări face posibilă obținerea de feedback de la utilizatori. În cele din urmă, afacerea va putea să inoveze pe baza feedback-ului primit, ceea ce este un câștig-câștig pentru toată lumea.
De asemenea, puteți învăța cum să extindeți și să optimizați CI/CD.
Dacă sunteți dezvoltator și sunteți interesat să învățați CI/CD, atunci verificați acest lucru curs genial.
Ți-a plăcut să citești articolul? Ce zici de împărtășirea cu lumea?