ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 141
Abonament PDF

Trunk based development: o călătorie în prezent

Radu Miron
Software Developer @ Zenitech



PROGRAMARE


Prezentul - momentul efemer pe care cu toții, inevitabil, îl trăim. Dar câte astfel de momente se întâmplă "fără noi", pentru că suntem pe un fir paralel, retrăind trecutul, sau planificând viitorul? Un răspuns greu de dat, cu siguranță. Câți dintre noi și-ar dori să trăiască mai mult în prezent? Putem specula că relativ mulți, bazat pe popularitatea în creștere a fenomenului mindfulness sau a meditației, ca să dăm doar două exemple.

O paralelă neașteptată

Nu, nu vom vorbi despre meditație sau mindfulness în acest articol. Dar să ne întrebăm: Ca software developers, există oare vreo zonă de activitate în care suntem expuși riscului de a fi deconectați de la realitatea "din teren"?

Să presupunem că echipa noastră lucrează la o funcționalitate nouă, cu o complexitate ridicată, în cadrul unei aplicații. Care este strategia de integrare a acestei funcționalități? Cel mai probabil, vom ținti lucrul în izolare, pe un fir paralel cu cel principal. Astfel, vom evita interferențele asupra produsului utilizat deja de către clienți. În momentul în care funcționalitatea nouă este pregătită pentru a fi livrată către consumator, aceasta este integrată pe firul principal, și toată lumea este fericită. Ați râs, așa-i?

În realitate, paragraful de mai sus se traduce în săptămâni sau luni în care dezvoltarea funcționalității respective este cea mai mică dintre probleme. Integrarea, în schimb, ne dă de multe ori dureri de cap. În ecuație există și alte echipe ce lucrează la propriile funcționalități, pe propriul fir paralel, iar procesul este repetat de n ori.

Toate echipele care lucrează în paralel pe fire separate sunt deconectate nu doar de la firul principal, dar și deconectate între ele.

Prezentul este ceva ce se doar se întâmplă în majoritatea timpului, nefiind determinat prin contribuții dese de către toți membrii activi de pe un proiect.

Un model popular de integrare

Să trecem în revistă poate cel mai folosit model de integrare a funcționalităților: git flow. Un model extrem de bine organizat, de a cărui strictețe depind probabil multe produse.

Abordarea principală a acestei metodologii sunt feature branchurile. Orice funcționalitate nouă este dezvoltată pe un fir paralel și integrată în principal atunci când este gata. Pe lângă feature branches, mai vorbim și de release branches, hot-fix branches, main branch, develop branch. Cuvânt cheie: branch.

Problema cu acest model este ca fiecare linie paralelă din ilustrația de mai jos reprezintă o realitate diferită și deconectată de celelalte. Evident că integrarea acestor realități nu e o joacă de copii. Pe lângă frustrarea adusă developerilor, una dintre cele mai pregnante probleme ale acestei abordări sunt ciclurile de release rare.

CI/CD

Conceptul de CI/CD este o abordare modernă a dezvoltării produselor software. El presupune integrarea rapidă a schimbărilor și livrarea deasă a acestora către clienți. Astfel se asigură un flux continuu de funcționalități noi, cât și de reparații ale eventualelor defecte. Clienții beneficiază astfel de un produs dinamic, în continuă îmbunătățire, iar dezvoltatorul, de un ciclu de feedback rapid, ce permite mularea pe nevoile clientului.

Baza CI/CD este reprezentată de integrarea continuă a schimbărilor de cod, ceea ce aduce în discuție un grad de incompatibilitate între git flow și CI/CD.

O schimbare de paradigmă

Acum patru ani, echipa noastră a început lucrul pe un proiect mare, unde existau deja câteva alte echipe ce lucrau intens la transformarea unui produs folosit de clienți majori. Cu un roadmap extrem de bogat și o interacțiune între echipa de produs și clienți la un nivel de invidiat, ne-am întrebat cum este posibil ca echipele de ingineri să egaleze aceasta dinamică și "la firul ierbii".

Rețeta este complexă și a fost într-un continuu proces de îmbunătățire în acești patru ani. Un singur lucru nu s-a schimbat însă: integrarea rapidă și fără efort a schimbărilor.

Faceți cunoștință cu trunk-based development (TBD), o metodologie de integrare branchless, unde toată lumea este conectată la realitatea din prezent și nimeni nu pierde timpul cu integrarea schimbărilor celorlalți.

