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.
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.
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.
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.
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.
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.
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?
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.
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.
