Când un upgrade nu mai e de rutină
Un upgrade e de rutină când ești cu o versiune minoră în urmă. Nu mai e de rutină când produsul e cu câteva versiuni majore în urmă, versiunea de PHP nu mai are suport, câteva bundle-uri au fost abandonate de autori, logul de deprecieri are mii de linii și nimeni nu vrea să fie cel care face deploy la upgrade. În situația asta suntem chemați de obicei.
Cum lucrăm
- Măsurăm întâi distanța: versiunile de Symfony și PHP, deprecierile, dependențele și bundle-urile fără o versiune întreținută. Afli numărul de pași și ce blochează fiecare pas înainte să se schimbe vreo linie de cod.
- Punem teste în jurul comportamentului actual, pe modulele care se schimbă primele. Generate cu ajutorul AI, verificate de un om, păstrate în CI.
- Rezolvăm deprecierile cât suntem încă pe versiunea curentă, modul cu modul, și livrăm fiecare bucată. Aici se face cea mai mare parte din munca unui upgrade, în modificări mici pe care echipa voastră le poate revizui.
- Trecem câte o versiune majoră pe rând, în producție, nu cinci deodată. Fiecare pas e un release obișnuit, nu un eveniment.
- Înlocuim bundle-urile abandonate unul câte unul, în spatele aceleiași interfețe, ca restul codului să nu observe.
- Păstrăm după aceea analiza statică și pragurile de acoperire în CI, ca baza de cod să rămână la zi în loc să alunece înapoi.
Un detaliu onest: versiunea de framework e comună pentru toată aplicația, deci comutarea finală se face pentru tot deodată. Ce merge modul cu modul este pregătirea, iar pregătirea este locul unde stă riscul. Făcută așa, comutarea în sine e un release mic.
Comutare și rollback
Comutarea finală se livrează ca orice alt release, cu drumul înapoi stabilit înainte, nu decis în timpul ei. Modificările de bază de date rămân compatibile cu versiunea anterioară până când codul vechi dispare, astfel încât build-ul anterior să poată fi redeployat pe aceleași date. Ce declanșează un rollback, cine îl decide și cât timp rămâne deployabilă versiunea veche sunt scrise în plan. La migrarea de pe Zend Framework, drumul înapoi a fost chiar sistemul shadow: codul vechi a rulat în continuare până când cel nou a produs output identic, iar clienții au fost mutați în grupuri, cu sistemul vechi încă în funcțiune în spatele lor.
Plecarea de pe alt framework
Aceeași abordare funcționează și când părăsești complet un framework mai vechi. Am mutat o platformă SaaS enterprise de pe Zend Framework și de pe o versiune veche de Node.js pe Symfony 7 în 3 luni: codul nou a rulat ca sistem shadow lângă cel vechi, pe același input, outputurile au fost comparate până au devenit identice, apoi clienții au fost mutați treptat. Zero incidente în producție cauzate de o comutare și sub 15 buguri după aceea, toate minore.
Cum se stabilește scopul
Un audit tehnic de două săptămâni produce planul de upgrade: pași, blocaje, ordine și efort. Un pilot de livrare asistată de AI, de 4-6 săptămâni, duce primul modul până în producție, ca să dovedească planul. Un retainer lunar duce restul, modul cu modul. Scopul și prețul vin în scris după o discuție de 20 de minute, iar planul din audit îl poți executa și cu echipa ta.