Blue-green deployment fără downtime în România

Cum arată o lansare fără întreruperi

Ridicăm mediul nou lângă cel care servește traficul, îl pornim cu aceeași configurație și rulăm pe el teste de fum. Dacă trec, mutăm traficul la nivel de ingress sau echilibrator, cu golirea conexiunilor deschise, ca nimeni să nu rămână cu o cerere tăiată la jumătate. Mediul vechi rămâne pornit până metricile confirmă că versiunea nouă se comportă corect. Dacă nu, comutăm înapoi imediat, fără reconstrucție și fără reinstalare.

• Teste de fum rulate automat înainte de comutare
• Golirea conexiunilor și a sesiunilor la schimbarea traficului
• Canary pe procente de trafic, cu praguri pe rata de erori și latență
• Comutatoare de funcționalitate pentru schimbările riscante

Bune practici pe care le aplicăm la fiecare lansare

Zero downtime nu vine din unealta folosită, ci din disciplina aplicată la fiecare pas. Lista de mai jos este exact ceea ce verificăm înainte, în timpul și după comutarea traficului, și rămâne scrisă în procedura de lansare pe care o primești la predare. O respectăm și când lansarea pare banală: incidentele mari vin aproape întotdeauna din livrări pe care cineva le-a considerat prea mici ca să merite verificări.

• Migrările care rup compatibilitatea nu pleacă niciodată împreună cu codul
• Teste de fum automate, obligatorii înainte de mutarea traficului
• Rollback într-o singură comandă, exersat, nu doar documentat
• Mediul vechi rămâne activ până metricile confirmă versiunea nouă
• Fereastră de lansare aleasă după orele de lucru ale clienților tăi din România

Migrările de bază de date, partea grea

Codul se comută în secunde, schema nu. De aceea împărțim orice modificare în două etape: mai întâi extindem, adică adăugăm coloane sau tabele pe care le înțeleg ambele versiuni, apoi, după ce versiunea nouă este stabilă, restrângem și ștergem ce nu mai e folosit. Între cele două etape, aplicația veche și cea nouă pot rula în paralel. Așa un rollback nu întâlnește o schemă pe care versiunea anterioară nu o mai recunoaște.

• Etapa de extindere: adăugăm, nu ștergem și nu redenumim
• Scriere dublă sau valori implicite pentru compatibilitate
• Etapa de restrângere abia după confirmarea versiunii noi

Ce intră în orele incluse

Punerea procedurii de lansare intră în orele lunare: 1–8 ore pe planurile VPS, 5–10 ore pe servere dedicate, în funcție de plan, și 10 ore pe GPU. Ceri lucrarea din panoul de client, la Servicii DevOps, și propui termenul, de obicei înaintea unei lansări importante. Prima configurare cere de regulă cea mai mare parte a cotei; după ea, fiecare lansare devine rutină pentru echipa ta. Ce depășește cota se acceptă și se facturează separat, la oră.

Cum lucrăm

1. Ceri lucrarea din panou

   Descrii cum lansați acum, ce se strică cel mai des și când aveți următoarea versiune importantă, apoi propui un termen.

2. Stabilim scopul și termenul

   Alegem între blue-green, canary sau rolling update, în funcție de arhitectură, și stabilim pragurile la care se oprește lansarea.

3. Livrăm și exersăm rollback

   Configurăm mediile, testele de fum și comutarea, apoi facem o lansare de probă și un rollback real, ca procedura să fie verificată.

4. Predăm cu documentație

   Primești procedura de lansare, comanda de rollback, pragurile de oprire și regulile pentru migrările de schemă, în repozitoriul tău.

Cazuri de utilizare

Tehnologii

• Kubernetes
• Argo Rollouts
• Flagger
• Traefik
• NGINX
• GitHub Actions
• Flyway
• Prometheus
• Unleash

Întrebări frecvente

• Ce este blue-green deployment?

  Sunt două medii identice: unul servește traficul, celălalt primește versiunea nouă. Se testează pe mediul liber, apoi traficul se mută integral pe el. Vechiul rămâne pornit ca plasă de siguranță, deci revenirea este o comutare, nu o reinstalare.

• Blue-green sau canary: care strategie e potrivită?

  Blue-green este mai simplu și potrivit când vrei o comutare curată, cu rollback rapid. Canary este mai bun când vrei să vezi comportamentul pe trafic real înainte de a expune toți utilizatorii, dar cere metrici de încredere și praguri stabilite din timp.

• Cum fac deploy fără downtime pe Kubernetes?

  Cu rolling update corect configurat ajungi deja departe: probe de readiness, PodDisruptionBudget și golirea conexiunilor. Pentru control mai fin adăugăm Argo Rollouts sau Flagger, care fac blue-green și canary cu praguri automate pe metrici.

• Cum fac rollback la versiunea anterioară într-o singură comandă?

  Păstrăm imaginile și manifestele versiunilor precedente, iar comutarea traficului este o schimbare de rută, nu o reconstrucție. Comanda o exersăm împreună la livrare și o trecem în procedură, inclusiv ce se face dacă între timp s-a rulat o migrare de schemă.

• Cum migrez baza de date fără să opresc aplicația?

  În două etape. Întâi extinzi schema cu elemente pe care le înțeleg ambele versiuni, lansezi codul, confirmi stabilitatea, apoi restrângi și elimini ce nu mai e folosit. Regula fixă: nicio migrare care rupe compatibilitatea nu pleacă odată cu codul.

• Am nevoie de resurse duble pentru două medii?

  Doar temporar, în timpul lansării. Pe Kubernetes mediul suplimentar există câteva minute și dispare după comutare. Pe arhitecturi mai simple ținem o rezervă de capacitate calculată împreună, ca să nu plătești constant pentru un mediu folosit rar.