Ce este CI/CD — explicat pentru non-tehnici

Vinerea seara, un developer rulează pe laptop șirul de comenzi care urcă noul modul de plată în producție. O literă greșită într-un nume de server, trei minute de depanare, și magazinul online pică 40 de minute — în plin weekend, când vinde cel mai mult. Nicio eroare de programare: doar un proces manual executat de un om obosit. CI/CD există ca să elimine exact acest scenariu. Pașii de livrare nu mai stau într-un document sau în memoria unui developer, ci într-un pipeline care rulează identic la fiecare schimbare de cod. Iată ce înseamnăm prin cele două litere, ce face pipeline-ul pas cu pas, ce se strică cel mai des la implementare și ce plătești de fapt când ceri «CI/CD pentru proiectul nostru».

Cele două litere: integrare continuă și livrare continuă

Fără reguli, o echipă de dezvoltare arată așa: fiecare developer lucrează pe copia lui de cod, săptămâni întregi. La final, schimbările se unesc într-o sesiune maraton în care nimeni nu mai știe ce a stricat cine — programatorii o numesc «merge hell», iar factura o plătești în zile de întârziere. CI (continuous integration — integrare continuă) interzice acest scenariu printr-o regulă simplă: orice schimbare se trimite la repository-ul comun zilnic, iar un server preia codul nou, îl construiește și rulează automat suita de teste. Dacă ceva e stricat, află în minute de la transmitere — nu peste două săptămâni, când costul reparării s-a triplat.

CD (continuous delivery — livrare continuă) continuă logica: versiunea care a trecut de build și teste este împachetată automat, identic cu ce va rula în producție, iar urcarea se face la apăsarea unui buton. Varianta extremă se numește continuous deployment: versiunea urcă singură în producție, fără niciun buton. Diferența dintre cele două e doar cine apasă butonul — și câtă încredere ai în teste.

Analogia: linia de producție cu puncte de control

Gândește-te la o linie de producție într-o fabrică: fiecare piesă trece prin aceleași puncte de control, în aceeași ordine, indiferent cine a asamblat-o. Piesa care nu trece un punct se oprește acolo — nu ajunge la client, care ar fi descoperit defectul. CI/CD e linia de producție pentru software: fiecare schimbare de cod e o piesă care trece prin construire, testare, împachetare și livrare — automat, în același fel, de fiecare dată. Alternativa e meșteșugarul care asamblează totul de mână, verifică din ochi și află de defecte din reclamațiile clienților.

Cum arată un pipeline real — pas cu pas

Un pipeline de livrare complet, în ordinea în care rulează:

1. Developerul trimite codul (push) sau deschide un pull request — o cerere de includere a schimbării.
2. Serverul de CI construiește aplicația: compilează codul și descarcă dependințele. Dacă nu construiește, totul se oprește aici.
3. Rulează testele automate — unitare și de integrare. Cum arată o suită serioasă am scris în articolul despre testare automată.
4. Rulează analiza statică și verificările de securitate: dependințe cu vulnerabilități cunoscute, cod care nu respectă standardele, chei uitate în cod.
5. Împachetează aplicația într-o versiune numerotată — exact artefactul care va ajunge în producție, nu o reconstrucție „asemănătoare”.
6. O deploiază pe staging — un mediu identic cu producția, dar fără clienți reali — unde rulează testele end-to-end.
7. Promovarea în producție: automat sau la buton, cu opțiunea de rollback la versiunea anterioară în minute.

Pentru un proiect mediu, jurnalul pipeline-ului arată așa — cu timpii reali:

✓ build       1 min 12 s   construit din commit 8f3c2ea
✓ test        4 min 03 s   248 teste trecute, 0 picate
✓ securitate     38 s      0 vulnerabilități critice
✓ împachetare    22 s      versiunea 2.4.1 creată
✓ staging      1 min 45 s   testele end-to-end au trecut
✓ producție    1 min 30 s   versiunea 2.4.1 live

