ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 115
Abonament PDF

Arta DevOps

Loredana Iuaniciu
DevOps/Domino Administrator @ accesa



Roland Balint
DevOps & SRE Engineer @ accesa



PROGRAMARE

Fie că suntem începători în dezvoltarea Agile, experţi în DevOps sau dornici să explorăm procesele CI/CD (Continuous Integration/Continuous Delivery), uneori, este bine să ne amintim cum a evoluat dezvoltarea aplicațiilor software.

La începuturi, (anii 80' și 90') metodologia cea mai frecvent aplicată în dezvoltarea software - este vorba despre cea folosită pentru ca un software să fie gata de release- a fost metodologia Waterfall. Aceasta are o structură strict secvențială în care echipele iniţiază următoarea fază de dezvoltare, doar după ce precedenta fază de dezvoltare este finalizată.

Astfel, a apărut o abordare mai "lightweight", mai relaxată, care a devenit populară și care a culminat cu metodologia Agile. În 2001, 17 dezvoltatori software s-au întâlnit la celebra conferință din Snowbird, Utah, dând naștere Manifestului Agile (Agile Manifesto). Agile intră în peisaj, introducând ideea că echipa ar trebui să pregătească release-ul unui software pe tot parcursul procesului de dezvoltare. Când principiile Agile au devenit dominante în lumea business, un nou pretendent își făcea timid apariția. Născut din Agile, dar diferit de acesta, DevOps era o nouă interpretare a ceea ce trebuia să fie dezvoltarea de software colaborativ.

În timp ce Agile aduce dezvoltarea și testarea împreună, DevOps susține că și alte zone ale businessului trebuie să facă parte din proces. Rezultatul a fost crearea de echipe ce au și personal non-IT precum managerii de produs (product managers). Este vorba de o schimbare de paradigmă dacă ne raportăm la ciclul de dezvoltare tradițional de la acea vreme. DevOps decide să țintească mai sus, creând un mediu unde noile release-uri pot fi livrate mai rapid și mai frecvent.

În timp ce DevOps (combinație între "Dezvoltare/DEV" și "Operațiuni/OPS") promovează o cultură/filozofie a colaborării în echipă, a transparenței, CI/CD sunt stâlpii de bază ai arhitecturii DevOps.

DevOps, o formă de artă legitimă, se distinge prin șapte principii cheie:

Echilibru - proces de deployment mai rapid și mai curat

Folosind proceduri automatizate complet, DevOps face ca procesele de deployment să fie mai rapide și mai curate pe tot parcursul ciclului de viață al unei aplicații. Totul începe cu un commit simplu, unde programatorul dorește să testeze sau să lanseze schimbări noi în codul sursă. Un inginer DevOps alege un tool din seria de tooluri consacrate DevOps și îl configurează, astfel încât un commit făcut de programator să declanșeze un build și un nou nivel de deployment pentru o aplicație.

Adoptând această abordare, eliminăm nevoia intervențiilor manuale în două din cele mai importante momente din ciclul de viață pe care îl are o aplicație, deploymentul fiind mai rapid, mai curat.

Mișcare - de la Integrare Continuă (Continuous Integration) la Livrare Continuă (Continuous Delivery)

CI/CD se axează pe automatizarea procesului de build, testare și deployment prin configurarea unui flux CI/CD cu instrumente specifice. Când vorbim de integrare continuă și de livrare continuă (CI/CD), este vorba de o extensie Agile ce se axează pe toolurile și procesele necesare pentru a integra mai rapid bucăți mai mici de cod în codul nucleu, folosind testarea automată și pentru a livra actualizări continue care, la rândul lor, fac mai rapidă dezvoltarea aplicațiilor.

Printre beneficiile CI/CD enumerăm:

Imaginați-vă că realizați o aplicație web care va fi lansată pe servere web live. Aveți o echipă de programatori responsabili cu scrierea codului și versionarea acestuia. Acest aspect împreună cu administrarea continuă a elementelor variate ale unei aplicații constituie procesul de Integrare Continuă (Continuous Integration).

Acum că am clarificat conceptul Integrare Continuă, să înțelegem mai bine și Livrarea Continuă (Continuous Delivery/Deployment (CD)). CD a urmat ca o extensie naturală a CI, ceea ce înseamnă că fiecare integrare a echipei de dezvoltare va declanșa automat un deployment. Această abordare garantează că exact aceiași pași vor fi executați la fiecare rulare a unui deployment, minimizând nevoia unei intervenții umane și reducând drastic timpul aferent unui deployment.

CI & CD sunt concepte fundamentale în lumea noastră rapidă. În ziua de azi, software-ul este dezvoltat și îmbunătățit într-un ritm nemaiîntâlnit, iar fără concepte precum Agile sau CI & CD, acest lucru ar fi imposibil de realizat.

