Ce este blue-green deployment?

Este o tehnică de lansare cu două medii identice. Unul servește traficul, celălalt primește versiunea nouă și este verificat în liniște. Comutarea traficului se face la balansator sau la ingress, deci utilizatorii nu văd nicio întrerupere, iar revenirea la versiunea anterioară se face mutând comutatorul înapoi.

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

Blue-green este mai simplu și potrivit când vrei o trecere clară, cu revenire rapidă. Canary este mai bun când schimbarea e riscantă și vrei dovezi din trafic real înainte să o dai tuturor. În practică le combinăm: mediu nou complet, dar trafic mutat pe procente crescătoare.

Cum fac deploy fără downtime pe Kubernetes?

Rolling update acoperă cazurile obișnuite: pod-urile noi pornesc, trec probele de readiness și abia apoi se opresc cele vechi. Pentru schimbări mai riscante folosim Argo Rollouts sau Flagger, care gestionează canary cu porți pe metrici și revenire automată la depășirea pragurilor stabilite.

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

Prin tiparul expand și contract. Mai întâi adaugi coloanele sau tabelele noi, compatibile cu versiunea care rulează. Apoi livrezi codul care scrie și citește din structura nouă. Curățarea coloanelor vechi vine la o lansare ulterioară, când nicio versiune activă nu mai depinde de ele.

Cât durează un rollback?

Dacă mediul anterior a rămas pornit, revenirea este o comutare de trafic, adică secunde. Ce lungește rollback-ul sunt migrările incompatibile de bază de date, exact motivul pentru care nu le acceptăm împreună cu codul. Exersăm revenirea înainte de prima lansare reală, ca procedura să fie verificată.

Am nevoie de Kubernetes pentru blue-green?

Nu. Se poate face și cu două grupuri de containere în spatele unui balansator, sau cu două directoare de aplicație și o schimbare de legătură simbolică, plus reîncărcarea serverului web. Kubernetes doar simplifică automatizarea când ai multe servicii și lansări frecvente.

Blue-Green Deployment fără downtime în Moldova

Servicii DevOps · Lansări · Moldova

Comutare la ingress, fără fereastră de mentenanță

Blue-green deployment și canary pentru echipele din Moldova care încă anunță clienții că site-ul va fi indisponibil două ore. Ridicăm două medii identice, mutăm traficul la ingress și păstrăm versiunea veche pornită până când metricile confirmă că cea nouă e bună. Rollback-ul rămâne o singură comandă, iar munca intră în orele incluse.

Canary pe procente, cu porți pe metrici
Rollback instant, într-o singură comandă

Cere lansări fără downtime Vezi planurile și orele incluse

VPS 1–8 h · dedicate 5–10 h (în funcție de plan), GPU 10 h
Ore incluse lunar
Frankfurt (UE)
Datacentere
latență redusă din Frankfurt
Latență din Moldova
română și rusă
Suport

Două medii identice și un comutator

Mediul albastru servește traficul, iar cel verde primește versiunea nouă și rulează testele de fum. Când totul e în ordine, comutăm traficul la nivel de ingress sau de balansator, într-o operațiune de câteva secunde. Sesiunile deschise se scurg controlat, nu se taie brusc. Mediul vechi rămâne pornit și pregătit, deci dacă apare o problemă în primele minute revenim instantaneu, fără să reconstruim nimic. Diferența față de o repornire simplă este că nu ai nicio fereastră în care aplicația lipsește.

Comutare la ingress sau balansator, în câteva secunde
Scurgere controlată a sesiunilor deschise, fără tăieri bruște
Mediul vechi păstrat pornit pentru revenire imediată

Canary: cinci la sută, apoi douăzeci și cinci, apoi tot

Când schimbarea e riscantă, nu comutăm tot traficul deodată. Trimitem întâi o felie mică spre versiunea nouă și urmărim automat rata de erori, latența și indicatorii de business, de exemplu comenzile finalizate. Dacă un prag este depășit, promovarea se oprește singură și traficul revine. Dacă totul e verde, felia crește treptat până la sută la sută. Steagurile de funcționalitate completează imaginea: poți livra codul stins și aprinde funcția separat, pentru un grup restrâns de utilizatori.

Porți automate pe rata de erori, latență și indicatori de business
Oprire și revenire automată la depășirea unui prag
Steaguri de funcționalitate, ca livrarea să nu însemne activare

Bune practici pe care le aplicăm la fiecare lansare

Cele mai multe lansări eșuate nu cad din cauza codului, ci din cauza bazei de date. O migrare care șterge o coloană odată cu versiunea nouă face rollback-ul imposibil, oricât de elegant e comutatorul. De aceea impunem tiparul expand și contract: mai întâi adăugăm, apoi livrăm codul care folosește noul, și abia la o lansare ulterioară curățăm vechiul. Restul practicilor de mai jos se aplică la fiecare intervenție din orele incluse, indiferent cât de mică pare schimbarea.

Migrări expand și contract, niciodată schemă incompatibilă odată cu codul
Teste de fum automate rulate pe mediul nou înainte de comutare
Rollback dintr-o singură comandă, exersat înainte de prima lansare reală
Mediul anterior rămâne pornit până când metricile sunt verzi
Fereastră de lansare aliniată la orele de lucru din Moldova, nu la miezul nopții

