Rollback după un deploy din GitHub: ce revine și ce nu
Cum pregătești un rollback sigur după un deployment: cod, configurare, baze de date și verificările care trebuie separate.
Rollback-ul codului nu înseamnă automat rollback-ul sistemului
O versiune anterioară a aplicației poate fi repusă în funcțiune, dar baza de date, fișierele persistente și serviciile externe pot fi deja într-o stare nouă. De aceea rollback-ul trebuie planificat împreună cu modificările pe care deployment-ul le produce în afara imaginii aplicației.
Înainte de deploy, definește punctul de revenire
Notează commitul sau versiunea cunoscută ca stabilă și păstrează configurația necesară acelei versiuni. Dacă deployment-ul schimbă variabile de mediu, schema bazei de date sau integrarea cu un serviciu extern, documentează și acele schimbări.
Fără un punct clar de revenire, „rollback” poate însemna doar alegerea unei versiuni mai vechi fără să știi dacă aceasta mai este compatibilă.
Migrațiile de bază de date sunt partea cea mai sensibilă
O migrare poate adăuga, elimina sau transforma date. Revenirea la codul anterior nu inversează automat acele modificări.
Înainte de schimbări destructive, stabilește dacă migrarea este compatibilă cu versiunea veche și ce procedură de restaurare există. Pentru aplicații cu date importante, backup-ul și rollback-ul trebuie tratate ca procese separate.
Configurarea trebuie să fie compatibilă cu versiunea restaurată
O versiune mai veche poate aștepta alte nume de variabile sau alte valori. Verifică configurația de runtime înainte să pornești rollback-ul.
Pentru organizarea acestor valori, vezi Variabile de mediu în Node.js.
Verifică fluxurile importante după revenire
După rollback, nu te opri la faptul că pagina principală răspunde. Testează:
- healthcheck-ul aplicației;
- autentificarea;
- citirea și scrierea datelor;
- joburile de fundal;
- webhooks și integrările externe;
- fluxul comercial esențial al aplicației.
Când rollback-ul nu este cea mai bună intervenție
Dacă problema este o variabilă configurată greșit sau un serviciu extern indisponibil, revenirea codului poate să nu rezolve cauza. Folosește logurile și diferența dintre versiuni pentru a identifica problema înainte de a schimba mai multe componente simultan.
Checklist de rollback
- versiune stabilă identificată;
- configurare compatibilă păstrată;
- impactul migrărilor înțeles;
- backup/restaurare separate de rollback-ul codului;
- teste funcționale definite;
- persoană responsabilă pentru decizie;
- incidentul documentat după stabilizare.
Pentru fluxul de publicare, vezi De la repository la producție și Cloud Apps.
Tratează rollback-ul ca pe o procedură, nu ca pe un buton magic
Revino la codul cunoscut ca stabil, dar verifică separat datele și schimbările de infrastructură.