De PHP-versie van een bestaande applicatie upgraden houdt meer in dan alleen de containerimage of serverconfiguratie wijzigen. De runtime werkt samen met de code, extensies, Composer-bibliotheken en processen die geplande taken of achtergrondtaken uitvoeren. Een wijziging kan elk van die onderdelen beïnvloeden, zelfs als de applicatie tijdens een handmatige test normaal lijkt te werken.
Onzekerheid beperk je door de upgrade te behandelen als een compatibiliteitswijziging: inventariseer wat er wordt uitgevoerd, zoek naar incompatibiliteiten, valideer representatieve routes en bepaal vooraf hoe je beslist of de uitrol doorgaat of wordt teruggedraaid. Het doel is het werk dat nodig is voor de nieuwe runtime af te bakenen, niet de upgrade om te vormen tot een herschrijving van het product.
De runtime maakt deel uit van de compatibiliteit van de applicatie
Een PHP-versie bepaalt welke syntaxis de interpreter ondersteunt en hoe bepaalde functies en typen zich gedragen. Ook bepaalt die welke versies van extensies en afhankelijkheden kunnen worden geïnstalleerd. Dat de code in de huidige omgeving heeft gewerkt, bewijst daarom niet dat die in de nieuwe omgeving zal werken: een functie, interface, typegedrag of de beschikbaarheid van een extensie kan veranderen.
Maak onderscheid tussen drie gebieden: de applicatiecode, afhankelijkheden van derden en de omgevingsconfiguratie. Als je alle drie tegelijk wijzigt, is een fout moeilijker te herleiden. Een geplande upgrade houdt die wijzigingen waar mogelijk gescheiden en maakt expliciet welk onderdeel elke aanpassing heeft geïntroduceerd.
Inventariseer de runtime, afhankelijkheden en processen
Leg voordat je iets wijzigt de daadwerkelijke runtimeomgeving vast, niet alleen de omgeving die in het configuratiebestand van het project wordt beschreven. Controleer de PHP-versie in de containers of servers die verzoeken verwerken en in de omgevingen die geplande taken, queue-consumers en onderhoudscommando's uitvoeren. Die processen kunnen andere images, variabelen of extensies gebruiken.
- Runtime en extensies: breng de ingeschakelde extensies in kaart, waar relevant hun versies en de systeembibliotheken waarvan ze afhankelijk zijn. Vergelijk de vereisten voor productie, CI en ontwikkeling.
- Composer-afhankelijkheden: controleer
composer.json, het lockbestand en de PHP-versiebeperkingen die pakketten declareren. Controleer ook ontwikkeltools, zoals analysers en testrunners. - Configuratie: inventariseer waarden in
php.ini, geheugen- en tijdslimieten, foutconfiguratie en serverspecifieke instellingen. Een nieuwe runtime garandeert niet dat relevante parameters behouden zijn gebleven. - Werk buiten webverzoeken: neem cron, queues, consolecommando's, imports, exports en langlopende taken mee. Een werkende webroute valideert die processen niet automatisch.
- Integraties en gegevens: noteer externe services, uitgewisselde formaten en schrijfbewerkingen naar databases of opslag. Zo kun je bepalen welke bewerkingen tijdens een terugdraaiing extra aandacht vereisen.
De inventaris kan een lijst zijn die in de repository of operationele documentatie wordt bijgehouden, zolang je er omgevingen mee kunt vergelijken en afwijkingen kunt opsporen. Een veelvoorkomend symptoom van een onvolledige inventaris is dat CI slaagt, maar een worker of geplande taak na de uitrol uitvalt.
Spoor incompatibiliteiten op met meerdere signalen
Begin met geautomatiseerde tools: controleer de platformvereisten van Composer en voer een afhankelijkheidscontrole uit met de beoogde PHP-versie. Een conflict bij het oplossen van afhankelijkheden betekent dat een pakket, waaronder ontwikkeltools, geen compatibiliteit met dat platform declareert. Forceer de installatie niet om het conflict te verbergen zonder te begrijpen welke vereiste je omzeilt.
Vul die analyse aan met statische analysetools en de stijl- of compatibiliteitstests die in het project beschikbaar zijn. Die kunnen verdachte toepassingen, verouderde API's of patronen signaleren die nader onderzoek verdienen, maar bewijzen op zichzelf niet dat de volledige applicatie werkt. Een analyse zonder bevindingen vervangt evenmin een daadwerkelijke uitvoering: sommige fouten treden alleen op bij het doorlopen van een weinig gebruikte codebranch of bij het laden van een extensie.
Voer de tests uit met de beoogde runtime en de extensies die naar verwachting in productie worden gebruikt. Is de testsuite beperkt, voeg dan handmatige of geautomatiseerde controles toe voor de meest impactvolle flows: authenticatie, schrijfbewerkingen, betalingen indien van toepassing, documentgeneratie en essentiële integraties. Leg ook fouten en waarschuwingen vast; een wijziging waardoor een waarschuwing een exception wordt, kan een route onderbreken voordat de testsuite dat detecteert.
Orden het werk om risico's af te bakenen
Een praktische volgorde is eerst de kandidaat-image of -configuratie en de extensies te bevestigen, vervolgens de afhankelijkheidsbeperkingen op te lossen en ten slotte de code en instellingen aan te passen die het uitvoeren van de tests verhinderen. Houd elke groep wijzigingen goed te beoordelen. Als een bibliotheek moet worden bijgewerkt, documenteer dan welke vereiste die wijziging noodzakelijk maakt en test de toepassingsgebieden ervan.
Werk niet zonder onderscheid alle afhankelijkheden bij als onderdeel van dezelfde stap. Een brede upgrade kan nodig zijn, maar vergroot het aantal mogelijke oorzaken als er een regressie optreedt. Als wijzigingen niet kunnen worden gescheiden, leg dan vast welke pakketten zijn gewijzigd en voeg tests toe die zijn gericht op de functionaliteit die daarvan afhankelijk is. Zorg er ook voor dat het lockbestand consistent wordt gegenereerd en geïnstalleerd in CI en productie.
De configuratie moet overeenkomen met de uiteindelijke omgeving. Valideren met een extensie die alleen in CI is geïnstalleerd, levert een misleidend signaal op; hetzelfde geldt als achtergrondtaken nog met de oude runtime worden uitgevoerd. Vergelijk images, startcommando's, variabelen en configuratie tussen de test- en productieomgeving voordat je een resultaat aan de code toeschrijft.
Valideer in een representatieve omgeving en bepaal de stopcriteria
CI moet de installatie, analyse en tests uitvoeren met de beoogde runtime, niet alleen met de huidige. Voeg alleen aparte jobs voor andere runtimes toe als de applicatie een compatibiliteitsvenster moet behouden: in dat geval moet elke ondersteunde combinatie expliciet worden gecontroleerd. Een CI-matrix kan laten zien welke combinaties worden getest, maar dekt niet automatisch de bijzonderheden van productie.
Gebruik een stagingomgeving die voldoende op de productieomgeving lijkt om het opstarten, kritieke routes, integraties, queues en geplande taken te controleren. Bekijk vóór en na de wijziging logs, fouten, responstijden en resourceverbruik. Bepaal vooraf welk gedrag de uitrol zou stoppen, wie die beslissing neemt en hoelang het systeem wordt gemonitord. Drempelwaarden moeten zijn gebaseerd op de behoeften en beschikbare signalen van de applicatie, niet op generieke waarden.
Een bruikbaar stopcriterium omvat: reproduceerbare installatie, de afgesproken testsuite die slaagt, geverifieerde kritieke flows, geen onverklaarde nieuwe fouten en de mogelijkheid om achtergrondprocessen uit te voeren. Leg bekende uitzonderingen en de verantwoordelijke ervoor vast. “De tests slagen” is onvoldoende als de testset een essentiële integratie niet dekt of als het team niet weet welke metriek het moet bewaken.
Rol uit met een terugdraaiing die compatibel is met de gegevens
Als de architectuur en het platform het toelaten, stel de nieuwe runtime dan geleidelijk beschikbaar: eerst in een gecontroleerde omgeving en vervolgens aan een deel van het verkeer of de uitvoeringscapaciteit. Geleidelijke blootstelling is een uitrolstrategie, geen openbaarmaking van informatie. Verkeer kan niet altijd over versies worden verdeeld — bijvoorbeeld bij stateful processen of verschillen in het interne protocol —; plan in dat geval een gecoördineerde overgang en controleer de consumers en producers van berichten expliciet.
Controleer vóór de uitrol of de vorige code bij een storing opnieuw kan worden uitgevoerd. Terugdraaien betekent niet alleen een image herstellen: een databasemigratie, een nieuw berichtformaat of een incompatibele schrijfbewerking kan verhinderen dat de vorige runtime gegevens leest die door de nieuwe runtime zijn aangemaakt. Geef de voorkeur aan stapsgewijze, schema-compatibele wijzigingen: breid eerst uit, rol code uit die met beide vormen overweg kan en verwijder het oude pas wanneer geen consumers het meer nodig hebben. Bepaal voor elke onomkeerbare stap een specifieke herstelprocedure en een stopbeslissing.
Houd tijdens de uitrol applicatie- en runtimefouten, workerstoringen, queue-achterstand, geplande taken en relevante bedrijfssignalen in de gaten. Als een terugdraaicriterium wordt bereikt, stop dan met het verder uitbreiden van de wijziging en volg de beproefde procedure. Bewaar de logs die nodig zijn om de oorzaak vast te stellen; terugdraaien zonder diagnose kan ertoe leiden dat dezelfde fout bij de volgende poging opnieuw optreedt.
Checklist om te bepalen of de upgrade klaar is
- Zijn de runtime en extensies voor alle omgevingen en processen geïdentificeerd?
- Zijn de Composer-beperkingen en ontwikkeltools gecontroleerd?
- Worden analyses en tests uitgevoerd met de beoogde configuratie?
- Zijn kritieke routes, integraties, queues en geplande taken getest?
- Zijn de verschillen tussen CI, staging en productie bekend?
- Zijn er operationele signalen, verantwoordelijken en duidelijke criteria om door te gaan of te stoppen?
- Kan de vorige code werken met de gegevens en berichten die de nieuwe runtime zal produceren?
- Is de terugdraaiing geoefend en is bekend welke wijzigingen niet automatisch ongedaan kunnen worden gemaakt?
De beslissing om de PHP-versie van een bestaande applicatie te upgraden is beter onderbouwd wanneer het team deze vragen met bewijs kan beantwoorden. Ontbreken tests of een inventaris, dan hoeft de volgende stap geen herschrijving te zijn: je kunt eerst die hiaten dichten en de omvang van de wijziging beperken. Zo worden potentiële fouten ontdekt voordat ze gebruikers raken en heeft elke uitrolbeslissing een verifieerbaar criterium.