Ce cere planul tău și ce intră în orele incluse

Blue-green cere resurse pentru două medii în paralel, deci un VPS mai generos sau un server dedicat; nu se poate face pe cPanel. Configurarea inițială, scrierea testelor de fum și exersarea rollback-ului intră de regulă în cota lunară a unui plan mediu. Cererile se deschid din panoul de client, la secțiunea Servicii DevOps, cu termenul propus de tine. Orele nu se reportează în luna următoare, iar ce depășește cota se acceptă și se facturează separat, la oră.

Orele de DevOps, CyberSecurity și Programare sunt incluse în abonament, lună de lună: 1 h de la planul cPanel Advanced în sus, 1–8 h pe VPS și 5–10 h pe serverele dedicate, în funcție de plan, și 10 h pe GPU. Le ceri din panoul de client și propui termenul; cota expiră la sfârșitul lunii calendaristice, iar lucrul de peste cotă se acceptă și se facturează separat, în euro, cu TVA 20 % și factură SFS. Cu abonamentele care includ minimum 2 ore lunare îți construim un site de prezentare, iar cu cele care includ minimum 5 ore, un magazin online — din orele deja plătite în abonament.

Cazuri de utilizare

Comerț online în campanie

În preajma sărbătorilor și a campaniilor de reduceri nu poți opri magazinul nici cinci minute. Versiunea nouă se validează pe mediul verde, apoi traficul se mută la ingress, cu revenire imediată dacă rata de eroare crește.

Procesator de plăți din Chișinău

Orice lansare atinge fluxuri care mișcă bani, deci pornim cu o felie de cinci la sută și porți pe tranzacțiile finalizate. Schema bazei de date se schimbă doar prin adăugări compatibile, ca revenirea să rămână posibilă.

Platformă de rezervări turistice

Sezonul concentrează cererile în câteva luni, iar o eroare la disponibilitate costă rezervări. Steagurile de funcționalitate permit testarea unei schimbări pe agențiile partenere înainte de a o deschide tuturor.

Cum lucrăm

Ne descrii lansările actuale
Din panou, la Servicii DevOps, ne spui cum livrezi acum, cât durează indisponibilitatea, ce migrări de bază de date faci și ce termen ai.
Proiectăm strategia și porțile
Alegem între blue-green și canary, stabilim procentele, pragurile de metrici la care promovarea se oprește și cine aprobă trecerea la sută la sută.
Implementăm și exersăm rollback
Construim al doilea mediu, scriem testele de fum, legăm porțile pe metrici și facem un exercițiu de revenire înainte de prima lansare reală.
Predăm cu procedura scrisă
Primești procedura de lansare și de rollback, definițiile porților, testele de fum în repo și o sesiune de predare în română sau rusă.

Tehnologii

Kubernetes
Argo Rollouts
Traefik
HAProxy
Flagger
Prometheus
Alembic
Playwright

Întrebări frecvente

Ce este blue-green deployment?
Este o tehnică de lansare cu două medii identice. Unul servește traficul, celălalt primește versiunea nouă și este verificat în liniște. Comutarea traficului se face la balansator sau la ingress, deci utilizatorii nu văd nicio întrerupere, iar revenirea la versiunea anterioară se face mutând comutatorul înapoi.
Blue-green sau canary: care strategie e potrivită?
Blue-green este mai simplu și potrivit când vrei o trecere clară, cu revenire rapidă. Canary este mai bun când schimbarea e riscantă și vrei dovezi din trafic real înainte să o dai tuturor. În practică le combinăm: mediu nou complet, dar trafic mutat pe procente crescătoare.
Cum fac deploy fără downtime pe Kubernetes?
Rolling update acoperă cazurile obișnuite: pod-urile noi pornesc, trec probele de readiness și abia apoi se opresc cele vechi. Pentru schimbări mai riscante folosim Argo Rollouts sau Flagger, care gestionează canary cu porți pe metrici și revenire automată la depășirea pragurilor stabilite.
Cum migrez baza de date fără să opresc aplicația?
Prin tiparul expand și contract. Mai întâi adaugi coloanele sau tabelele noi, compatibile cu versiunea care rulează. Apoi livrezi codul care scrie și citește din structura nouă. Curățarea coloanelor vechi vine la o lansare ulterioară, când nicio versiune activă nu mai depinde de ele.
Cât durează un rollback?
Dacă mediul anterior a rămas pornit, revenirea este o comutare de trafic, adică secunde. Ce lungește rollback-ul sunt migrările incompatibile de bază de date, exact motivul pentru care nu le acceptăm împreună cu codul. Exersăm revenirea înainte de prima lansare reală, ca procedura să fie verificată.
Am nevoie de Kubernetes pentru blue-green?
Nu. Se poate face și cu două grupuri de containere în spatele unui balansator, sau cu două directoare de aplicație și o schimbare de legătură simbolică, plus reîncărcarea serverului web. Kubernetes doar simplifică automatizarea când ai multe servicii și lansări frecvente.

Scoatem fereastra de mentenanță din calendar

Spune-ne cum livrezi acum și ce migrări de bază de date faci. Îți propunem strategia de lansare, porțile pe metrici și procedura de revenire.