Ritm - Timpul de procesare pentru Deployment. Atunci VS Acum

Timpul de procesare al deploymentului unei aplicații depinde de mai mulți factori ce pot include: dimensiunea aplicației, gradul de automatizare din execuția testelor, hardening & patching, generarea rapoartelor, resursele hardware disponibile etc. Fiecare din procesele menționate anterior (și nu numai) pot reprezenta un pas în procesul de dezvoltare al oricărei aplicații care astfel poate extinde timpii de execuție. Totul depinde de cum este configurat fluxul (pipeline) de deployment și de câți pași are nevoie pentru a se finaliza execuția.

Dacă comparăm timpul necesar pentru ca un flux de deployment să fie executat automat vs. cât de mult i-ar lua unui profesionist IT să ruleze aceiași pași manual, am concluziona fără excepție că execuția automată este mai rapidă și mai fiabilă. Un flux automat poate executa aceiași pași de sute de ori cu același rezultat. Când adăugăm elemente manuale acelui proces, mai devreme sau mai târziu profesionistul IT va rata niște pași, va da valori greșite unor variabile cheie sau va uita de anumite etape vitale pentru execuție. Toate acestea se pot concretiza în sesiuni lungi de debugging, în implicarea multor oameni pentru a găsi o soluție care, mai apoi, poate întârzia deploymentul și poate necesita mai multe resurse disponibile.

Prin urmare, CD este o parte vitală pentru ciclul de viață al unei aplicații. Reduce semnificativ timpul și costurile necesare pentru ca o aplicație să ajungă la etapa finală. Nu e nimic rău să ne permitem să bem o cafea așteptând ca un deployment să fie finalizat.

Tipare - structura generală a unui flux (pipeline) Build & Deployment

Fluxurile de deployment pot varia mult ca structură în funcție de toolurile folosite pentru proces, de cerințele aplicației și de infrastructură. Totuși, sunt câteva concepte cheie care se regăsesc, în general, în orice flux de deployment:

Conceptele menționate mai sus trebuie privite cu un ochi critic, acestea depinzând de arhitectura subiacentă și de modul în care a fost configurat acel flux. Unele aplicații au dependințe diferite de altele, ceea ce duce la implementări diferite ale fluxului de deployment.

Contrast - diferența dintre DEV și OPS

În trecutul nu foarte îndepărtat, dezvoltarea și operațiunile au lucrat complet izolat unele de altele, interacționând doar la realease-uri. Programatorii, cunoscând data release-ului, tind să adauge o nouă funcționalitate până la acea dată. Pe de altă parte, echipa de operațiuni știe dinainte dacă release-ul curent va conține noi funcționalități sau nu. Deci, după ce se obține versiunea de release a unei aplicații, înainte de a face deploy la client, partea Ops testează riguros stabilitatea acestei versiuni. După ce se ajunge la un nivel satisfăcător se lansează la client.

Conflictul dintre cele două tabere și obiectivele lor aparent incongruente apare atunci când echipa de dezvoltare este motivată și evaluată conform frecvenței cu care schimbă lucrurile și cu care scalează (funcționalități, corecții, îmbunătățiri), în timp ce echipa de operațiuni este evaluată în ceea ce privește fiabilitatea și constanța, calități adesea văzute drept produs al unei frecvențe reduse de a schimba și de a scala. De multe ori, apare o relație conflictuală între cele două echipe, cauzată de efortul de a repara greșeli, activitate cronofagă ce implică riscul ca produsul final să nu se potrivească în totalitate cu nevoia originală de business.

Unitate - combinarea lui DEV cu OPS în DevOps

Soluția evidentă la comunicarea deficitară între programatori și operațiuni este sincronizarea dintre aceste două echipe, care acum se numește DevOps. Este cea mai notabilă metodă prin care o organizație poate asigura echilibrul între dezvoltare și calitate. Atât partea Dev, cât și partea Ops trebuie să adopte metodologia DevOps schimbându-și perspectiva și modul de a lucra.

Emfază - avantajele și provocările DevOps

Printre beneficiile DevOps amintim:

Ca orice artă, frumusețea DevOps este subiectivă, fiind dependentă de observator. Unii preferă o anumită abordare, în timp ce alții văd procesele complet diferit și interpretează sensul DevOps diferit. Considerăm că toți avem dreptate în felul nostru.

Pentru noi, DevOps nu este atât de mult un titlu sau o poziție, ci un mod de a gândi în care programatorii și echipa de operare lucrează împreună pentru a atinge un scop comun: să oferim software fiabil folosind cele mai recente tendințe în tehnologie de care dispunem, să învățăm, să facem lumea un loc mai bun și să ne distrăm făcând acest lucru.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects