---
title: "CI/CD pentru dezvoltare agentică: de la modificare la lansare controlată"
description: "CI/CD pentru cod scris cu AI: teste, artefacte verificabile, medii protejate, aprobări și lansare controlată în producție."
canonical: https://i8.ro/blog/ci-cd-pentru-dezvoltare-agentica-de-la-modificare-la-lansare-controlata
---

# CI/CD pentru dezvoltare agentică: de la modificare la lansare controlată

> CI/CD pentru cod scris cu AI: teste, artefacte verificabile, medii protejate, aprobări și lansare controlată în producție.

Sursă: https://i8.ro/blog/ci-cd-pentru-dezvoltare-agentica-de-la-modificare-la-lansare-controlata

**Seria II: De la infrastructură la proiecte agentice în producție. Episodul 13 din 20.**

Un agent de programare a pregătit pentru portalul B2B fictiv din serie un export CSV, adică un fișier tabelar cu valori separate prin delimitatori. Codul trece testele, iar dependențele au fost verificate. Mai rămâne o întrebare: cum ajunge această schimbare în producție, cu aceleași dovezi și cu o persoană care acceptă lansarea? Pentru un IMM, propunerea acestui episod este un flux automat de verificare și pregătire a versiunii, urmat de o aprobare explicită pentru instalarea în producție.

## Ce automatizăm prin CI/CD

**CI**, integrarea continuă, înseamnă integrarea frecventă a schimbărilor în codul comun, însoțită de construire și teste automate. Un *pipeline* este succesiunea de etape și condiții care execută aceste operații. O verificare automată pe o ramură ajută, însă practica presupune și integrarea efectivă, nu doar păstrarea multor ramuri testate separat.

**Continuous delivery**, livrarea continuă, urmărește ca software-ul să fie pregătit pentru lansare, cu un proces repetabil. Decizia de lansare poate rămâne umană. **Continuous deployment**, lansarea continuă automată, duce schimbările care trec condițiile fluxului direct în producție, fără o aprobare umană separată pentru fiecare lansare. Prescurtarea CD poate desemna ambele, de aceea precizăm ce alegem.

Distincția este explicată de Martin Fowler și tratată în cercetarea despre practicile continue. Sinteza academică a lui Shahin și a colaboratorilor, publicată în 2017, identifică testarea, transparența echipei și infrastructura potrivită printre factorii importanți. Este un reper conceptual anterior agenților actuali, nu o dovadă că automatizarea va aduce un anumit câștig portalului nostru.

## Un traseu concret pentru exportul CSV

Folosim un scenariu ipotetic, fără rezultate atribuite unui client. Agentul care dezvoltă portalul propune schimbarea într-un *pull request*, o cerere de integrare a codului. Cerința precizează coloanele exportate, păstrarea diacriticelor și accesul doar la solicitările organizației utilizatorului. Echipa stabilește verificările înainte de integrare.

| Etapă propusă | Ce verificăm | Ce permite continuarea |
| --- | --- | --- |
| Cerere de integrare | Diferența de cod, teste, dependențe și configurația fluxului | Review și verificări obligatorii reușite |
| Construirea versiunii integrate | Commitul final, imaginea aplicației, inventarul componentelor și proveniența | Artefact identificat și verificat |
| Mediu de preproducție | Exportul, autorizarea și compatibilitatea configurației | Teste de integrare și acceptare reușite |
| Aprobare pentru producție | Dovezile, riscurile și planul de revenire | Decizia responsabilului desemnat |
| Instalare și control ulterior | Versiunea instalată și funcțiile esențiale | Confirmarea funcționării sau oprirea lansării |

**Preproducția**, numită și *staging*, este un mediu de verificare apropiat de producție, fără a folosi inutil date reale. Testele pe cererea de integrare nu înlocuiesc verificarea versiunii finale: îmbinarea altor schimbări poate modifica rezultatul. Construim și testăm candidatul de lansare din commitul integrat, adică versiunea precisă salvată în depozitul de cod.

## Același artefact, configurație potrivită mediului

Un **artefact** este pachetul rezultat din construire, de exemplu imaginea containerului aplicației. Propunem promovarea aceluiași artefact verificat din preproducție în producție. Îl identificăm printr-un **digest**, o amprentă criptografică a conținutului, și păstrăm legătura cu sursele, testele și inventarul SBOM, lista structurată de componente software din episodul anterior.

Nu reconstruim pe serverul de producție folosind dependențe care s-ar putea schimba între timp. Secretele și configurația mediului sunt furnizate separat. Această strategie cere ca aplicația să permită configurarea la rulare. Dacă anumite valori sunt fixate la construire, documentăm diferența și testăm artefactul destinat producției; nu pretindem că două pachete diferite sunt același candidat.

Fișa lansării înregistrează identificatorul execuției, commitul, digestul, mediul, testele și aprobatorul. După instalare, citim versiunea efectiv rulată. Eticheta „ultima versiune” este insuficientă pentru a demonstra ce pachet a ajuns la utilizatori.

## Aprobarea trebuie aplicată de platformă

Agentul poate modifica aplicația și propune ajustări ale pipeline-ului, dar drepturile sale nu trebuie să îi permită eliminarea verificărilor obligatorii sau schimbarea aprobatorilor. Configurația de livrare este și ea cod care necesită review. Politica echipei stabilește cine administrează protecțiile și cine poate autoriza o excepție.

GitLab oferă aprobări pentru medii protejate în edițiile Premium și Ultimate, conform documentației. Aprobarea nu pornește automat jobul aferent, adică sarcina de instalare; acesta trebuie pornit manual. În GitHub, aprobatorii obligatorii ai mediilor au condiții de disponibilitate: pentru planurile Free, Pro și Team sunt disponibili doar în depozite publice. Verificăm planul și versiunea platformei înainte de a proiecta fluxul în jurul unei funcții.

Un simplu buton „rulează manual” nu este echivalent cu o aprobare independentă. Testăm cine poate declanșa, aproba și ocoli fiecare control. Dacă platforma aleasă nu oferă protecția necesară, stabilim un mecanism alternativ cu drepturi limitate și dovadă de aprobare, apoi îi verificăm comportamentul.

## Identități separate și execuții controlate

Etapa de testare a codului propus nu primește credențiale pentru producție. Etapa autorizată de instalare primește doar accesul necesar mediului respectiv. Un *runner*, procesul sau calculatorul care execută etapele pipeline-ului, trebuie administrat ca parte a infrastructurii proiectului. Numele unui mediu protejat nu garantează izolarea calculatorului care execută codul.

Pentru portal, propunem spații curate de execuție și separarea lucrărilor care rulează cod neverificat de cele care instalează versiuni aprobate. Evităm lansări simultane asupra aceluiași mediu și verificăm că o execuție mai veche nu înlocuiește o versiune mai nouă. Regulile sunt necesare indiferent dacă agentul lucrează în mediul de dezvoltare (IDE), terminal sau cloud.

## Lansarea nu se termină la un job verde

După instalare, verificăm pornirea aplicației, răspunsurile serviciilor și câteva comportamente esențiale. Pentru exportul CSV, controlăm o solicitare cu diacritice, un utilizator autorizat și refuzul accesului din altă organizație, folosind conturi și date de test adecvate. Păstrăm rezultatele și stabilim cine urmărește erorile în intervalul de verificare.

Un **rollback** este revenirea la o versiune anterioară. Păstrăm artefactul anterior și procedura de instalare, însă revenirea aplicației nu inversează automat modificările datelor. O **migrare** este o schimbare a structurii sau conținutului bazei de date; ștergerea unui câmp poate face versiunea veche inutilizabilă.

Pentru schimbări de schemă, propunem pași compatibili: adăugarea structurii noi, adaptarea aplicației și abia ulterior eliminarea celei vechi. Testăm compatibilitatea și planul de recuperare înainte de lansare. Restaurarea unui backup poate pierde scrierile ulterioare, deci nu este un înlocuitor automat pentru revenirea codului. Dacă verificarea eșuează, responsabilul oprește continuarea și alege remedierea potrivită stării reale.

Rezultatul este o fișă CI/CD cu etape, dovezi și aprobări. Agenții care dezvoltă portalul folosesc acest flux; agenții integrați ulterior în aplicație sunt componente ale produsului, cu identități distincte. Episodul următor va explica observabilitatea, prin care aflăm ce se întâmplă după lansare și când trebuie intervenit.

## Surse

Surse verificate la 14 octombrie 2026:

- [GitLab, Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/), pentru ediții, aprobări și pornirea jobului.
- [GitHub, Deployments and environments](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments), pentru protecții, disponibilitate și limitele izolării.
- [Martin Fowler, Continuous Delivery, 30 mai 2013, actualizat la 12 august 2014](https://martinfowler.com/bliki/ContinuousDelivery.html), pentru distincția dintre livrare și lansare automată.
- [Shahin, Babar și Zhu, Continuous Integration, Delivery and Deployment: A Systematic Review, 2017](https://arxiv.org/abs/1703.07019), pentru reperele conceptuale și provocările practicilor continue.

Vrei un flux de lansare verificabil pentru codul scris de oameni și agenți? [Discută cu i8 despre CI/CD, medii protejate și criterii de acceptare.](https://i8.ro/contact)