GitLab CI/CD

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 1 din 14. Multe echipe de development se bazează pe procese de release haotice și nedocumentate, pe care o singură persoană le înțelege cu adevărat. Drumul real către producție rămâne invizibil până când ceva crapă. Paradigma dot gitlab dash c i dot yml schimbă asta transformând întregul tău ciclu de viață de build și release într-un graf secvențial, transparent. GitLab CI/CD este sistemul built-in de continuous integration și continuous deployment pentru GitLab. Este controlat în întregime de un singur fișier de configurare numit dot gitlab dash c i dot yml. Pui acest fișier în directorul root al repository-ului proiectului tău. Pentru că îi dai commit alături de codul aplicației tale, procesul tău de deployment este versionat, auditabil și accesibil oricărui developer care se uită în repository. Când dai push la un commit care conține acest fișier, GitLab îl detectează imediat și declanșează un pipeline. Un pipeline este arhitectura top-level a procesului tău de CI/CD. Este compus din două componente principale: joburi și stages. Joburile dictează ce se întâmplă de fapt. Un job conține comenzile shell sau scripturile specifice necesare pentru a executa un task, cum ar fi compilarea codului sursă, formatarea textului sau mutarea fișierelor pe un server. Stage-urile dictează când rulează acele joburi. Organizezi joburile în stages pentru a controla fluxul cronologic de execuție. Gândește-te la un pipeline standard cu trei stages. În partea de sus a fișierului tău de configurare YAML, îți declari acele stages în ordinea exactă în care vrei să ruleze: build, test și deploy. Sub această listă, îți definești joburile individuale și le mapezi la acele stages definite. Începi prin a scrie un job numit build dash job și îl atribui stage-ului de build. Scriptul său îi spune sistemului să îți compileze aplicația. Apoi, scrii un job numit test dash job, îl atribui stage-ului de test și îi dai comanda pentru a rula suita ta de teste. În cele din urmă, scrii un job deploy dash prod, îl legi de stage-ul de deploy și îi dai instrucțiunile pentru a da push aplicației compilate către mediul tău de producție. Iată ideea principală. GitLab procesează aceste stages strict în secvență. Pipeline-ul începe cu stage-ul de build. Sistemul execută jobul tău de build. Dacă acel job se termină cu succes, pipeline-ul avansează automat la stage-ul de test și execută jobul de test. Dacă testele trec, merge mai departe la stage-ul de deploy. Această ordonare strictă acționează ca un quality gate definitiv. Dacă un job pică în orice moment - de exemplu, dacă un unit test pică în timpul stage-ului de test - întregul pipeline se oprește. Stage-ul de deploy nu se va executa niciodată, ceea ce înseamnă că un cod stricat nu poate ajunge în producție. Pentru că această logică este declarată clar în fișierul YAML, UI-ul GitLab o traduce într-un graf vizual al pipeline-ului. Oricine din echipa ta poate vizualiza un commit, se poate uita la graf și poate înțelege instantaneu exact unde se află codul în pipeline, ce stage a reușit și exact unde a apărut o eroare. Punctul forte principal al acestei paradigme este centralizarea. Prin definirea stage-urilor și a joburilor într-un singur fișier root, secvența ta de deployment încetează să mai fie un mister și devine un proces lizibil și repetabil, care trăiește exact în același loc ca și codul tău. Dacă vrei să ajuți la susținerea emisiunii, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mersi că ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 2 din 14. Petreci ore întregi scriind un fișier de configurare perfect pentru un pipeline, îi dai commit și aștepți. Dar nu se întâmplă nimic. Pipeline-ul tău este complet inutil fără un motor de calcul care să aștepte să preia acele instrucțiuni. Aici intervin GitLab Runners și Executors. Există o concepție greșită des întâlnită conform căreia aplicația GitLab în sine îți rulează scripturile de build. Nu este așa. GitLab gestionează repository-ul și urmărește statusul pipeline-urilor tale, dar deleagă strict execuția propriu-zisă. Un GitLab Runner este o aplicație separată care funcționează ca un agent. Acesta face polling continuu pe instanța GitLab, întrebând dacă există job-uri pending pe care este autorizat să le gestioneze. Când găsește unul, face pull la payload-ul job-ului, execută comenzile și trimite log-urile și rezultatele înapoi către GitLab. Ai două opțiuni principale pentru a obține acești agenți. Cea mai ușoară cale este să folosești GitLab-hosted runners. Acestea sunt gestionate pentru tine pe GitLab SaaS și acoperă medii comune precum Linux, macOS și Windows. Adesea, însă, ai nevoie de un setup custom. Poate că build-ul tău necesită hardware specializat, cum ar fi un anumit GPU, sau are nevoie de acces la o rețea internă privată. În acest caz, folosești self-managed runners. Instalezi aplicația runner pe propria ta infrastructură. Poți seta scope-ul acestor self-managed runners la nivelul întregii instanțe GitLab, le poți da share într-un grup de proiecte conexe sau le poți bloca pentru un singur proiect specific. Odată ce un runner preia un job, trebuie să știe exact cum și unde să execute comenzile. Acest lucru este definit de executor. Executorul dictează mediul specific de execuție pentru job. Două dintre cele mai comune tipuri sunt executorul shell și executorul Docker. Executorul shell este simplu. Rulează job-ul direct pe sistemul de operare al mașinii host folosind un shell de terminal standard, cum ar fi Bash sau PowerShell. Din această cauză, toate dependențele trebuie să fie preinstalate pe acea mașină host. Executorul Docker funcționează diferit. Acesta ridică un container nou, izolat, pentru fiecare job în parte, rulează scripturile în interiorul său, iar apoi îi dă tear down. Acest lucru garantează un mediu complet curat de fiecare dată. Hai să parcurgem un scenariu concret și să înregistrăm local un self-managed project runner folosind un executor shell. Mai întâi, intri în setările specifice proiectului tău din GitLab și creezi un nou runner. GitLab va genera un token de autentificare unic. Apoi, instalezi aplicația GitLab Runner pe mașina ta locală. Din terminalul local, rulezi comanda register. Prompt-ul îți va cere două informații principale. Are nevoie de URL-ul instanței tale GitLab și de token-ul de autentificare pe care tocmai l-ai generat. Acest pas leagă în siguranță mașina ta locală de acel proiect specific. În cele din urmă, setup-ul îți va cere să alegi un executor. Tastezi shell. Din acel moment, ori de câte ori un job primește trigger în acel proiect GitLab, mașina ta locală îi va face pull și va executa comenzile direct în mediul terminalului local. Iată ideea cheie. GitLab este orchestratorul, dar Runner-ul și Executor-ul său formează propriu-zisa linie de producție. Prin decuplarea managementului job-urilor de execuția job-urilor, câștigi flexibilitatea de a rula pipeline-uri pe orice, de la un shared cloud container până la un server bare-metal într-un subsol încuiat. Mersi pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 3 din 14. Ai un pipeline cu douăzeci de joburi, iar fiecare începe prin rularea exact aceleiași comenzi de setup. Când acel proces de setup se schimbă, ai acum douăzeci de locuri diferite de updatat, iar dacă ratezi măcar unul, îți va strica build-ul. Rezolvarea acestei repetiții începe cu înțelegerea anatomiei unui job de CI/CD. Un job este unitatea fundamentală de execuție în GitLab CI/CD. Este definit printr-un nume și trebuie să conțină cel puțin o comandă de rulat. Acest bloc principal de execuție este definit folosind keyword-ul script. Scriptul reprezintă un array de comenzi executate în secvență de către runner. Dacă o comandă eșuează, jobul se oprește imediat și este marcat ca failed. Joburile rareori rulează în vid. Adesea au nevoie ca environment-ul să fie pregătit înainte să ruleze și uneori necesită un cleanup după. Aici intervin keyword-urile before script și after script. Ia în considerare un proiect Ruby. Înainte să rulezi testele sau să execuți un linter, trebuie să îți instalezi dependențele. Pui comanda bundle install în interiorul blocului before script. Runner-ul execută mai întâi acest before script. Dacă reușește, rulează scriptul principal. Odată ce scriptul principal se termină, se execută after script-ul. Iată ideea cheie. After script-ul rulează chiar dacă scriptul principal dă fail. Asta îl face locul corect pentru închiderea conexiunilor de rețea, ștergerea credențialelor temporare sau un cleanup al bazelor de date de test. Să scrii aceeași comandă bundle install în fiecare job de test individual devine rapid repetitiv. Ca să rezolvi asta, folosești keyword-ul default la nivelul de top al fișierului tău de configurare. Orice configurație definită sub default este moștenită automat de toate joburile din pipeline. Declari acel before script cu bundle install o singură dată, în interiorul blocului default. Acum, fiecare job îl rulează automat. Dacă un anumit job nu are nevoie de el, definești un before script gol în interiorul acelui job specific. Acea definiție locală suprascrie default-ul global. Uneori ai nevoie de o definiție de job în fișierul tău, dar nu vrei ca acesta să ruleze efectiv. Poate scrii un template de bază din care vor moșteni alte joburi, sau poate vrei să dezactivezi temporar un test flaky fără să ștergi complet codul. Faci asta ascunzând jobul. Pur și simplu adaugi un punct chiar la începutul numelui jobului. Când GitLab parsează configurația de pipeline, ignoră complet orice nume de job care începe cu un punct. Jobul nu va apărea în UI și nu se va executa. Pe măsură ce pipeline-ul tău crește, interfața web poate deveni aglomerată cu zeci de joburi individuale. Dacă ai mai multe joburi strâns legate, le poți grupa vizual în graficul de pipeline. Realizezi asta denumind joburile cu un prefix comun, urmat de un slash sau două puncte. De exemplu, dacă denumești trei joburi separate build slash ruby one, build slash ruby two și build slash ruby three, interfața le va restrânge într-un singur grup de tip dropdown, etichetat pur și simplu build. Dacă dai click pe grup, acesta se extinde pentru a afișa joburile individuale din interior. Asta nu schimbă cu nimic modul în care joburile se execută pe runnere, dar face ca un pipeline masiv să fie mult mai ușor de citit dintr-o privire. Un pipeline bine structurat separă setup-ul de execuție, folosește default-uri pentru a elimina codul duplicat și se bazează pe convenții de denumire pentru a menține interfața vizuală strict concentrată pe ceea ce contează. Asta e tot pentru acest episod. Mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 4 din 14. Hardcodarea unui API key direct în configurația de pipeline este absolut cea mai rapidă modalitate de a-ți compromite întregul mediu de producție. Ai nevoie de o modalitate de a transmite configurația și credențialele în joburi în mod dinamic, fără a le expune oricui îți poate citi repository-ul. Variabilele și secretele CI/CD sunt mecanismele care gestionează acest lucru. Ori de câte ori un runner GitLab preia un job, acesta nu pornește cu un state gol. GitLab injectează automat variabile predefinite în environment. Acestea oferă scriptului tău un context imediat. Ai acces la variabile precum CI commit branch, ID-ul de pipeline și numele proiectului. Nu tu le definești. Ele sunt pur și simplu acolo, gata de utilizare în scripturile tale pentru a direcționa logica sau pentru a pune tag-uri pe build artifacts. Dincolo de contextul predefinit, va trebui să furnizezi propriile tale variabile custom. Le poți defini în două locuri: în fișierul tău de configurare yaml sau în interfața GitLab. Regula pentru a alege unde să le pui este simplă. Dacă valoarea este sigură pentru a fi citită, cum ar fi un compiler flag sau un URL de development server, pune-o în fișierul yaml. Configurația rămâne alături de cod. Dacă valoarea este sensibilă, cum ar fi o parolă de bază de date, definește-o în UI-ul proiectului GitLab. Când plasezi un secret în UI, trebuie să îi configurezi limitele de securitate. Oamenii confundă frecvent mascarea unei variabile cu protejarea ei. Sunt concepte complet diferite. Mascarea unei variabile previne apariția valorii sale în log-urile jobului. Dacă maschezi o parolă de bază de date, iar un script scris prost încearcă să o printeze în consolă, GitLab interceptează output stream-ul. Înlocuiește textul real al parolei cu un string de asteriscuri înainte ca log-ul să fie măcar salvat. Mascarea controlează vizibilitatea în log-uri. Iată ideea de bază. Mascarea nu face nimic pentru a opri un developer să scrie un script care trimite parola către un server extern. Aici intervine protecția. Protejarea unei variabile îi limitează disponibilitatea. O variabilă protejată este injectată doar în pipeline-uri care rulează pe protected branches sau protected tags. Dacă cineva deschide un merge request dintr-un feature branch standard, pipeline-ul pe care îl declanșează pur și simplu nu va conține acea variabilă. Acest lucru previne ca un cod untrusted să acceseze secretele de producție. În plus, poți folosi setări ascunse în UI pentru o sensibilitate extremă. Odată ce o variabilă este salvată, valoarea sa este ascunsă în interfață. Nici măcar project maintainers nu pot recupera cu ușurință textul raw mai târziu, ceea ce înseamnă că cineva cu acces nu poate pur și simplu să dea un scrape pe pagina de setări pentru a-ți fura toate token-urile. Acum, gândește-te cum ajunge variabila în aplicația ta. Majoritatea variabilelor sunt injectate ca environment variables standard. Dar unele tool-uri refuză să citească environment variables și insistă să citească dintr-un fișier fizic. AWS command line interface, de exemplu, se așteaptă adesea la un credentials file formatat, care să se afle pe disk. În loc să scrii un pipeline script care creează un fișier, face dump la textul variabilei în el și apoi încearcă să îl șteargă în siguranță mai târziu, poți folosi o variabilă de tip File. Când configurezi o variabilă ca tip File în UI, runner-ul se ocupă automat de logistică. Când jobul începe, runner-ul preia valoarea text, o scrie în siguranță într-un fișier temporar pe disk-ul runner-ului și setează environment variable-ul să conțină calea fișierului, nu conținutul acestuia. Pur și simplu îți îndrepți tool-ul AWS către calea furnizată de variabilă. Când jobul se termină, runner-ul distruge fișierul automat. Securizarea pipeline-ului tău înseamnă minimizarea expunerii la fiecare pas. Nu te baza pe log masking pentru a te proteja împotriva codului malițios și nu scrie tu fișiere temporare de credențiale atunci când runner-ul poate gestiona lifecycle-ul în siguranță. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 5 din 14. Jobul tău de build se finalizează perfect, dar jobul de deploy eșuează în mod misterios cu o eroare de tip file not found. Verifici runner-ul, iar fișierele au fost cu siguranță generate cu doar câteva minute în urmă. Problema se reduce de obicei la o neînțelegere fundamentală între două cuvinte cheie: artifacts și cache. Aceste două concepte sunt frecvent confundate deoarece ambele implică salvarea fișierelor pe un runner, dar există din motive complet diferite. Cuvântul cheie cache definește o listă de fișiere și directoare menite să îți accelereze pipeline-ul. Acesta stochează dependențele descărcate între diferite rulări ale pipeline-ului. Ia ca exemplu un proiect Node standard. Jobul tău de build necesită mii de pachete în folderul node modules. În loc să le descarci din registry-ul public de fiecare dată când un developer face push la cod, configurezi un cache. Îi dai o cheie bazată pe fișierul tău package lock și îl pui să pointeze către directorul node modules. La rulările ulterioare, GitLab restaurează acele fișiere local. Iată ideea principală. Caching-ul este strict o optimizare. Dacă acel cache este șters, expiră sau dă fail la extragere, jobul tău trebuie să poată rula și să se finalizeze cu succes descărcând pachetele de la zero. Un cache lipsă înseamnă doar un pipeline mai lent, nu unul picat. Logica jobului tău nu ar trebui să depindă niciodată de prezența unui cache. Artifacts servesc unui scop arhitectural complet diferit. Cuvântul cheie artifacts specifică fișierele și directoarele generate de un job, care trebuie transmise joburilor ulterioare din cadrul aceleiași rulări a pipeline-ului. Ele nu reprezintă o optimizare. Sunt o cerință structurală pentru flow-ul tău de CI. Revenind la proiectul Node, jobul tău de build compilează codul sursă într-un director final de output numit dist. Jobul tău de deploy rulează într-un stage ulterior și are nevoie exact de acel folder dist pentru a-i da push pe serverul de producție. Deoarece joburile rulează în medii izolate, jobul de deploy nu poate pur și simplu să acceseze workspace-ul jobului de build. Rezolvi această problemă folosind artifacts. Definești folderul dist sub cuvântul cheie artifacts în jobul tău de build. Când jobul se termină cu succes, GitLab preia acele fișiere, le împachetează și le atașează pipeline-ului. Când începe jobul de deploy downstream, GitLab descarcă automat acel pachet de artifacts și îl extrage în working directory. Dacă un artifact lipsește, jobul downstream va eșua deoarece fișierele necesare efectiv nu există în workspace. Spre deosebire de un cache, nu poți pur și simplu să descarci un artifact de pe internet dacă acesta lipsește. El conține starea unică, intermediară, a rulării curente a pipeline-ului tău. Într-un fișier YAML configurat corect, adesea le folosești pe ambele în același job de build. Setezi cache-ul să vizeze folderul de dependențe pentru a economisi timp. Setezi artifacts să vizeze folderul de output compilat pentru a transmite datele mai departe. Jobul de deploy de mai târziu din pipeline nu are nevoie deloc de cache. Are nevoie doar de codul compilat, pe care îl primește fără probleme, deoarece artifacts sunt descărcate by default în toate stage-urile ulterioare. Când îți configurezi următorul pipeline, ține minte această regulă. Folosește cache-ul pentru dependențele externe pe care le descarci ca să economisești timp, și folosește artifacts pentru rezultatele interne de build pe care trebuie să le transmiți mai departe pentru a finaliza deploy-ul. Asta e tot pentru azi. Mulțumesc că m-ai ascultat — du-te și construiește ceva cool.

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 6 din 14. Tocmai ai dat commit la un typo fix într-un fișier markdown și, dintr-o dată, pipeline-ul tău declanșează o suită de teste end-to-end de douăzeci de minute. Asta e o risipă enormă atât de compute minutes, cât și de răbdare. Pentru a opri rularea unor joburi grele atunci când nu sunt necesare, controlezi execuția folosind keyword-ul rules. Keyword-ul rules determină exact când un job este adăugat într-un pipeline. Dacă folosești GitLab de ceva vreme, s-ar putea să-ți amintești că foloseai only și except pentru a filtra joburile. Acestea sunt keyword-uri legacy. Rules este înlocuitorul modern, mai puternic. Sub capotă, rules primește o listă de condiții. GitLab evaluează această listă de sus în jos. De îndată ce găsește un match, se oprește din căutat și fie adaugă jobul, fie îi dă skip, în funcție de cum ai configurat regula respectivă. Există trei condiții principale pe care le poți evalua. Prima este if. Condiția if evaluează variabilele de pipeline folosind o expresie logică simplă. Poți spune unui job de deploy să ruleze doar dacă branch-ul de commit face match cu default branch. Dacă evaluarea variabilei returnează true, regula face match. Acum, a doua condiție verifică modificările fișierelor folosind keyword-ul changes. Asta evaluează dacă push-ul curent a modificat fișiere care fac match pe un anumit path sau wildcard. Aici economisești bani reali. Ia în considerare un job greu de linter JavaScript. Nu vrei ca acest linter să consume cicluri de CPU dacă un developer de backend a atins doar fișierele de configurare ale bazei de date. Adaugi o regulă folosind changes și specifici wildcard-ul pentru fișierele dot js. Dacă commit-ul include modificări la un fișier javascript, regula face match și linter-ul rulează. Dacă nu au fost atinse fișiere javascript, jobul este exclus complet din pipeline. A treia condiție este exists. În loc să verifice variabile sau modificări recente, exists verifică pur și simplu dacă un anumit fișier este prezent în repository în acel moment. S-ar putea să ai un template generic de pipeline folosit de mai multe proiecte. Poți defini un job de build pentru container cu o regulă exists care indică spre un Dockerfile. Dacă proiectul are un Dockerfile în directorul său root, jobul rulează. Dacă nu are, jobul primește skip complet. Iată ideea cheie. Găsirea unui match nu înseamnă automat că jobul rulează. Când o regulă este evaluată ca true, aplică o instrucțiune secundară folosind atributul when. By default, o regulă care face match presupune că jobul ar trebui adăugat în pipeline. Dar poți defini explicit o regulă cu when setat pe never. Asta e foarte eficient pentru blocklisting. Poți pune o regulă în partea de sus a listei care spune că, dacă commit message-ul conține cuvântul draft, setează when pe never. Deoarece regulile sunt evaluate de sus în jos, acel job primește kill instantaneu înainte să fie verificate orice alte condiții. Dacă ții minte un singur lucru despre controlul execuției, este că ordinea dictează rezultatul. Pune regulile de excludere chiar în partea de sus a listei, pentru că în momentul în care GitLab găsește o condiție true, se oprește din citit și blochează decizia. Aș vrea să îmi iau un moment să îți mulțumesc că ne asculți — ne ajută foarte mult. Să ai o zi excelentă!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 7 din 14. Pipeline-ul tău nu este de fapt lent. Este doar limitat artificial. Probabil ai joburi rapide care așteaptă după joburi lente cu care nu au absolut nicio legătură, pur și simplu pentru că stau în aceeași coloană pe ecran. Pentru a repara asta, renunți la coloanele rigide și construiești Directed Acyclic Graphs folosind needs. În mod implicit, pipeline-urile standard se execută secvențial, pe stage-uri. Definești stage-uri precum build, test și deploy. Fiecare job din stage-ul de test trebuie să se termine complet înainte ca orice job din stage-ul de deploy să poată începe. Dacă stage-ul tău de test are cinci joburi, iar patru dintre ele se termină în două minute, în timp ce unul durează zece minute, întregul stage de deploy este blocat până la minutul zece. Bariera de execuție dintre stage-uri este absolută. Keyword-ul needs sparge această barieră. Îți permite să definești relații explicite între joburi, transformând pipeline-ul tău dintr-o secvență strictă într-un Directed Acyclic Graph. Când folosești keyword-ul needs în definiția unui job, îi spui sistemului exact ce joburi anterioare trebuie să se termine înainte ca acesta să înceapă. În momentul în care acele dependențe specifice se termină cu succes, jobul tău se declanșează. Nu mai așteaptă ca restul stage-ului să se termine. Ia în considerare un monorepo care conține atât un frontend, cât și un backend. Joburile tale de build și test pe backend sunt rapide, durând cam două minute. Jobul de build pe frontend este greu și durează zece minute. Într-un pipeline tradițional, stage-ul de deploy nu se poate declanșa până când nu se termină testele pe frontend și backend. Jobul tău de deploy pe backend este practic ținut ostatic de build-ul de frontend. Iată ideea cheie. Poți adăuga keyword-ul needs la jobul tău de deploy pe backend și poți lista doar jobul de test pe backend ca dependență a acestuia. Acum, logica de execuție se schimbă. Jobul de test pe backend se termină la minutul doi. Jobul de deploy pe backend vede că dependența sa explicită este îndeplinită și pornește imediat. Ignoră complet faptul că build-ul de frontend mai rulează încă opt minute. Stage-urile încă există pentru organizarea vizuală în user interface, dar ordinea reală de execuție este acum dictată de graful pe care l-ai construit. Pentru a configura asta, adaugi keyword-ul needs la un job și oferi un array cu numele exacte ale joburilor. Există și un beneficiu secundar aici, legat de transferul de date. În mod normal, un job descarcă artifacts de la toate joburile rulate cu succes din stage-urile anterioare. Când folosești needs, descărcarea de artifacts devine direcționată. Jobul tău va descărca artifacts doar de la joburile specifice listate în array-ul needs. Asta previne ca jobul tău de deploy pe backend să descarce assets de frontend masive și irelevante, economisind și mai mult timp în timpul inițializării jobului. Dacă ai nevoie ca un job să pornească imediat ce este creat pipeline-ul, ocolind toate întârzierile de stage, poți pasa un array gol către keyword-ul needs. Asta îi spune sistemului că jobul are zero dependențe, forțând execuția lui la secunda zero. Adevărata valoare a unui Directed Acyclic Graph este decuplarea de workflows independente în cadrul unui singur pipeline. Te oprești din a organiza joburile după momentul în care ar trebui să ruleze și începi să le organizezi pur și simplu după ce inputs au nevoie pentru a fi executate. Mulțumesc pentru ascultare. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 8 din 14. Menții un proiect open-source. Un străin îi dă fork, ascunde un script care exportă environment variables în interiorul unui unit test și deschide o contribuție. Dacă sistemul tău rulează automat acel cod pe serverele tale private, secretele tale s-au dus. Pentru a preveni asta, ai nevoie de o graniță strictă între un simplu push de cod și executarea lui într-un mediu privilegiat. Această graniță este gestionată de Merge Request Pipelines. În mod normal, GitLab declanșează un pipeline de fiecare dată când dai push la un commit pe orice branch. Un merge request pipeline se comportă diferit. Este un tip specific de pipeline configurat să ruleze pe conținutul source branch-ului, dar numai în contextul unui merge request deschis. Acest context îți oferă acces la environment variables specifice legate de merge-ul în sine, cum ar fi numele target branch-ului sau identificatorul acelui merge request. Îi spui unui job să ruleze ca un merge request pipeline folosind secțiunea rules din fișierul tău de configurare. Scrii o regulă care evaluează variabila pipeline source. Verifici dacă CI pipeline source este egal cu textul exact merge request event, scris cu underscore între cuvinte. Când aplici această regulă, jobul va rula doar atunci când un merge request este creat sau actualizat. Este foarte comun să asociezi asta cu rules care previn rularea jobului la push-uri standard pe branch. Dacă nu le separi, un push al unui commit către un merge request deschis va declanșa două pipelines în exact același timp, făcând exact aceeași treabă. Asta ne aduce la implicațiile de securitate ale contribuțiilor externe. Când cineva dă fork la repository-ul tău, creează o copie complet izolată. Dacă deschide un merge request din fork-ul său înapoi către proiectul tău părinte, orice pipeline care rulează automat se execută în interiorul fork-ului său. Folosește runnerii săi și variabilele sale. Asta este by design. Secretele proiectului tău părinte sunt în siguranță, deoarece codul contribuitorului nu are acces la infrastructura ta. Dar, în cele din urmă, trebuie să verifici dacă codul său trece de test suite-ul tău oficial folosind propriile tale credențiale de bază de date și deployment targets. GitLab îți permite să rulezi pipelines pentru aceste fork merge requests în cadrul proiectului părinte, dar necesită o acțiune umană deliberată. Un developer sau un maintainer din proiectul părinte trebuie să dea trigger manual execuției. Într-un workflow corect, maintainer-ul citește mai întâi codul trimis din fork. Trebuie să caute orice element malițios, distructiv sau prost construit. Doar atunci când maintainer-ul este absolut sigur că acel cod este safe, dă click pe buton pentru a da trigger la pipeline. Odată ce a primit trigger, acel cod extern se execută pe runnerii proiectului părinte și are acces la secretele proiectului părinte. Acel manual trigger acționează ca o poartă de securitate fizică. Asta este partea care contează. Merge request pipelines nu sunt doar o modalitate de a grupa joburile în interfața cu utilizatorul, ci sunt un mecanism fundamental de control care îți permite să evaluezi codul extern fără a-ți expune orbește infrastructura internă. Dacă vrei să ne ajuți să ținem luminile aprinse aici, poți susține emisiunea căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 9 din 14. Ai un singur fișier YAML cu cinci sute de joburi. Să schimbi o linie e ca și cum ai dezamorsa o bombă, iar execuția durează o oră, pentru că totul rulează într-un bloc masiv. Pipeline-urile downstream rezolvă asta prin împărțirea acelui monolit în workflow-uri modulare și independente. Un pipeline downstream este pur și simplu orice pipeline GitLab CI/CD declanșat de un alt pipeline. Pipeline-ul care face declanșarea se numește pipeline upstream. În loc să ruleze fiecare job într-o singură secvență, pipeline-ul upstream acționează ca un coordonator, delegând munca către pipeline-uri mai mici și concentrate. GitLab împarte pipeline-urile downstream în două tipuri specifice, în funcție de locul în care se execută. Primul tip este un pipeline parent-child. Asta se întâmplă în întregime în cadrul aceluiași proiect. Dacă ai un monorepo, un setup parent-child este exact ce ai nevoie. Pipeline-ul parent detectează ce s-a modificat și declanșează doar configurația child relevantă. Al doilea tip este un pipeline multi-project. Asta se întâmplă atunci când un pipeline dintr-un repository declanșează un pipeline dintr-un proiect GitLab complet diferit. Folosești asta pentru arhitecturi răspândite în mai multe repository-uri, cum ar fi declanșarea unui proiect de integration testing doar după ce un pipeline dintr-un proiect API standalone se termină cu succes. Configurezi ambele tipuri folosind un keyword de job specific, numit trigger. Un job trigger este fundamental diferit de un job standard. Nu conține niciodată o secțiune script. Nu execută comenzi pe un runner. Singurul său scop este să pornească pipeline-ul downstream. Pentru un pipeline multi-project, pasezi keyword-ului trigger calea către proiectul target. Pentru un pipeline parent-child, folosești keyword-ul trigger combinat cu keyword-ul include, indicând un fișier YAML diferit, aflat în același repository. Gândește-te la un pipeline parent de rutare care gestionează trei microservicii separate, stocate într-un monorepo. Pipeline-ul parent evaluează commit-ul și declanșează trei pipeline-uri child paralele. Unul se ocupă de user service, unul de payment service și unul de inventory service. Fiecare pipeline child are propriile stages, joburi și rules. Acestea se execută independent. By default, un job trigger este fire and forget. Jobul upstream pornește pipeline-ul downstream și trece pe success imediat. Dacă ai nevoie ca pipeline-ul upstream să aștepte și să oglindească statusul pipeline-ului downstream, adaugi parametrul strategy depend la jobul trigger. Asta forțează pipeline-ul parent să aștepte, ceea ce înseamnă că un fail în pipeline-ul child va face bubble up și va marca jobul parent ca failed. Iată ideea cheie. Inginerii configurează adesea pipeline-uri parent-child și presupun imediat că sunt stricate, pentru că pipeline-urile child nu apar pe pagina principală de index a pipeline-urilor. Asta este o alegere de design intenționată. Indexul principal afișează doar pipeline-urile parent pentru a preveni aglomerarea. Pentru a vedea pipeline-urile child, trebuie să dai click pe detail view-ul pipeline-ului parent. Ele sunt nested sub jobul specific care le-a declanșat. Pipeline-urile multi-project, pe de altă parte, apar în indexul de pipeline-uri al proiectelor target respective, pentru că sunt pipeline-uri top-level în acele repository-uri. Trecerea la pipeline-uri downstream te obligă să tratezi configurația CI/CD ca pe o arhitectură software reală, înlocuind un script fragil cu componente distincte care au failure domains izolate. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 10 din 14. Dacă echipa ta se bazează pe întrebări pe Slack ca să afle cine tocmai a făcut push pe serverul de staging, ai o lipsă de vizibilitate în workflow-ul tău. Ai nevoie de o metodă clară și automată prin care să urmărești exact ce cod rulează și unde, în orice secundă, iar asta este exact problema pe care o rezolvă GitLab Environments and Deployments. În GitLab, un environment este o entitate logică de tracking. GitLab nu îți face automat provision la servere și nu dă spin up la infrastructura de cloud doar pentru că ai creat un environment. Environment-ul este pur și simplu o etichetă. Îi spune lui GitLab că un anumit job din pipeline-ul tău este responsabil să facă push la cod într-o destinație specifică, cum ar fi staging sau production. Configurezi asta adăugând keyword-ul environment direct în job-ul tău de deployment. Îi dai un nume static pentru destinație. De exemplu, ai putea crea un job numit deploy to staging, iar în interiorul acelui job, setezi numele environment-ului la staging. Secțiunea script a job-ului tău se ocupă în continuare de munca propriu-zisă. Rulează comenzile care copiază fișiere, aplică configurări sau dau restart la serviciile remote. Gândește-te la scenariul în care faci deploy la un nou release candidate. Faci merge la cod și pipeline-ul pornește. Face build la aplicație, rulează suita de teste și ajunge la job-ul de deployment pe staging. Pentru că ai atașat keyword-ul environment la acest job, GitLab schimbă modul în care tratează execuția. Urmărește îndeaproape output-ul job-ului. Când script-ul tău de deployment se termină și job-ul face exit cu succes, GitLab înregistrează un eveniment formal de deployment pentru environment-ul de staging. Aici este ideea principală. Folosirea acelui singur keyword activează o întreagă suită de funcționalități de tracking pentru deployment în interfața GitLab. Dacă navighezi la meniul Operate din sidebar și selectezi Environments, vei vedea un dashboard care îți arată statusul în timp real al target-urilor tale de deployment. Pentru environment-ul tău de staging, nu mai trebuie să ghicești ce rulează. Dashboard-ul afișează exact hash-ul commit-ului activ în prezent, branch-ul din care provine acel commit, autorul codului și cu cât timp în urmă s-a terminat deployment-ul. Creează o înregistrare imuabilă, shared, a stării serverului. Toată lumea din proiect are exact aceeași vizibilitate, fără să fie nevoie să verifice log-urile serverului sau să întrebe colegii. Dacă dai click pe environment-ul de staging, vei vedea tot istoricul de deployment. Acest istoric este cel care permite rollback-uri manuale direct din UI. Dacă un nou release candidate strică de tot serverul de staging, ca să-l repari nu trebuie să scrii un revert commit sau să construiești manual un pipeline mai vechi. Deschizi lista cu istoricul, identifici ultimul deployment reușit și dai click pe butonul de rollback de lângă el. GitLab dă imediat re-run la job-ul de deployment de la acel commit mai vechi și stabil. Înlocuiește codul stricat și îți restaurează rapid environment-ul de staging la o stare funcțională. Folosind keyword-ul environment, reduci distanța dintre rularea script-urilor și tracking-ul deployment-urilor reale. Transformă un job izolat din pipeline într-o înregistrare clară și vizibilă a versiunii de software care se află în prezent pe infrastructura ta. Aș vrea să îmi iau un moment să îți mulțumesc că ne asculți, ne ajută enorm. Să ai o zi excelentă!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 11 din 14. Să-i oferi product manager-ului un URL live, pe care se poate da click, pentru fiecare feature branch, elimină complet argumentul că la tine pe mașină merge. Acest workflow se bazează în întregime pe Dynamic Environments și Review Apps. Environment-urile standard, cum ar fi staging sau production, sunt statice. Le definești o singură dată și persistă. Environment-urile dinamice sunt create on the fly. Le pornești pentru a testa un anumit branch, le folosești, și apoi le arunci. Când folosești un environment dinamic special pentru a previzualiza modificările de cod dintr-un merge request, GitLab numește asta un Review App. Pentru a crea un environment dinamic, nu poți să-i hardcodezi numele în fișierul de configurare. În schimb, folosești variabile de pipeline. Cea mai importantă variabilă pentru asta este CI commit ref slug. Această variabilă îți ia numele de branch, îl convertește în litere mici, elimină caracterele speciale și îl scurtează. Îți garantează că ai un string DNS-safe pe care să-l folosești pentru a-ți denumi atât environment-ul în GitLab, cât și resursele reale de infrastructură. Definind numele environment-ului tău ca fiind cuvântul review urmat de un slash și această variabilă slug, GitLab generează automat un environment separat, tracked, pentru fiecare branch la care dai push. Aici e ideea cheie. Crearea înregistrării de environment în GitLab e doar jumătate din bătălie. De asemenea, trebuie să rutezi reviewerii către codul efectiv deployat. Să zicem că faci spin up la o instanță AWS Lambda temporară pentru feature branch-ul tău. Când rulează scriptul tău de deployment, AWS generează un URL random pentru acea nouă funcție Lambda. Nu știi acest URL dinainte. Ai nevoie de o modalitate de a trimite acea adresă generată dinamic înapoi în interfața GitLab, astfel încât reviewerii să poată da click pe ea. Rezolvi asta folosind un tip specific de artifact numit dotenv report. În interiorul jobului tău de deployment, după ce AWS provizionează funcția Lambda și returnează endpoint-ul, scriptul tău scrie acel URL într-un simplu fișier text formatat ca o pereche key-value. Îți configurezi jobul să dea output la acest fișier ca un artifact de tip dotenv report. GitLab citește acest fișier la sfârșitul jobului și expune variabila. Apoi configurezi parametrul environment URL în definiția pipeline-ului tău pentru a citi exact acea variabilă. Datorită acestei conexiuni, merge request-ul tău va afișa acum un buton View App care rutează utilizatorii direct către acel endpoint AWS Lambda specific. Infrastructura temporară costă bani. Să lași sute de funcții Lambda stale să ruleze îți va epuiza rapid bugetul. Ai nevoie de o modalitate automată de clean up. Gestionezi asta folosind keyword-ul on stop. În jobul tău de deployment, adaugi proprietatea on stop și îi dai numele exact al unui alt job din pipeline-ul tău. Acest al doilea job conține scriptul tău de teardown al infrastructurii. Legându-le în acest fel, GitLab preia lifecycle management-ul. Când un developer dă merge la feature branch, sau șterge branch-ul, GitLab execută automat acel job de teardown. Infrastructura este distrusă imediat. Adevărata valoare a Review Apps nu constă doar în previzualizarea codului, ci în automatizarea întregului lifecycle al infrastructurii. Poți să provizionezi dinamic, să conectezi perfect și să distrugi în mod fiabil environment-uri temporare fără ca un singur developer să atingă vreodată o consolă de hosting. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 12 din 14. Să dai copy-paste la exact același script de deploy în cincizeci de repository-uri diferite garantează un lucru: când acel script va trebui inevitabil să se schimbe, vei uita să actualizezi cel puțin un repository. Soluția este scrierea de configurații DRY folosind keyword-ul include. În GitLab CI, keyword-ul include îți permite să îți împarți configurația de pipeline în mai multe fișiere mai mici, reutilizabile. În loc să menții un fișier YAML masiv, construiești un sistem modular. Când un pipeline face trigger, GitLab pune pauză, aduce toate fișierele incluse, le dă merge și apoi evaluează configurația combinată ca un întreg. Există trei subchei principale pe care le folosești pentru a aduce aceste fișiere externe. Cea mai simplă este local. Folosești include local pentru a aduce un fișier care se află în exact același repository cu fișierul tău principal de pipeline. Asta este strict pentru organizarea unui singur proiect mare. Poți să îți muți toată logica de testare într-un fișier numit test pipeline dot yml, să pui logica de deploy în deploy pipeline dot yml, și să îți păstrezi fișierul root de configurare curat prin simpla referențiere a acelor path-uri locale. A doua subcheie este project, iar aici modularitatea de pipeline scalează la nivelul întregii organizații. Include project face pull unui fișier YAML dintr-un repository complet diferit, hostat pe aceeași instanță de GitLab. Specifici path-ul proiectului extern, împreună cu path-ul fișierului și, opțional, referința specifică de branch sau commit la care vrei să faci pull. Gândește-te la o echipă de platformă care menține un pipeline central de security scanning. În loc ca cincizeci de echipe diferite de microservicii să scrie și să își mențină propriile job-uri de security, echipa de platformă menține un singur template YAML autoritar într-un proiect dedicat de platformă. Cele cincizeci de proiecte de microservicii adaugă pur și simplu un bloc include project care pointează către acel repository central. Când echipa de platformă face update la versiunea de scanner sau modifică regulile de security din template-ul lor, toate cele cincizeci de microservicii rulează automat verificările updatate la următoarea lor execuție de pipeline. Nu mai este nevoie de copy-paste repetitiv. A treia subcheie este remote. Include remote ia un URL HTTPS complet și face fetch unui fișier de configurare de pe orice web server public. Ai putea folosi asta pentru a face pull la definiții de pipeline furnizate de un vendor sau la standarde din comunitatea open source. Singura cerință strictă este ca URL-ul să fie accesibil public printr-un web request standard, fără autentificare. Acum, fii atent la partea asta. Vei întâlni adesea situația în care un fișier inclus definește un job, dar proiectul local trebuie să îl modifice puțin. GitLab gestionează asta prin comportamentul său de merge. Când fișierele sunt incluse, GitLab face un deep merge al configurațiilor. Dacă un fișier inclus definește un job numit run security scan, iar fișierul tău principal definește și el un job numit run security scan, configurația din fișierul tău principal are prioritate. Asta înseamnă că nu trebuie să renunți la un template centralizat doar pentru că proiectul tău specific are nevoie de un mic tweak. Poți da include la template-ul echipei de platformă, și apoi să definești local doar job-ul run security scan cu o variabilă updatată sau cu adăugarea unui script custom. Override-urile tale locale se aplică, în timp ce restul definiției job-ului rămâne exact așa cum a scris-o echipa de platformă. Adevărata putere a modularității de pipeline nu este doar centralizarea codului, ci designul de template-uri ca default-uri sensibile pe care proiectele downstream le pot suprascrie local prin override, fără să rupă lanțul de moștenire. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 13 din 14. Pipeline-ul tău tocmai a eșuat pentru că cineva a actualizat un snippet YAML partajat, la trei repository-uri distanță. Nu ai primit niciun avertisment și acum pierzi o oră reparând un job pe care nici măcar nu l-ai scris tu. Zilele în care te bazai pe snippet-uri YAML fragile și neversionate au apus. Componentele CI/CD și CI/CD Catalog rezolvă asta aducând fiabilitatea unui package manager direct în pipeline-urile tale. Componentele sunt configurații de pipeline reutilizabile, cu un singur scop. Ele reprezintă evoluția modernă a vechii metode include template. Cu template-urile legacy, practic importai YAML brut prin rețea. Dacă fișierul upstream se modifica, pipeline-ul tău se modifica instantaneu, adesea cu rezultate dezastruoase. Componentele rezolvă asta prin impunerea unei versionări stricte. CI/CD Catalog servește drept registry centralizat unde organizația ta poate publica, descoperi și partaja aceste componente versionate. Pentru a construi o componentă, ai nevoie de un repository cu o structură de fișiere foarte specifică. Logica de bază trebuie să stea într-un director denumit explicit templates. Poți plasa mai multe fișiere YAML în acest director, fiecare fișier reprezentând o componentă distinctă. La rădăcina repository-ului, trebuie să adaugi și un fișier readme dot md. Acest fișier markdown nu este doar o sugestie politicoasă. El funcționează ca documentație oficială afișată în Catalog, detaliind ce face componenta și ce parametri necesită. Iată ideea cheie. Componentele sunt prea rigide pentru a fi utile fără inputs. Aceste inputs acționează exact ca argumentele unei funcții pentru configurația pipeline-ului tău. Când scrii componenta YAML, declari un bloc în partea de sus care definește acele inputs acceptate. Le specifici numele, valorile default și dacă sunt required. Gândește-te la o echipă de platform engineering care implementează scanări de securitate obligatorii. Ei creează un proiect de tip componentă numit corporate-security. În directorul templates, scriu un fișier special pentru secret detection. Pentru a-l menține flexibil, definesc un singur input required numit stage. Dezvoltatorii de aplicații din întreaga companie nu mai trebuie să scrie sau să mențină ei înșiși joburi de secret detection. Pentru a consuma exact acea componentă de secret detection, un dezvoltator folosește sintaxa include component în configurația pipeline-ului său. El specifică path-ul către componenta de pe server. Apoi, adaugă simbolul at urmat de o versiune semantică, cum ar fi unu punct zero punct zero. Acesta este pasul crucial. Fixarea versiunii semantice garantează că pipeline-ul nu va pica niciodată pe neașteptate, chiar dacă echipa de platformă lansează o versiune puternic modificată doi punct zero punct zero mai târziu în acea săptămână. Dacă un dezvoltator vrea intenționat varianta bleeding edge, poate adăuga tag-ul special tilde latest în loc de un număr de versiune, dar versionarea semantică este un default mai sigur. Chiar sub declarația include, dezvoltatorul își pasează variabilele, mapând input-ul stage la orice stage din pipeline care se potrivește proiectului său specific, cum ar fi test sau pre-build. Tratarea logicii de pipeline ca software versionat schimbă modul în care echipele scalează infrastructura. Adevărata putere a componentelor nu este doar reutilizarea codului, ci garanția absolută că un pipeline care rulează cu succes astăzi va rula exact la fel și peste șase luni. Mulțumesc pentru audiție. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. GitLab CI/CD, episodul 14 din 14. Încerci să definești numele de stage al unui job folosind o variabilă CI standard, dai push la cod și primești imediat o eroare de sintaxă. Pipeline-ul refuză să ruleze. Problema este de timing. Runner-ul nu poate defini structura pipeline-ului folosind variabile pe care le primește abia după ce pipeline-ul a început deja. Exact aici intervin expresiile CI de tip compile-time. Iată ideea de bază. Variabilele standard de runtime, scrise cu un singur semn dolar, sunt evaluate de shell atunci când job-ul se execută efectiv. Până când runner-ul ajunge să le vadă, întreaga arhitectură a pipeline-ului este deja blocată. Nu poți schimba dinamic un nume de stage, un service sau o versiune de image în timpul execuției, deoarece GitLab are nevoie de aceste informații în avans pentru a construi graful pipeline-ului. Expresiile compile-time rezolvă acest lucru prin evaluarea logicii exact în momentul în care GitLab face parse la configurația ta YAML, cu mult înainte ca vreun runner să fie măcar asignat. Sintaxa folosește un semn dolar urmat de două paranteze pătrate. În interiorul acestor paranteze, scrii o expresie care este evaluată la o valoare înainte ca pipeline-ul să fie creat. Aceste expresii își extrag datele din contexte specifice. Un context este, în esență, un set restricționat de date disponibile în timpul procesului de parsing YAML. Cel mai important context este contextul de inputs, care este utilizat intens la construirea componentelor CI/CD. Ia ca exemplu scenariul unei componente de deploy dinamic. Vrei ca proiectul care consumă această componentă să transmită un nume de environment ca input. Apoi vrei să folosești acel input pentru a seta numele de stage al job-ului și pentru a dicta versiunea specifică de image Docker pe care o face pull. În configurația componentei tale, scrii câmpul stage și îi asignezi o expresie compile-time care conține inputs dot environment. Când un proiect include componenta ta, GitLab citește input-ul de environment furnizat. Evaluează expresia imediat. Graful pipeline-ului rezultat vede un nume de stage static, hardcoded, și un tag de image hardcoded. Runner-ul nu întâlnește niciodată parantezele duble. Pur și simplu primește configurația standard. Dincolo de inputs, expresiile compile-time suportă și un context de matrix, care este în prezent în versiune beta. Când generezi job-uri paralele folosind un keyword precum parallel matrix, poți folosi expresii compile-time pentru a ajusta dinamic proprietățile job-ului pe baza variabilelor specifice asignate fiecărei instanțe paralele. Asta te scutește de a fi nevoit să duplici definițiile de job doar pentru a modifica unul sau două câmpuri per rulare de matrix. Aceste expresii sunt mai puternice decât o simplă înlocuire de text. Poți scrie logica direct în paranteze folosind operatori de egalitate, precum și operatori logici AND și OR. Poți evalua dacă un input se potrivește cu un anumit string și poți modifica condiționat o valoare pe baza rezultatului. De asemenea, ai acces la funcții built-in. Funcția expand vars, de exemplu, îți permite să injectezi în siguranță valori compile-time într-un string, păstrând în același timp în mod explicit sintaxa standard a variabilelor de runtime. Asta garantează că runner-ul primește în continuare variabilele de runtime pe care le așteaptă, fără a provoca conflicte de parsing la început. Concluzia critică este că expresiile compile-time îți oferă un mecanism nativ pentru a face template la graful pipeline-ului, separând clar logica de generare structurală de execuția reală a script-ului. Ia-ți puțin timp pentru a citi documentația oficială GitLab, a examina funcțiile suportate și a încerca să faci deploy la o componentă hands-on. Dacă ai subiecte pe care ai dori să le vezi abordate într-o serie viitoare, vizitează devstories dot eu și spune-ne. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.