Sesiunea 5
Azure DevOps & CI/CD Pipelines
Zero to hero — de la cod la producție în mod controlat și auditabil
Introducere
Azure DevOps & CI/CD Pipelines
De ce contează acest curs
Mulți oameni știu să creeze o resursă în Azure, dar mult mai puțini înțeleg cum ajunge codul în producție în mod repetabil, controlat și sigur. Aici apare adevărata diferență dintre un administrator cloud și un inginer cloud modern.
CI/CD nu este doar automatizare. Este disciplina prin care reduci riscul de schimbare, crești viteza de livrare, obții trasabilitate completă, standardizezi între echipe și îmbunătățești compliance-ul.
Stăpânirea acestui subiect schimbă complet profilul profesional: din om care «știe Azure» în om care poate livra în Azure în mod responsabil.
Slide 2
Fluxul complet CI/CD — de la cod la producție
Cele 6 etape ale fluxului CI/CD
1. Source Control
Azure Repos sau GitHub, branch-uri, PR, code review.
2. CI Build
Restore, build, test, security scan, artifact.
3. Artifact
Pachet versionat: ZIP, container image, NuGet, Helm chart.
4. Environment
Dev → Test → UAT → Prod cu aprobări și checks.
5. CD Deploy
App Service, AKS, VM, Function, IaC.
6. Observe & Rollback
Logs, health checks, canary, blue-green, rollback.
Separă clar CI de CD. CI dovedește că aplicația se poate construi și testa. CD dovedește că aplicația se poate livra repetabil, controlat și auditabil.
Slide 3
Analogii practice — înțelege CI/CD vizual
Analogii pentru Azure DevOps și CI/CD
Fabrica auto
Azure DevOps este banda de producție. Repozitoriul este depozitul de piese, build-ul este linia de asamblare, artifact-ul este produsul ambalat, iar release-ul este camionul care livrează în magazine.
Orașul și logistica
Azure este orașul în care rulează aplicația. Azure DevOps este sistemul logistic care decide cum se construiește marfa, cine o aprobă, ce rută urmează și cum ajunge în magazin fără să se strice pe drum.
Fără CI/CD, fiecare deploy devine un mic proiect haotic: un coleg compilează local, altul copiază fișiere manual, altcineva modifică o setare în portal. Dacă apare o problemă, nimeni nu știe ce s-a schimbat.
Cu CI/CD, schimbarea devine o rutină controlată: construiești, testezi, ambalezi, aprobi, livrezi, observi și poți reveni rapid. Beneficii: mai puține erori umane, timp mai mic până la livrare, standardizare, compliance mai bun și colaborare clară între Dev, QA, Security și Ops.
Slide 4
Ce este Azure DevOps — pe scurt
Azure DevOps este o suită de servicii pentru planificare, versionare, build, test și livrare. Valoarea reală apare când conectezi codul, work items, artefactele și deploy-urile într-un singur fir logic.
Componentele Azure DevOps
Azure Boards
Backlog, work items, sprint-uri și trasabilitate completă a cerințelor.
Azure Repos
Git hosting nativ în Azure DevOps, cu suport pentru branch-uri, PR și code review.
Azure Pipelines
Automatizare CI/CD, atât YAML cât și Classic. Inima întregului flux de livrare.
Service Connections, Environments & Library
Elementele de control și integrare necesare pentru livrare sigură și auditabilă.
Slide 5
Conceptele fundamentale — dicționar esențial
Termeni esențiali Azure DevOps
| Termen | Definiție |
|---|---|
| Organization | Containerul principal din Azure DevOps. Conține proiecte, utilizatori, permisiuni și servicii. |
| Project | Spațiul de lucru pentru o aplicație, o platformă sau un produs. |
| Repository | Locul în care stă codul sursă. Poate fi Azure Repos sau GitHub. |
| Pipeline | Fluxul automat care execută build, test și deployment. |
| Stage | Grup logic mare: Build, Test, Deploy-Dev, Deploy-Prod. |
| Job | Unitate executată de un agent sau de server. |
| Step / Task | O comandă individuală: script, task Docker, AzureCLI, test, publish artifact. |
| Agent | Mașina care execută job-ul. Poate fi Microsoft-hosted sau self-hosted. |
| Artifact | Produsul rezultat din build: zip, fișier, pachet, imagine de container, chart. |
| Environment | Obiect logic ce reprezintă un mediu țintă și poate avea approvals și checks. |
| Service Connection | Identitatea prin care pipeline-ul se conectează la Azure, GitHub, ACR, Kubernetes sau alt serviciu extern. |
| Variable group / Secure files / Secrets | Metode de a injecta configurări și secrete fără a le hardcode în repo. |
Slide 6
CI versus CD — nu le confunda
CI vs CD — diferențele fundamentale
CI — Continuous Integration
Fiecare schimbare este integrată frecvent, compilată și verificată automat. Accentul este pe build, unit tests, code quality și artifact. Întrebarea CI: «Este codul bun și livrabil?»
CD — Continuous Delivery / Deployment
Continuous Delivery: pipeline-ul duce pachetul până la poarta producției și așteaptă o aprobare manuală. Continuous Deployment: sistemul merge până la livrare automată, fără intervenție. Întrebarea CD: «Poate fi pus în mediu în mod controlat și repetabil?»
Separă clar cele două concepte. CI dovedește că aplicația se poate construi și testa. CD dovedește că aplicația se poate livra repetabil, controlat și auditabil.
Slide 7
YAML vs Classic — ce alegi și de ce
Microsoft recomandă pornirea proiectelor noi cu YAML. Motivul: definiția pipeline-ului stă în repo, lângă cod, este versionată, se poate valida prin pull request și se poate standardiza prin template-uri. Classic rămâne util în organizații cu multe release-uri istorice sau echipe orientate spre UI.
YAML vs Classic — comparație
| Criteriu | YAML | Classic |
|---|---|---|
| Unde trăiește definiția | Fișier azure-pipelines.yml, versionat cu aplicația | Interfața web Azure DevOps |
| Versionare | Foarte bună — în Git | Separată de cod |
| Template-uri | Excelent | Limitat |
| Onboarding inițial | Mediu — necesită cunoștințe YAML | Foarte ușor — doar UI |
| Audit și review | Natural prin Git (PR și istoric) | Mai greu de urmărit |
| Când are sens | Platform engineering, standardizare, scale, GitOps | Legacy, demo-uri rapide, migrare treptată |
Un pipeline Classic de build poate fi exportat în YAML în anumite cazuri, dar release-urile clasice nu se exportă direct în YAML — contează când planifici migrarea.
Slide 8
Azure Repos vs GitHub — comparație și relație
Ambele pot funcționa foarte bine cu Azure Pipelines. Nu trebuie să gândești alegerea ca pe un război religios. În multe organizații, GitHub este sursa principală de cod, iar Azure DevOps este folosit pentru Boards, enterprise governance și pipelines.
Azure Repos vs GitHub
| Aspect | Azure Repos | GitHub + Azure DevOps |
|---|---|---|
| Integrare nativă | Foarte strânsă, fără service connection externă | Necesită conectare și autorizare GitHub |
| Experiență enterprise | Puternică în ecosistem Azure DevOps complet | Foarte bună, mai ales când echipa folosește deja GitHub |
| Pull requests | Da | Da, foarte matur |
| Boards linkage | Nativ | Suportat prin integrare Azure Boards - GitHub |
| Când are sens | Platforme interne, totul într-un loc | Echipă modernă, open source, colaborare externă |
Slide 9–10
Build Pipelines — ce face de fapt CI
Un build pipeline profesionist nu doar compilează — el validează. Build-ul este poarta tehnică. Dacă build-ul este instabil, tot lanțul de release devine instabil.
Etapele unui build pipeline
Checkout & Toolchain
Checkout al codului și setarea versiunii de toolchain (ex: .NET SDK, Node, Python).
Restore Dependencies
Descărcarea pachetelor și dependențelor necesare pentru build.
Build / Package
Compilarea aplicației sau construirea pachetului.
Teste & Quality
Unit tests, integration tests rapide, linting, code quality și security scan.
Publish Artifact
Publicarea artifact-ului rezultat cu naming/versioning clar pentru urmărit ce s-a livrat.
Nu livra manual ce nu poți produce repetabil în build. Build pipeline-ul este secția de control calitate din fabrică — verifici, etichetezi și abia apoi pui pe raft ca artifact.
Slide 10–11
Release & Deployment Pipelines — partea de CD
Ce înseamnă deploy-ul în realitate
Artifact-ul validat este promovat din mediu în mediu. În YAML faci asta cu multi-stage pipelines și deployment jobs. În modelul Classic faci asta cu release pipelines și stage-uri vizuale.
Deploy-ul nu înseamnă doar copiere de fișiere. Înseamnă și: setări pe environment, injecție de secrete, ordine între componente, checks și approvals, health validation, opțiune de rollback, evidență clară a cine a aprobat și ce s-a livrat.
Fluxul de promovare între medii
Dev
Deploy automat, fără approval. Viteză maximă.
Test / UAT
Approval opțional, în funcție de procesul echipei.
Prod
Approval aproape întotdeauna prezent, cu checks suplimentare.
Slide 11–12
Service Connections — identitatea pipeline-ului
Service connection-ul este podul de identitate dintre Azure DevOps și un serviciu extern: Azure subscription, GitHub, ACR, Kubernetes, Docker registry și multe altele. Tipic, pentru un deploy în Azure vei crea o conexiune Azure Resource Manager.
Bune practici Service Connections
Nume clare
Folosește naming descriptiv: sc-az-prod-rg sau sc-acr-shared.
Scop restrâns
Resource Group înainte de Subscription. Principiul least privilege.
Nu oferi acces automat
Nu autoriza toate pipeline-urile fără motiv clar.
Revizuiește periodic
Verifică cine folosește conexiunea și dacă permisiunile mai sunt necesare.
O conexiune prea largă poate transforma o greșeală YAML într-o problemă de securitate sau de cost.
Slide 12–13
Environments, Approvals și Checks
Ce este un Environment
Environment-ul este obiectul logic care îți permite să spui: «Aici deployez și aici aplic reguli de control». În jurul environment-ului poți pune approvals și checks, de exemplu aprobare manuală înainte de producție.
Acest model este foarte valoros pentru separarea responsabilităților. Dezvoltatorul scrie YAML-ul, dar aprobarea de producție poate aparține owner-ului de produs, echipei de operațiuni sau change management.
Environment-ul este poarta unei clădiri. Pipeline-ul poate ajunge la poartă automat, dar accesul final poate necesita paznic, card de acces și validare.
Model de guvernare sănătos
Dev
Fără approval, viteză mare. Deploy automat la fiecare commit.
Test / UAT
Approval opțional, în funcție de procesul echipei și maturitatea testelor.
Prod
Approval aproape întotdeauna prezent, eventual și check-uri suplimentare de business.
Slide 13–15
Strategii de Deployment
În Azure Pipelines, deployment jobs YAML au suport explicit pentru runOnce, rolling și canary. Blue-green este mai degrabă un pattern de arhitectură și routing decât un keyword nativ de strategie.
Strategii de deployment — comparație
| Strategie | Cum funcționează | Avantaj | Unde are sens |
|---|---|---|---|
| runOnce | Livrezi o singură dată în environment | Simplu și clar | Dev, Test, internal apps |
| rolling | Livrezi pe loturi de instanțe, nu toate simultan | Mai puțin risc decât all-at-once | VM-uri, grupuri de noduri |
| canary | Livrezi la subset mic, observi, apoi extinzi | Validezi pe trafic real | AKS, trafic mare, prod |
| blue-green | Două medii identice; muți traficul între ele | Rollback foarte rapid | App Service slots, routing controlat |
Rezumat pentru juniori: runOnce = totul odată | rolling = pe loturi | canary = întâi puțin și observi | blue-green = ai două lumi paralele și schimbi traficul între ele.
Slide 14–15
Blue-Green și Canary — explicații simple
Două strategii esențiale
Blue-Green
Ca două scene identice într-un teatru. Publicul se uită la scena albastră, tu pregătești scena verde în spate. Când totul e gata, schimbi reflectorul. În Azure: deployment slots pe App Service. Rollback = swap înapoi, instant.
Canary
Ca atunci când lansezi un produs nou întâi într-un singur magazin. Observi reacțiile, măsori și abia apoi scalezi la tot orașul. În Azure: AKS și controlul traficului sunt terenul natural. Necesită observabilitate bună.
Slide 16–17
Setup Zero to Hero — Pașii complet în portal
Construim un traseu didactic complet pentru livrarea unei aplicații web în Azure App Service. Presupunem că vrei să livrezi o aplicație web și, opțional, mai târziu, într-un cluster AKS.
10 pași de la zero la pipeline complet
Pasul 1 — Creează organizația și proiectul
Intră în Azure DevOps, creează o Organization dacă nu există deja, apoi creează un Project nou. Alege un nume clar, de exemplu devops-lab-webapp.
Pasul 2 — Alege sursa codului
Decide dacă vei folosi Azure Repos sau GitHub. Pentru cursuri, Azure Repos este mai simplu fiindcă totul stă în aceeași platformă.
Pasul 3 — Pregătește aplicația
Repo-ul trebuie să conțină codul aplicației și, ideal, fișierul azure-pipelines.yml.
Pasul 4 — Creează resursele Azure țintă
În portal.azure.com creează Resource Group-ul și serviciul țintă: App Service, Function App sau AKS. Pentru App Service, creează și deployment slot.
Pasul 5 — Creează Service Connection
Project settings → Service connections → New → Azure Resource Manager. Alege scopul potrivit (Resource Group) și salvează cu un nume clar.
Pasul 6 — Creează Environment-urile
Pipelines → Environments → creezi dev, test, prod. Pentru prod adaugă approval.
Pasul 7 — Creează pipeline-ul
Pipelines → New pipeline. Alege repo-ul. Dacă folosești YAML, selectează Starter pipeline și înlocuiește conținutul.
Pasul 8 — Rulează primul build
Salvezi și rulezi pipeline-ul. Verifici checkout, restore, build, tests și publish artifact. Nu treci la deploy până build-ul nu este curat.
Pasul 9 — Adaugă stage-ul de deploy
În YAML adaugi un stage Deploy cu deployment job și environment. Leagă service connection-ul creat mai devreme.
Pasul 10 — Validează trasabilitatea
Arată unde se văd logurile, artifact-ul, approval-ul, istoricul environment-ului și diferența dintre un deploy reușit și unul eșuat.
Slide 18–20
Exemplu YAML complet — Build + Deploy
Structura unui pipeline YAML sănătos
Observă elementele importante: trigger pe branch, pool Microsoft-hosted, variabile centralizate, artifact publicat în Build și deployment job cu environment dev.
Elementele cheie YAML explicate
trigger
Definește când pornește pipeline-ul. De exemplu, la orice push pe main. Poți configura și pentru PR-uri sau alte branch-uri.
pool
Alege agentul care execută job-ul. ubuntu-latest este un agent Microsoft-hosted. Poți folosi și agenți self-hosted.
variables
Evită hardcodarea repetitivă. Valorile pot fi suprascrise la rulare.
publish + artifact
Creează artifact-ul consumat mai târziu de deploy. Artifact-ul este puntea dintre build și deploy — fără el, nu există trasabilitate.
deployment job + environment
Spune explicit că nu este un job generic, ci o livrare către un environment. Permite approvals, checks și istoric de deployment.
stages
Separă clar build-ul de deploy. Fiecare stage poate depinde de altul (dependsOn) și poate rula condiționat.
Slide 21
Cum faci același lucru în Classic
Classic are două lumi istorice: build pipeline și release pipeline. Merită să le arăți, pentru că multe organizații încă le folosesc. Avantajul didactic: studenții văd foarte clar conceptul de artifact și traseul vizual dintre stage-uri.
Build Pipeline Classic
Creează pipeline-ul
Pipelines → Builds → New pipeline și alegi repo-ul.
Adaugă task-urile
Task-uri vizuale de restore, build, test și publish artifact.
Salvează și rulează
Rulează build-ul și verifică rezultatul.
Release Pipeline Classic
Creează release pipeline
Pipelines → Releases → New release pipeline.
Adaugă artifact-ul
Conectează artifact-ul provenit din build.
Configurează stage-uri
Adaugă Dev și Prod. Configurează task-urile de deployment în fiecare stage.
Activează approvals
Activează approvals înainte de Prod dacă vrei control manual.
Definiția release-ului Classic nu stă elegant în Git împreună cu aplicația și nu se poate exporta direct în YAML — contează când planifici migrarea spre YAML.
Slide 22
Cum conectezi GitHub la Azure DevOps
5 pași pentru conectare GitHub → Azure Pipelines
Verifică accesul
Asigură-te că ai acces la repo-ul GitHub și permisiuni de autorizare pentru aplicații terțe.
Alege GitHub ca sursă
În Azure DevOps, când creezi pipeline-ul, alege GitHub ca sursă în loc de Azure Repos.
Acordă autorizațiile
Azure DevOps va instala un GitHub App sau va folosi OAuth.
Service Connection
Dacă ai nevoie de resurse suplimentare, creează service connection GitHub.
Verifică webhook-urile
Pipeline-ul trebuie să pornească la push sau PR conform designului tău.
Greșeală frecventă la juniori: presupun că alegerea GitHub schimbă logica CI/CD. Nu o schimbă. Sursa codului se schimbă, dar disciplina pipeline-ului rămâne aceeași.
Slide 23
Ce greșesc cel mai des juniorii
7 greșeli clasice de evitat
Secrete în YAML
Pun secrete direct în YAML sau în repo. Folosiți Variable Groups, Key Vault sau Secure Files.
Fără artifact clar
Amestecă build-ul și deploy-ul fără artifact clar. Artifact-ul este puntea — fără el nu există trasabilitate.
Fără environments
Nu separă mediile și nu folosesc environments. Toate deploy-urile merg direct, fără control.
Service connections prea largi
Leagă service connection-uri cu acces prea mare (Subscription în loc de Resource Group).
Naming inconsistent
Nu păstrează naming consecvent pentru pipeline-uri, artifacts și environments.
Build vs Deploy confundate
Nu înțeleg diferența dintre un eșec de build și un eșec de deployment — diagnosticul devine haotic.
Fără strategie de rollback
Nu au o strategie clară de rollback. Rollback-ul trebuie gândit înainte de primul incident.
Slide 24
Model de laborator practic
5 laboratoare progresive
| Lab | Obiectiv | Servicii | Rezultat |
|---|---|---|---|
| 1 | Repo + pipeline YAML minimal | Azure Repos/GitHub, Azure Pipelines | Build reușit și artifact publicat |
| 2 | Deploy automat în Dev | App Service, Environment dev, Service Connection | Prima livrare completă end-to-end |
| 3 | Approval înainte de Prod | Environment prod cu approval configurat | Flux controlat de aprobare demonstrat |
| 4 | Blue-green demo | App Service deployment slots | Swap și rollback demonstrat live |
| 5 | Canary / AKS demo | AKS, ACR, Kubernetes manifest | Înțelegerea rollout-ului gradual |
Fiecare laborator construiește pe cel anterior, creând un traseu progresiv de la zero la un pipeline complet.
Slide 25
Troubleshooting — cum gândește un inginer bun
Când pipeline-ul eșuează, cea mai mare parte a timpului pierdut nu vine dintr-o eroare sofisticată, ci din lipsa unei metodologii simple de diagnostic.
6 pași de troubleshooting
Identifică etapa exactă
Source, restore, build, test, artifact, deploy, approval sau post-deploy validation.
Citește logul complet
Nu doar ultima eroare. Cauza reală este adesea câteva linii mai sus.
Clasifică problema
Este de cod, de agent, de permisiuni sau de target environment?
Verifică service connection și scope
Verifică dacă conexiunea există, are permisiunile corecte și este autorizată.
Verifică artifact-ul
Chiar există și este consumat din calea corectă? Verifică branch, trigger și condiții.
Verifică targetul din Azure
App Service, AKS, slot, secrets, config. Problema poate fi în infrastructură, nu în pipeline.
Slide 26
Bune practici de design pe termen lung
Principii de arhitectură și operare
Arhitectura pipeline
Folosește YAML pentru proiectele noi, separă build de deploy, standardizează template-uri între echipe, folosește environments și approvals.
Operare și siguranță
Gândește rollback-ul înainte de primul incident, leagă pipeline-ul de observabilitate, nu hardcoda secrete, revizuiește periodic permisiunile.
Cu cât pipeline-ul este mai predictibil, cu atât scade riscul de schimbare. În producție, disciplina pipeline-ului contează la fel de mult ca aplicația.
Slide 27
Concluzie
Azure DevOps și CI/CD nu sunt doar un capitol tehnic. Sunt mecanismul prin care organizația transformă codul în livrare predictibilă. Pentru un junior cloud engineer, stăpânirea acestui subiect schimbă complet profilul profesional: din om care «știe Azure» în om care poate livra în Azure în mod responsabil.
Infrastructura și aplicația nu sunt complete fără un traseu de livrare repetabil. Cloud-ul fără CI/CD este doar jumătate din poveste.
Cheat Sheet
Referință rapidă
Cheat Sheet Final — referințe rapide
Verificare rapidă — întrebări de recapitulare
1 Care este diferența fundamentală dintre CI și CD?
CI dovedește că aplicația se poate construi și testa. CD dovedește că se poate livra repetabil, controlat și auditabil.
2 De ce artifact-ul este atât de important?
Artifact-ul este puntea dintre build și deploy. Fără el, nu există trasabilitate a ceea ce s-a livrat.
3 Când alegi blue-green vs canary?
Blue-green pentru schimbare rapidă de trafic (swap). Canary pentru expunere graduală — întâi puțin și observi.
4 Ce este un Service Connection?
Podul de identitate dintre Azure DevOps și un serviciu extern (Azure, GitHub, ACR, Kubernetes).
5 Ce greșeală critică fac juniorii cu secretele?
Le pun direct în YAML sau în repo. Soluția: Variable Groups, Key Vault sau Secure Files.
Exerciții practice
Lab 1: Primul pipeline YAML
Creează un proiect Azure DevOps, adaugă o aplicație simplă (Node.js sau .NET) și configurează un pipeline YAML care face build, test și publish artifact.
Lab 2: Deploy automat în Dev
Adaugă un stage de deploy în pipeline-ul tău care livrează artifact-ul într-un App Service. Creează un environment 'dev' fără approvals.
Lab 3: Approval pentru Prod
Creează un environment 'prod' cu approval manual. Verifică fluxul end-to-end: build → deploy dev → approval → deploy prod.
Lab 4: Blue-Green cu App Service Slots
Creează un staging slot pe App Service și configurează un pipeline care face deploy în staging, apoi swap cu production.
Resurse suplimentare
Azure DevOps este un instrument puternic care evoluează constant. Rămâi la curent cu noile funcționalități și best practices prin documentația oficială și comunitate.
Ce să faci acum (A05)
- Reascultă rezumatul audio sau recitește secțiunile cheie — salt la audio.
- Verifică notele cu quiz-ul acestei sesiuni.
- Sesiunea următoare — Infrastructure as Code cu Bicep & Terraform.
Opțional: repetă termenii în Studiu sau joacă un modul din Game Hub.
Crează-ți profil
Dacă nu te loghezi, parcursul prin sesiuni rămâne doar în acest browser: nu îl vezi pe alt dispozitiv sau în alt browser și îl pierzi dacă ștergi datele site-ului ori folosești incognito.
PIN-ul nu este un cont securizat și nu trebuie să fie aceeași combinație ca parole importante (Microsoft, email bancă). Este doar o etichetă locală + sincronizare pentru progresul din Learn Cloud.
Cu prenume, nume și PIN (4 cifre) îți poți continua cursul oriunde — același cont ca în Game Hub și Realizări(vizite, audio, quiz, lectură).
Ai uitat PIN-ul?
Nu există recuperare automată a PIN-ului. Încearcă combinația salvată sau creează un profil nou cu alt nume/prenume (generând alt ID). Pentru date pe server vezi Ajutor · PIN.
Backup & date locale
Exportul este un fișier JSON pentru arhivă personală; nu îl încărca în locuri publice (poate conține pseudo-identificatori).