În TBD, există un singur branch, trunchiul. Inginerii integrează des schimbări mici în acest trunchi, ușurând procesul de revizuire și reducând riscul.

Să ameliorăm puțin șocul inițial al cuvântului branchless totuși. Commiturile direct în singurul branch existent, care este și sursa release candidates (RC), sună un pic extrem, nu-i așa? Varietatea de TBD care a funcționat tot timpul pentru noi a fost folosirea short-lived feature branches. Acestea au doar rolul de a facilita procesul de revizuire și nu de a izola schimbarea pentru o perioadă lungă de timp.

TBD în practică

Totul începe local, unde developerul comite schimbarea direct în trunk. Urmează rularea unui script ce abstractizează crearea unui branch, încărcarea acestuia pe origin și deschiderea pull-requestului. Branchul creat local este șters, iar contextul mutat din nou pe trunchi, care conține deja schimbarea.

Pe branchul efemer de pe origin începe rularea unui sau mai multor pipeline-uri, care vor verifica automat schimbarea, prin rularea de unit tests, build și altele. Integrarea este blocată până acest pas este complet. În paralel cu rularea automatizării sau după aceasta, se poate derula și procesul de revizuire a schimbării de către colegi. Atunci când cele două validări sunt complete, schimbarea poate deveni parte din trunchiul principal și pe origin, readucând versiunea locală și cea de pe origin la un stadiu sincronizat.

Desigur, integrarea în trunchiul principal trebuie să declanșeze o suită de automatizări care vor valida și pregăti versiunea curentă de sursă pentru a fi transformată într-un deployable artefact, urmat de instalarea acestuia pe un mediu inițial. Aceste stadii cuprind de obicei rularea de teste end-to-end, containerizare, promovare în diverse stări de RC, rulare de smoke tests și altele.

O cultură de responsabilitate

Un aspect important ce este facilitat de către integrarea continuă este ca artefactele produse după rularea pipeline-ului pe trunchi sunt (sau ar trebui să fie) gata să ajungă în producție în orice moment.

Desigur, am abordat sistemul de automatizare care vine sa complementeze TBD, dar ce facem cu izolarea? Vrem să trăim în prezent, dar nu vrem ca acel care ne este client să trăiască în același prezent ca și noi. Nu vrem ca acesta să vadă funcționalități pe jumătate gata sau insuficient testate. Cum împăcăm și capra, și varza?

Faceți cunoștință cu conceptul de feature flags (FF).

FF sunt doar niște întrerupătoare programatice ce blochează sau permit accesul la anumite funcționalități. Revine în responsabilitatea developerilor să folosească FF pentru funcționalități mai mari, facilitând astfel în continuare schimbările mici și dese, ușor de revizuit și testat. Un alt avantaj al folosirii FF este acela că echipa de produs poate decide parametri ca data exactă când funcționalitatea va fi vizibilă în producție, clienții care vor primi early access și altele. Obținem astfel o distincție între conceptele de deployment și release. Sistemele de FF pot varia de la simple liste de valori boolean în cod, până la aplicații conexe, cum ar fi Launch Darkly sau Harness.

Concluzii

Cu un sistem CI/CD ce are la baza TBD, echipa noastră, ca și celelalte echipe ce lucrează la părțile lor de aplicație, are vizibilitate continuă asupra tuturor inițiativelor aflate în progres, iar integrarea cu acestea este cât se poate de ușoară. Deployment-urile în producție pe multiple servicii au loc ce cel puțin două ori pe săptămână, programat, dar pot interveni oricând este nevoie de un hot-fix.

Prin ancorarea în stadiul cu adevărat prezent al codului, developerilor li se reduce anxietatea legată de integrarea cu funcționalități pe care nu le cunosc, lăsându-i să se concentreze la propria misiune și la crearea unei funcționalități robuste și bine testate.

Linkuri utile

  1. https://trunkbaseddevelopment.com/

  2. https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development

LANSAREA NUMĂRULUI 142

Robotics & AI

joi, 25 aprilie, ora 18:00

sediul Accenture

Facebook Meetup StreamEvent YouTube

Conferință

NUMĂRUL 141 - Business Anlysis (BA)

Sponsori

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

INTERVIURI VIDEO