Un lucru esențial de înțeles: pipeline-ul ăsta rulează la fiecare schimbare de cod, nu o dată pe lună. O echipă care livrează de cinci ori pe zi îl rulează de cinci ori pe zi. De aici vine diferența dintre o echipă care se teme de deploy și una care îl tratează ca pe un fapt divers.

Ce elimină concret automatizarea

Cele patru probleme clasice — de ce «am pus un CI» nu e de ajuns

Uneltele — GitLab CI, GitHub Actions, Jenkins — sunt partea ușoară. Un pipeline care chiar protejează producția evită patru capcane pe care le vei întâlni constant:

1. Teste lente sau instabile. O suită care rulează 40 de minute e o suită pe care developerii o ocolesc; un test care pică aleator (așa-numitul test «flaky») face ca echipa să ignore roșul, iar ignorarea roșului e exact comportamentul pe care pipeline-ul trebuia să îl elimine. Regula practică: testele de bază sub 10 minute, testele instabile reparate sau șterse imediat.
2. Pipeline decorativ. Rulează, afișează bifă verde, dar nimic nu se oprește când pică — deploy-ul în producție continuă oricum. Un CI fără putere de veto e teatru. Dacă poți livra cu testele roșii, nu ai CI; ai un screensaver.
3. Secrete în clar. Pipeline-ul are nevoie de chei de acces la servere și servicii de producție. Dacă aceste chei stau în clar în repository, oricine are acces la cod le poate citi — iar la primul audit de securitate afli că privatitatea clienților tăi depindea de o filă de Excel. Secretele aparțin într-un spațiu dedicat, cu acces restricționat și înregistrat.
4. Staging care nu seamănă cu producția. Testele trec pe staging și pică în producție pentru că staging-ul are altă versiune de bază de date, alte variabile de configurare sau altă putere de calcul. Regula: staging e identic cu producția, minus traficul real. Orice diferență dintre ele e o ghicitoare în care testele trec, iar clienții plătesc.

Ce NU face CI/CD

• Nu scrie testele în locul tău. Pipeline-ul rulează testele; calitatea lor rămâne responsabilitatea echipei. Un proiect fără teste primește un pipeline care verifică doar că codul compilează — util, dar departe de protecția reală.
• Nu garantează că funcționalitatea e corectă. Testele verifică ce au fost învățate să verifice. O cerință de business greșit înțeleasă trece prin orice pipeline cu bifă verde.
• Nu înlocuiește review-ul de cod. Automatizarea prinde defectele mecanice; omul prinde deciziile greșite de arhitectură. Proiectele serioase folosesc ambele.

Cât costă un pipeline construit corect

Estimări pentru piața românească în 2026, consecvente cu cele din seria noastră de articole tehnice:

A treia linie e cea mai frecventă la proiectele care vin spre noi după un an sau doi: «avem cod, nu avem nimic automat». Acolo nu pipeline-ul e scump — e lipsa testelor pe care ar trebui să le ruleze. De aceea orice estimare onestă pentru un retrofit începe cu o inventariere a ceea ce există, nu cu un preț de pipeline.

Patru întrebări care dezvăluie o implementare făcută bine

Chiar dacă nu scrii cod, poți evalua orice echipă care îți construiește sau întreține pipeline-ul. Răspunsul corect e în paranteze:

1. Cât durează suita de teste care rulează la fiecare schimbare? («Sub 10 minute; restul rulează nocturn.»)
2. Ce se întâmplă când pică un test? («Deploy-ul se blochează; nu există override fără înregistrare.»)
3. Cât durează un rollback la versiunea anterioară? («Un buton, sub 5 minute.»)
4. Unde stau cheile de acces la producție? («Într-un spațiu securizat dedicat, nu în repository.»)

Dacă la a doua întrebare auzi «păi, ocolim testele când e urgent», ai aflat exact ce aveai de aflat — înainte de primul incident, nu după.

Citește în continuare

• Testare software automată — ghid pentru fondatori non-tehnici
• Ce este un webhook — explicat pentru non-tehnici
• Servicii: Infrastructură & DevOps