Azure Pipelines

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 1 din 10. Dai click printr-o interfață web, tragi câteva elemente, și build-ul tău funcționează perfect. Apoi, cineva modifică o setare, build-ul pică, și nu ai absolut niciun istoric despre cine a făcut ce sau de ce. Aceasta este capcana editoarelor vizuale și exact motivul pentru care trecerea de la Classic UI la pipeline-uri YAML este fundamentul CI/CD-ului modern. Azure Pipelines îți oferă două modalități distincte de a automatiza livrarea de software. Metoda mai veche este interfața Classic. Se bazează pe un portal web grafic unde configurezi task-uri folosind formulare și dropdown-uri. Pare accesibilă la început. Dar pe măsură ce sistemul tău crește, abordarea Classic devine o problemă majoră. Configurația trăiește în baza de date Azure DevOps, complet deconectată de codul tău sursă. Pipeline-urile YAML înlocuiesc asta cu conceptul de Pipeline-as-Code. În loc să configurezi setările într-un portal web, îți definești întregul proces de build și release într-un fișier text simplu. Faci commit la acest fișier YAML direct în repository-ul tău, păstrându-l fix lângă codul aplicației căreia trebuie să-i facă build. Unii developeri ezită să facă schimbarea, îngrijorați că o configurație bazată pe text ar putea restricționa feature-urile în comparație cu editorul vizual. Nu este cazul. Pipeline-urile YAML oferă paritate completă a feature-urilor pentru continuous integration și continuous delivery. Microsoft consideră Classic UI ca fiind legacy și își concentrează noile dezvoltări pe YAML. Este standardul enterprise pentru repetabilitate și auditare. Gândește-te la o echipă care migrează o definiție complexă de build, făcută prin drag-and-drop, într-un fișier din repository. În sistemul vechi, testarea unui nou pas de build însemna editarea configurației shared a pipeline-ului, riscând să pice build-ul pentru restul echipei. Cu YAML, pipeline-ul este ținut în version control, exact ca aplicația ta. Dacă creezi un feature branch pentru a actualiza o dependență de bază, poți modifica fișierul YAML exact în acel branch. Logica de build actualizată se aplică doar branch-ului tău izolat. Restul echipei continuă să folosească pipeline-ul din main branch fără întrerupere. Aici este ideea cheie. Pentru că pipeline-ul tău este acum doar un fișier text în Git, acesta intră în procesul tău standard de code review. Când renunți la UI, nimeni nu mai poate modifica pe ascuns un deployment target sau sări peste un pas de testare. Fiecare modificare a pipeline-ului necesită un commit. Necesită un pull request. Necesită o aprobare din partea unui coleg. Obții un audit trail permanent și incontestabil al fiecărei modificări. În plus, starea pipeline-ului tău este legată pentru totdeauna de starea aplicației tale. Dacă trebuie să faci rollback la un release de acum șase luni, fișierul YAML din acel moment exact este păstrat în istoricul tău Git. Ai garanția că vei avea instrucțiunile de build corecte pentru acea versiune mai veche a codului. Tranziția la YAML înseamnă să îți tratezi mecanismul de delivery cu exact aceeași rigoare inginerească precum software-ul pe care îl livrează. Dacă găsești aceste episoade utile și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. 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. Azure Pipelines, episodul 2 din 10. Diferența dintre un stage și un job dictează exact unde va pica pipeline-ul tău dacă înțelegi greșit alocarea de agenți. Dacă greșești, s-ar putea să te trezești că îți lipsesc brusc build artifacts exact când e timpul să rulezi testele. Anatomia unui pipeline — mai exact stages, jobs și steps — este structura care rezolvă asta. Un pipeline este un sistem ierarhic. Această structură impune cu strictețe modul în care este împărțită munca, unde rulează și în ce ordine. Ierarhia are trei niveluri. Stages conțin jobs, iar job-urile conțin steps. Un stage acționează ca o graniță logică. Grupează munca asociată la un loc. Într-o aplicație enterprise, folosești stages pentru a separa fazele majore din software delivery cycle. Ai putea defini un build stage, urmat de un testing stage separat. By default, aceste stages rulează secvențial. Un stage trebuie să se termine complet înainte să înceapă următorul. Ele acționează ca niște garduri organizaționale pentru întregul tău proces. Iată ideea cheie. Inginerii confundă frecvent stages și jobs, tratându-le ca fiind interschimbabile. Ele nu servesc aceluiași scop. Un stage este pur și simplu un container logic. Un job este o graniță fizică de execuție. Un job definește mediul real în care rulează codul tău. Fiecare job este atribuit unui agent, care este mașina sau container-ul ce îți execută task-urile. Toate operațiunile dintr-un singur job se execută pe acel agent specific. Pentru că job-urile sunt unitatea de execuție, ele se comportă diferit față de stages. Dacă pui trei jobs într-un singur stage, Azure Pipelines va încerca să ruleze acele trei jobs în paralel pe trei agenți diferiți, presupunând că ai capacitatea disponibilă. Asta înseamnă că job-urile nu partajează local file systems sau memoria. Dacă job-ul A îți compilează codul aplicației, job-ul B nu poate accesa pur și simplu acele compiled binaries de pe drive-ul local. Job-ul B rulează pe o mașină complet diferită. Dacă ai nevoie ca două procese să partajeze secvențial același spațiu pe discul local, ele trebuie puse în același job. În interiorul unui job, definești steps. Un step este cel mai mic building block al unui pipeline. Este o instrucțiune concretă, de obicei un task sau un script. Pentru că acești steps trăiesc în interiorul unui job specific, toți rulează secvențial pe exact același agent. Step unu ar putea fi un task care să îți descarce source code-ul. Step doi ar putea fi un bash script care îți rulează compiler-ul. Din moment ce împart același mediu de execuție, step doi are acces imediat și direct la fișierele pe care step unu tocmai le-a descărcat. Aplică asta la structurarea unui enterprise pipeline care face build unei aplicații, rulează unit tests și face package la rezultat. Creezi un singur stage numit Continuous Integration. În interiorul acestui stage, definești două jobs separate pentru a accelera execuția. Job unu se ocupă de primary build. Acești steps fac checkout la cod, rulează compiler-ul și fac package la binar. Job doi se ocupă de static code analysis și standalone unit testing. Pentru că acestea sunt jobs separate în cadrul aceluiași stage, ele rulează concomitent pe agenți separați. Nu se blochează reciproc, dar nici nu partajează un file system. Dacă job doi are nevoie de binarul creat de job unu, trebuie să instruiești explicit job unu să dea publish la artifact în pipeline storage, și să instruiești job doi să îi facă download. Structura dictează capabilitatea în arhitectura ta de continuous integration. Folosește stages pentru a-ți organiza workflow-ul logic, dar bazează-te pe jobs pentru a controla exact unde și cum scalează execuția ta pe mașini. Mersi că m-ai ascultat. Sper că ai învățat ceva nou.

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 3 din 10. Orice pipeline are nevoie de putere de calcul, dar alegerea unui execution context greșit îți poate dubla pe ascuns timpii de build. Poate că scrii un cod de pipeline perfect, dar dacă build-ul tău trebuie să descarce gigabytes de dependencies de la zero la fiecare rulare, echipa ta va pierde ore întregi așteptând. Acest bottleneck este exact motivul pentru care trebuie să înțelegi Execution Context, mai exact Agents și Demands. Ca să dai build la cod sau să dai deploy la software în Azure DevOps, ai nevoie de un agent. Un agent este pur și simplu un software instalabil care se conectează la organizația ta de Azure DevOps, așteaptă taskuri și execută joburi pe rând. Fiecare agent rulează pe un host machine și, în general, poți alege între două tipuri de host-uri. Poți folosi agenți Microsoft-hosted sau poți folosi agenți self-hosted. Agenții Microsoft-hosted sunt alegerea default pentru comoditate. Ceri o mașină, iar Microsoft îți oferă una din cloud pool-ul lor. Nu trebuie niciodată să faci patch la sistemul de operare sau să dai upgrade la software-ul de agent. Dar această comoditate vine cu o capcană care încurcă multe echipe. Iată ideea principală. Un agent Microsoft-hosted îți oferă un virtual machine complet nou și curat pentru fiecare rulare de pipeline. Nu ține minte ultimul tău build. Când jobul tău se termină, acea mașină este distrusă permanent. Dacă build-ul tău are nevoie de un package cache de câțiva gigabytes, îl va descărca prin rețea de la zero la fiecare rulare, asta dacă nu adaugi pași expliciți de pipeline caching ca să salvezi și să restaurezi acele date. Dacă vrei să eviți să descarci tot internetul de fiecare dată, sau dacă build-ul tău trebuie să treacă de un firewall corporate strict, folosești agenți self-hosted. Instalezi software-ul de agent pe propria ta infrastructură. Acesta poate fi un server din data center-ul tău local sau un virtual machine persistent în propriul tău cloud tenant. Pentru că mașina supraviețuiește între rulări, acele package caches, software development kits descărcate și fișierele de incremental build rămân exact acolo unde le-ai lăsat. Asta accelerează drastic timpii de execuție. Dacă vrei o cale de mijloc modernă, poți să te uiți la Managed DevOps Pools. Acestea acționează ca o alternativă de tip scale-set, unde definești base images și dimensiuni custom, iar Azure se ocupă de automatic provisioning și scaling. Asta acoperă partea despre ce sunt agenții. Acum, cum știe Azure DevOps ce agent să folosească pentru un anumit job? Asta se bazează pe un sistem de capabilities și demands. Fiecare agent self-hosted raportează o listă de capabilities înapoi la server. Multe dintre ele sunt descoperite automat de software-ul de agent, cum ar fi tipul sistemului de operare sau path-ul către tool-urile instalate, precum Node sau Python. Poți, de asemenea, să definești user capabilities custom, poate etichetând o anumită mașină ca având o placă video specifică. În definiția ta de pipeline, scrii demands care să se potrivească cu acele capabilities. Un demand garantează că jobul tău va fi rutat doar către un agent care are exact acel capability pe care îl ceri. Ia în calcul un scenariu în care dai build la o aplicație iOS. Un build de iOS necesită Xcode, care cere strict hardware Apple. Să presupunem că ai un singur pool de douăzeci de agenți self-hosted, dar doar doi dintre ei sunt Mac Mini. Pur și simplu adaugi un demand pentru capability-ul de macOS la jobul tău din pipeline. Când Azure DevOps evaluează rularea, filtrează toate mașinile de Windows și Linux din pool și îți rutează build-ul de iOS direct către unul dintre Mac Mini-urile disponibile. Alegerea agentului îți dictează întreaga arhitectură de pipeline. Microsoft-hosted te scapă de mentenanța serverelor, cu prețul de a-ți gestiona singur state-ul, în timp ce self-hosted dă la schimb întreținerea infrastructurii pentru viteză brută și persistent caches. Asta e tot pentru acest episod. Mersi că m-ai ascultat și spor la build-uri!

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 4 din 10. S-ar putea să crezi că pipeline-ul tău se execută doar atunci când cineva dă push la un commit. Dar într-un sistem matur, pipeline-urile sunt mult mai proactive, rulând diferite tipuri de validare în momente complet diferite. Vorbim despre automatizarea workflow-ului cu triggere. Triggerele definesc exact ce evenimente determină rularea pipeline-ului tău. Cel mai comun tip este triggerul de Continuous Integration, sau CI. Un trigger CI se declanșează automat de fiecare dată când se dă push la cod pe un branch specificat. În fișierul de pipeline, definești asta folosind un simplu block trigger. Poți să-i spui să asculte branch-ul main, dar să ignore anumite path-uri de fișiere, cum ar fi folderele de documentație. Asta împiedică pipeline-ul tău să piardă timpul cu build-ul aplicației atunci când cineva a corectat doar un typo într-un fișier text. Asta gestionează codul care ajunge deja pe un branch. Dar, de obicei, vrei să prinzi erorile înainte să se facă merge-ul. Asta e treaba triggerelor de Pull Request. Un trigger de PR se declanșează atunci când se deschide un pull request sau când se dă push la noi commit-uri pe acel pull request existent. Scopul său principal este să protejeze branch-ul target prin validarea codului care intră. Aici e ideea principală. Există o capcană comună în care pică developerii cu triggerele de PR. Când un pull request declanșează un pipeline, Azure Pipelines evaluează configurația folosind fișierul YAML aflat pe branch-ul sursă, nu pe branch-ul target. Logica ce guvernează validarea vine chiar de pe feature branch. Dacă faci modificări la configurația de pipeline pe feature branch-ul tău, acele modificări se aplică la rularea de PR. Triggerele de PR trebuie să fie rapide. Dacă configurezi un trigger de PR, ar trebui să-l folosești pentru a rula operațiuni rapide, cum ar fi unit tests și code linting. Vrei ca developerii să primească feedback în câteva minute. Dar unele operațiuni, cum ar fi analiza statică profundă sau scanările de securitate complexe, durează mult mai mult. O scanare de securitate de două ore îți va paraliza echipa dacă o atașezi la un trigger de PR. Asta ne aduce la al treilea tip: triggerele scheduled. În loc să reacționeze la mișcarea codului, triggerele scheduled execută pipeline-uri pe baza unui ceas. Ele folosesc sintaxa cron standard pentru a defini zile și ore specifice pentru rularea pipeline-ului. Definești un block schedules în fișierul tău YAML, specifici expresia cron și listezi branch-urile cărora vrei să le faci build. Poți combina aceste triggere pentru a construi un workflow eficient. În timpul zilei, triggerele tale de PR rulează unit tests rapide pe feature branches pentru a menține dezvoltarea în mișcare. Între timp, configurezi un trigger scheduled care să pornească acea scanare de securitate de două ore în fiecare miez de noapte pe branch-ul main. Poți chiar să setezi triggerul scheduled să se execute doar dacă s-a făcut merge la noi commit-uri de noaptea trecută. Asta sare complet peste rulare într-un weekend liniștit, economisind costuri de compute. Folosirea acestor triggere împreună îți permite să decuplezi feedback-ul rapid pentru developeri de validarea profundă a sistemului. Triggerele nu sunt doar butoane de start; sunt controalele arhitecturale care decid cum și când sunt consumate resursele tale de compute. Îți mulțumesc că ai ascultat — ne auzim data viitoare.

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 5 din 10. Hardcodarea numelor de environment direct în fișierele tale YAML este o datorie tehnică ce așteaptă să explodeze în timpul următoarei migrări de infrastructură. Când aceste nume se schimbă, nu vrei să cauți prin zeci de repository-uri pentru a le face update. State management-ul folosind Variables și Variable Groups rezolvă asta prin centralizarea configurației tale. Pipeline-ul știe deja o mulțime de lucruri despre contextul său de execuție din start. Azure oferă system variables predefinite pentru a-i da pipeline-ului tău un fel de environment awareness, fără niciun setup manual. De exemplu, dacă trebuie să știi ce branch a declanșat run-ul, folosești Build punct SourceBranch. Dacă ai nevoie de ID-ul unic al run-ului curent, folosești Build punct BuildId. Acestea sunt populate automat și gata de a fi citite. Când ai nevoie de o configurare custom, definești inline variables. Le plasezi direct în fișierul tău YAML, sub blocul variables. Asta e perfect pentru valori specifice unui singur pipeline, cum ar fi un flag de configurare pentru build sau un local file path. Asta păstrează logica self-contained. Totuși, aceste inline variables eșuează atunci când scalezi. Ia un scenariu în care ai trei pipeline-uri separate pentru microservicii. Toate trebuie să știe numele environment-ului de deploy target și un set de URL-uri shared pentru API endpoint-uri. Dacă le definești inline, te repeți în trei repository-uri. Dacă un endpoint se modifică, ai de făcut trei pull requests. Soluția este un Library Variable Group. Acesta este un key-value store centralizat, ținut în Azure DevOps Library. Creezi grupul o singură dată în UI, îl populezi cu numele de environment și API endpoint-urile, iar apoi faci referință la acel grup după nume în blocul variables din toate cele trei pipeline-uri de microservicii. Când vine ziua migrării, actualizezi Variable Group-ul în portalul DevOps, iar fiecare pipeline folosește instantaneu noile valori la următorul run. Aplici principiul Don't Repeat Yourself, păstrând configurația shared în exact un singur loc. Aici e ideea cheie. Modul în care apelezi o variabilă schimbă momentul în care Azure o evaluează. Există două sintaxe principale, iar dacă le încurci, îți vei strica pipeline-ul. Prima este macro syntax, scrisă ca un semn de dolar urmat de paranteze care încadrează numele variabilei. Macro syntax este evaluată la runtime. Azure înlocuiește variabila chiar înainte să se execute task-ul specific care o folosește. A doua este template expression syntax, scrisă ca un semn de dolar urmat de acolade duble care conțin cuvântul variables punct și numele variabilei tale. Template expressions sunt evaluate la compile time, înainte ca pipeline-ul măcar să înceapă să ruleze. Dacă încerci să folosești o variabilă pentru a decide dacă un stage ar trebui să ruleze deloc, sau pentru a defini un loop peste o listă de joburi, trebuie să folosești template expression syntax. Pipeline-ul are nevoie de acea valoare de la bun început pentru a construi execution graph-ul. Dacă o valoare este generată dinamic în timpul run-ului de pipeline de către un script, trebuie să folosești macro syntax, deoarece valoarea pur și simplu nu există la compile time. Stăpânește diferența dintre template expressions la compile time și macros la runtime, și vei elimina cele mai frustrante parsing errors de variabile în dezvoltarea pipeline-ului tău. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 6 din 10. Mascarea unui secret în log-urile din pipeline nu înseamnă că este sigur dacă l-ai introdus direct în configurația CI/CD. Când un administrator de baze de date schimbă parola respectivă, deploy-urile tale pică instantaneu până când cineva actualizează manual pipeline-ul. Pentru a remedia asta, preiei credențialele dinamic folosind Azure Key Vault. Adesea, oamenii definesc variabile secrete direct în UI-ul Azure DevOps. Dai click pe iconița lacăt, textul dispare și presupui că ești în siguranță. Stocarea secretelor în UI-ul pipeline-ului creează o postură de securitate fragmentată. Dacă o politică de enterprise impune rotirea credențialelor la fiecare treizeci de zile, găsirea și actualizarea fiecărei variabile de pipeline în zeci de proiecte este un coșmar operațional. În plus, pierzi auditul centralizat asupra a cine sau ce a accesat acele date. Abordarea secure-by-design constă în preluarea dinamică a secretelor la runtime dintr-un Key Vault de enterprise. Pipeline-ul nu deține niciodată secretul. Doar îl împrumută exact atunci când este nevoie. Pentru a realiza asta, folosești task-ul de pipeline Azure Key Vault. În primul rând, pipeline-ul are nevoie de permisiune pentru a se uita în vault-ul tău. Configurezi un service connection Azure Resource Manager în proiectul tău DevOps. Această conexiune se bazează fie pe un Service Principal, fie pe un Managed Identity. Apoi, acorzi acelei identități acces explicit de citire la secretele din Key Vault folosind Azure role-based access control sau vault access policies. Iată ideea principală. Pipeline-ul rulează sub această identitate, dovedindu-i lui Azure cine este înainte de a extrage orice date sensibile. Asta se încadrează într-un model zero-trust. Nu există credențiale permanente în repository-ul tău de cod sau în definițiile pipeline-ului. Ia în considerare un pipeline care preia un connection string de bază de date extrem de sensibil chiar înainte de a face deploy la un serviciu backend. În definiția pipeline-ului tău, chiar înainte de pasul de deployment, adaugi task-ul Azure Key Vault versiunea doi. Oferi trei input-uri principale pentru acest task. În primul rând, specifici numele service connection-ului pentru abonamentul tău Azure. În al doilea rând, furnizezi numele Key Vault-ului propriu-zis. În al treilea rând, definești o listă cu numele specifice ale secretelor pe care vrei să le descarci. Poți pasa un wildcard asterisc pentru a descărca totul, dar principiile de least-privilege dictează să soliciți doar exact ceea ce ai nevoie. Soliciți în mod specific un secret numit production-database-connection. Când pipeline-ul ajunge la acest pas, face un call către vault. Dacă identitatea are permisiune, vault-ul returnează secretul. Task-ul preia acea valoare securizată și o transformă automat într-o variabilă standard de pipeline. Numele noii variabile de pipeline se potrivește exact cu numele secretului din vault. Următorul tău pas de deployment poate acum să facă referire la acea variabilă pentru a configura baza de date, la fel ca orice text input standard. Azure Pipelines înregistrează, de asemenea, această valoare descărcată ca o variabilă secretă în background. Dacă un script printează accidental connection string-ul în consolă, sistemul îl interceptează și înlocuiește textul real cu asteriscuri în log-uri. Fetching-ul dinamic asigură că, atunci când echipa de baze de date actualizează parola principală din vault, pipeline-ul tău utilizează automat noul string la următorul său run, cu zero intervenție manuală. Sistemul tău de continuous delivery ar trebui să acționeze ca un curier securizat, ridicând servieta încuiată chiar înainte de livrare, în loc să stocheze o copie permanentă la depozit. 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. Azure Pipelines, episodul 7 din 10. Cele mai fiabile pipeline-uri enterprise nu rulează orbește de sus în jos. Ele reacționează dinamic atunci când lucrurile merg prost, făcând tear down la infrastructură după un crash sau sărind peste test suites grele în timpul unui hotfix minor. Pentru a construi acest tip de reziliență, ai nevoie de Control Dinamic: Condiții și Expresii. Fiecare job și step din Azure Pipelines are o condiție atașată, indiferent dacă o scrii explicit sau nu. By default, sistemul aplică o condiție built-in numită succeeded. Asta înseamnă că un step se execută doar dacă toate dependențele sale anterioare s-au terminat fără să arunce o eroare. Dacă step unu dă fail, step doi este skipped automat. Lumea înțelege adesea greșit când au loc aceste verificări. O condiție evaluează dacă un step ar trebui să ruleze și face asta complet înainte ca step-ul sau jobul să înceapă. Un step nu poate folosi niciodată o condiție pentru a-și evalua propriul output intern. Condiția este paznicul care stă la intrare. Ea analizează starea pipeline-ului până în acel moment exact și decide dacă step-ul are voie să înceapă. Uneori, ai nevoie în mod explicit ca un job să ruleze atunci când un step anterior pică. Ia ca exemplu un job de deployment care face spin up la o infrastructură temporară de test. Dacă deployment-ul dă crash la jumătatea drumului, comportamentul default dă skip la restul pipeline-ului. Serverele tale temporare rămân online, consumând în tăcere bugetul de cloud. Rezolvi asta adăugând un job de cleanup dedicat la finalul pipeline-ului, dar îi schimbi condiția din succeeded în failed. Acum, acest job de cleanup ignoră complet rulările cu succes. Se trezește doar ca să distrugă infrastructura temporară dacă joburile principale de deployment dau crash. Nu ești limitat la verificări de status de bază, cum ar fi succeeded, failed sau always. Poți scrie expresii custom pentru a evalua stările variabilelor și a lua decizii granulare de rutare. Azure Pipelines folosește o sintaxă funcțională pentru aceste expresii. În loc să scrii simboluri matematice, folosești funcții cu nume. Dacă vrei să verifici dacă o variabilă este egală cu o valoare specifică, folosești o funcție numită eq. Deschizi paranteze, pasezi variabila de pipeline pe care o verifici, adaugi o virgulă și oferi valoarea pe care o aștepți. Poți combina mai multe verificări făcând nesting la aceste funcții. Să presupunem că ai un job de release care ar trebui să ruleze doar dacă pipeline-ul s-a terminat cu succes și branch-ul curent este main. Începi cu o funcție and. În interiorul parantezelor sale, pasezi două argumente. Primul argument este funcția succeeded. Al doilea argument este funcția ta eq, care compară variabila de source branch cu string-ul de text pentru branch-ul main. Jobul de release se va declanșa doar dacă ambele statements evaluează la true. Folosirea expresiilor îți permite să construiești pipeline-uri care se adaptează la contextul rulării. Înainte să încheiem, dacă vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon, lucru care este mereu apreciat. Iată partea care contează. Adevărata reziliență a unui pipeline nu vine din prevenirea fiecărei erori posibile, ci din folosirea condițiilor pentru a te asigura că sistemul tău știe exact cum să gestioneze un failure atunci când se întâmplă inevitabil. Mersi că ai ascultat. Până data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 8 din 10. Ai cincizeci de microservicii și tocmai ai actualizat definiția de build pentru unul dintre ele. Acum trebuie să dai copy și paste manual la acel bloc YAML de încă patruzeci și nouă de ori. Dacă dai copy și paste la cod între pipelines, acumulezi technical debt masiv și faci imposibile update-urile globale de securitate. Soluția este Enterprise Reusability: YAML Templates. Templates te lasă să definești logica de pipeline o singură dată și să o refolosești oriunde. În Azure Pipelines, templates funcționează în două moduri complet diferite: Includes și Extends. Un template Include acționează exact ca o operațiune de copy și paste făcută de compiler-ul de pipeline. Iei o secvență comună, cum ar fi instalarea unui set de dependencies sau publicarea unui artifact, o salvezi ca un fișier YAML standalone și apoi o referențiezi din pipeline-ul tău principal. Când pipeline-ul rulează, trage conținutul acelui template extern direct în job-ul sau stage-ul tău activ. Asta e util ca să eviți să te repeți, dar tot lasă developer-ul în control complet asupra structurii de pipeline. El decide dacă, când și unde să includă template-ul tău. Aici e ideea cheie. Când o echipă centrală de platformă trebuie să impună reguli, nu folosește Includes. Folosește Extends. Un template Extends întoarce structura de control cu susul în jos. În loc ca pipeline-ul developer-ului să tragă bucăți de logică, pipeline-ul developer-ului declară că dă extend unui template central. Acel template central dictează exact acele stages, jobs și scheletul general al întregului pipeline. Developer-ul are voie doar să paseze instrucțiunile lui specifice în sloturile specifice pe care template-ul le lasă explicit deschise. Ia ca exemplu un mandat al echipei de securitate. Ei cer ca fiecare microserviciu să ruleze un scanner de cod SAST, adică static application security testing, înainte ca orice cod să dea compile. Ca să impună asta, scriu un template Extends care definește un job cu doi steps. Primul step este scanner-ul SAST obligatoriu. Al doilea step este un placeholder pentru acțiunile developer-ului. Fișierul de pipeline al echipei de development nu face altceva decât să arate spre acest template central și să furnizeze comenzile lor specifice de build acelui placeholder. Echipa de platformă garantează că scanner-ul rulează primul, de fiecare dată, fără să aibă vreodată nevoie să auditeze cincizeci de fișiere YAML individuale. Ca să pasezi aceste comenzi sau alte informații în templates, folosești Template Parameters. Lumea confundă adesea parameters cu variables, dar comportamentul lor este fundamental diferit. Variables sunt evaluate la runtime și sunt, în general, doar text structurat liber. Parameters sunt evaluați la compile time. Înainte ca pipeline-ul măcar să înceapă execuția, Azure DevOps face parse la templates și rezolvă toți parameters. Pentru că asta se întâmplă la compile time, parameters oferă safety checks stricte. Poți defini tipuri precise de parameters, cum ar fi boolean, number, sau o listă de steps. Poți impune default values sau poți restricționa input-urile la o listă predefinită de strings permise. Dacă un developer încearcă să paseze un string de text într-un parameter boolean, pipeline-ul refuză să dea compile. Acest strong typing previne erorile la runtime și se asigură că template-ul se comportă exact așa cum a intenționat echipa centrală. Prin forțarea structurii de pipeline să fie evaluată și type-checked înainte să înceapă execuția, un template Extends acționează ca o graniță arhitecturală. Separă complet ceea ce construiesc developerii de modul în care organizația securizează acel cod. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 9 din 10. Poți scrie cu ușurință un pipeline job standard care rulează un shell script pentru a da push la cod pe un server. Dar când apare un bug critic și cineva întreabă ce anume a intrat în production marțea trecută, acel job standard nu îți oferă nimic altceva decât console logs. Pentru a obține un audit trail real pentru ce a fost deployat și unde, ai nevoie de Targeting Deployments with Environments. Un Environment în Azure DevOps este o colecție logică de resurse pe care o targetezi cu un deployment. Îl numești ceva de genul production sau staging și servește ca ancoră de tracking. În loc să folosești un pipeline job standard pentru a da push la cod, folosești un keyword special numit deployment job. Când legi un deployment job de un Environment, Azure DevOps face tracking automat la commit-urile și work item-urile exacte care sunt deployate către acel target specific. Obții un deployment history complet în interfață fără să scrii nicio logică extra de logging. Există o diferență majoră în modul în care se comportă deployment jobs în comparație cu standard jobs. Un standard job descarcă automat repository-ul de cod sursă. Un deployment job nu face asta. By default, omite complet pasul de checkout. Asta îi încurcă pe mulți developeri. Motivul este simplu. Până când ajungi la faza de deployment, ar trebui să deployezi un artifact precompilat sau un container image creat într-un build stage anterior. În general, nu ai nevoie de cod sursă raw pe un deployment runner. Dacă chiar ai nevoie de repository-ul sursă, trebuie să îi spui explicit deployment job-ului să îi facă checkout. Când definești un deployment job, nu listezi o secvență plată de tasks. Împachetezi acele tasks într-o deployment strategy. Cea mai comună strategie este run once. După cum sugerează și numele, aceasta execută pur și simplu pașii tăi de deployment secvențial pe Environment. Dacă ai nevoie de ceva mai complex, poți folosi strategia canary. Canary îți permite să deployezi pe un procent mic din serverele tale, să monitorizezi erorile și apoi să faci treptat roll out la noua versiune către restul. Acest lucru limitează daunele unui release prost. În cadrul acestor strategii, task-urile tale sunt organizate în lifecycle hooks. Asta impune o structură curată. Mai întâi, ai hook-ul pre-deploy, unde poți inițializa resurse sau rula database migrations. Apoi vine hook-ul deploy, care dă push la noua versiune a aplicației tale. După aceea, hook-ul route-traffic gestionează redirecționarea de network requests către versiunea nou deployată. În cele din urmă, poți folosi post-route-traffic pentru a rula health checks sau pentru a curăța resursele vechi. Dacă ceva nu merge bine, există de asemenea hook-urile on-failure și on-success pentru a gestiona rollbacks sau notificări. Să luăm un scenariu în care folosești strategia run once pentru a da push la un container image către un Kubernetes namespace. În pipeline-ul tău, definești un deployment job care targetează environment-ul tău de production. În cadrul strategiei run once, folosești hook-ul deploy pentru a defini un task care preia container artifact-ul construit și aplică deployment manifest-ul pe cluster. Nu trebuie să faci checkout la repository, deoarece container image-ul este deja construit și stocat în registry-ul tău. Când acest pipeline rulează, task-urile se execută, iar Azure DevOps înregistrează acțiunea. Deoarece targetează un Environment, poți deschide interfața, poți da click pe production și poți vedea exact ce commit a declanșat image build-ul, ce developer l-a creat și că a ajuns cu succes în clusterul Kubernetes. Iată ideea cheie. Trecerea de la un standard job la un deployment job nu schimbă doar modul în care este structurat pipeline-ul tău. Îți transformă pipeline-ul dintr-un automation script orb într-un deployment history complet trasabil. Mersi că m-ai ascultat. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Azure Pipelines, episodul 10 din 10. Nu vrei niciodată ca un pipeline automatizat să facă push la o migrare masivă și ireversibilă de bază de date în producție într-o seară de vineri. Un pipeline complet automatizat este excelent până când se declanșează la momentul nepotrivit sau fără supraveghere umană. Aici intervin Enterprise Gates, mai exact Approvals și Checks, pentru a rezolva această problemă. Înainte de a examina aceste checks specifice, trebuie să clarificăm o concepție greșită des întâlnită. Approvals și checks nu sunt definite în fișierul tău de pipeline YAML. Ele sunt configurate în UI-ul Azure DevOps, direct pe resursă, cum ar fi un Environment sau un Service Connection. Această distincție contează enorm. Dacă aceste reguli ar fi în fișierul YAML, un developer ar putea edita fișierul pe un feature branch, ar putea elimina acele checks de producție și ar ocoli controalele. Prin plasarea configurării pe resursă, owner-ul resursei este cel care impune regulile. Asta face ca procesul tău de compliance să fie tamper-proof. Codul din pipeline pur și simplu face un request pentru a folosi resursa, iar resursa decide dacă sunt îndeplinite condițiile de deploy. Să aplicăm asta pe un scenariu concret. Ai un environment numit Production. Vrei să impui siguranța de release și compliance-ul ITIL fără să îți pierzi automatizarea. În primul rând, vrei să previi deploy-urile în weekend. Pe environment-ul de Production din UI, adaugi un check de Business Hours. Definești fereastra de timp permisă, poate de luni până joi, de la nouă la cinci în fusul tău orar local. Dacă un pipeline încearcă să facă deploy în afara acestei ferestre, se pune pe pauză. Așteaptă într-un state de pending până când începe programul de business hours. Gata cu migrările de vineri seara. Mai departe, ai nevoie de un sanity check uman. Adaugi un check de Manual Approval și îl asignezi unui grup specific, cum ar fi echipa de QA. Când pipeline-ul ajunge la stage-ul de deploy pentru Production, se oprește. Un email este trimis către echipa de QA. Ei fac review la modificări și dau explicit approve sau reject la run în portalul Azure DevOps. Doar după approval își reia pipeline-ul execuția. Poți chiar să impui secvența de evaluare, cerând ca acel check de Business Hours să treacă înainte să fie trimisă notificarea de manual approval. Acum, trebuie să te asiguri că nu se strecoară cod experimental. Implementezi Branch Control. Adaugi un check care spune că doar main branch-ul are voie să facă target pe environment-ul de Production. Dacă cineva dă trigger la pipeline de pe un feature branch, acel check dă fail automat. Deploy-ul este blocat înainte măcar să încerce să ruleze. În cele din urmă, există problema de concurrent deployments. Dacă doi developeri dau merge la cod la zece minute distanță, s-ar putea să te trezești cu două pipeline-uri care încearcă să actualizeze aceeași infrastructură de producție simultan. Check-ul de Exclusive Lock previne acest race condition. El se asigură că doar un singur pipeline run poate accesa environment-ul la un moment dat. Al doilea pipeline așteaptă pur și simplu într-un queue până când primul se termină, garantând un istoric de deploy curat și secvențial. Iată insight-ul cheie. Approvals și checks iau puterea de a face deploy din codul de pipeline și o dau owner-ului de infrastructură, creând o graniță sigură și imposibil de modificat în jurul sistemelor tale critice. Deoarece acesta este episodul final al seriei noastre Azure Pipelines, îți recomand cu căldură să consulți documentația oficială Microsoft și să încerci aceste configurări hands-on. Dacă vrei să sugerezi subiecte pentru următoarea noastră serie, treci pe la devstories dot eu. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat și continuă să construiești!