Hoe ik werk, aan de hand van één echt project

Vóór de upgrade: in de lucht houden terwijl anderen offline gingen

Vlak voor de upgrade werd een kritiek PHP-lek bekend dat servers met oude PHP-versies raakte, en voor PHP 7.4 was er op dat moment geen oplossing. Een veelvoorkomende reactie was om de getroffen sites offline te halen tot ze gepatcht konden worden.

Voor dit bedrijf betekent offline: geen orders, geen routes en geen leveringen. Dus heb ik de klant gebeld voordat ze het ergens anders hoorden, en een tijdelijk slot voor het systeem gezet: medewerkers logden in met één extra wachtwoord, en alleen het netwerk van het webshopplatform kon nog orders afleveren. Het bedrijf werkte gewoon door en er is geen order verloren gegaan.

Dat gaf de tijd om het echte probleem goed op te lossen: de upgrade hieronder. Het slot is verwijderd toen de nieuwe versie live stond.

Een vangnet voordat ik de code aanraak

De eerste tests zijn geschreven en gedraaid op de oude versie, om vast te leggen hoe het systeem zich werkelijk gedroeg: de order-webhook, de beheerschermen, PDF's, Excel-exports, voorraad en reserveringen. Met elke stap kwamen er tests bij.

• Een aparte testdatabase met de structuur van productie, maar met fictieve orders en klanten
• De order-webhook veld voor veld getest, inclusief dubbele en mislukte aanroepen
• Complete bedrijfsprocessen: webhook-order → voorraadreservering → koerier → route → afgeleverd
• Rechten per rol, elke geplande taak, elke export

Upgraden in stappen, niet in één sprong

CakePHP 3.6 → 4.6 → 5.4, en PHP 7.4 → 8.4 → 8.5. Elke stap ging pas door als dezelfde tests nog slaagden.

• Elke library bijgewerkt; verlaten libraries vervangen door ondersteunde, of door een klein stuk eigen code
• Inloggen opnieuw gebouwd op de nieuwe authenticatie-library, waarbij bestaande wachtwoorden geldig bleven
• 144 schermtemplates, 13 geplande commando's en 5 eigen plugins overgezet
• 223 validatieregels met de hand herschreven
• Statische analyse (PHPStan) en codestijlcontroles zonder meldingen
• De frontend bewust ongemoeid gelaten, zodat elk scherm er hetzelfde uitziet en hetzelfde werkt

Bewijzen dat er niets veranderd is

Op staging, met een verse kopie van de productiedata, zijn oud en nieuw naast elkaar gelegd:

• PDF's van orders, offertes, routes en labels: identieke tekst
• Een echte webshoporder geïmporteerd: 56 velden identiek
• De prijssynchronisatie met de leverancier: 618 producten identiek
• De voorraadtellers van alle 1.535 producten, en de totalen van dashboard en statistieken
• Alle 189 menupagina's geopend, alle 31 opgeslagen filters nageteld tegen de database
• Met elke rol ingelogd en elke menulink aangeklikt, plus een testdag door de klant

Live in de nacht, met een weg terug

Staging ging eerst. Productie is op een maandag om 23:34 overgezet volgens een uitgeschreven draaiboek, met een volledige kopie van de database van vijf minuten ervoor en de oude versie klaar om terug te zetten. Gebruikers hoefden de volgende ochtend alleen één keer opnieuw in te loggen.

Drie dagen later ging de server midden op een werkdag van PHP 8.4 naar PHP 8.5. Het kantoor bleef ondertussen orders opslaan.

Blijven meekijken, en oplossen voordat iemand het merkt

Bij de livegang houdt het voor mij niet op. In de eerste week las ik elke 30 minuten de logs: wie er werkte, of iemand een fout kreeg, of orders en nachtelijke taken goed doorkwamen.

Zo kwamen drie problemen boven. Elk is dezelfde dag opgelost, afgedekt met een nieuwe test, uitgeprobeerd op staging en live gezet, voordat een gebruiker ertegenaan liep. Eén ervan was een waarschuwing in een logbestand die niemand ooit op het scherm had gezien. De klant hoorde het van mij, in het rapport, als iets dat al was opgelost.

Na die week neemt monitoring het over: het systeem mailt me als een koppeling uitvalt en opnieuw als die weer werkt.