Een Symfony-upgrade die geen weekend kost

Waar upgrades echt op stuklopen

Een Symfony-upgrade die uit de hand loopt, loopt zelden stuk op Symfony. Hij loopt stuk omdat niemand kon vaststellen of de applicatie ná de upgrade nog hetzelfde deed als ervoor. Zonder die vaststelling wordt een upgrade een reeks aannames, en aannames komen bij oplevering allemaal tegelijk terug.

Daarom heeft de eerste stap van onze aanpak niets met Symfony te maken.

Stap één: zorg dat u het verschil kunt zien

Voordat er één versienummer omhoog gaat, kijken we of er genoeg geautomatiseerde tests zijn om de belangrijkste bedrijfsprocessen af te dekken. Is dat niet zo, dan schrijven we die eerst — juist op de plekken waar geld doorheen loopt: bestellen, betalen, factureren, inloggen.

Dat voelt als uitstel en is het tegenovergestelde. Deze tests zijn het enige gereedschap waarmee u na afloop kunt vaststellen dat er niets stiekem is veranderd. Ze blijven bovendien bestaan na de upgrade, en verlagen de kosten van elke volgende wijziging.

Stap twee: eerst binnen de hoofdversie

Symfony waarschuwt binnen een hoofdversie voor alles wat in de volgende gaat verdwijnen. Die waarschuwingen zijn de landkaart. We werken daarom eerst de laatste kleine versies bij, verzamelen alle waarschuwingen, en lossen die op terwijl de applicatie gewoon draait. Pas als die lijst leeg is, gaat de hoofdversie omhoog.

Wie die volgorde omdraait — meteen naar de nieuwe hoofdversie — verruilt een lijst met concrete waarschuwingen voor een applicatie die niet meer start, zonder aanwijzing waar te beginnen.

Stap drie: in stukken uitrollen, niet in één nacht

Een upgrade hoeft geen weekendoperatie te zijn. Wanneer het werk in kleine, afzonderlijk uitrolbare stappen zit, gaat elke stap naar productie zodra hij klaar is. Gaat er iets mis, dan weet u meteen welke stap het was.

Dat vraagt wel iets van de omgeving eromheen: een uitrolproces dat herhaalbaar is en een testsuite die bij elke stap draait. Bij Newcraft zat dat deel van het werk expliciet in de opdracht — we hebben daar het Symfony-platform en de onderliggende infrastructuur bijgewerkt en tegelijk een nieuwe CI-pipeline opgezet, zodat ontwikkelen en uitrollen daarna soepel liepen. De pipeline was geen bijproduct; hij was de voorwaarde.

De drie fouten die we het vaakst tegenkomen

• Kleine versies overslaan. Daarmee slaat u ook de waarschuwingen over die u de weg zouden wijzen.
• Waarschuwingen wegdrukken. Een genegeerde melding is uitgesteld werk met rente.
• Upgraden en verbouwen tegelijk. Gaat er iets stuk, dan weet niemand of het door de upgrade kwam of door de nieuwe functionaliteit. Doe één ding per keer.

Wanneer upgraden niet het antwoord is

Soms is de eerlijke uitkomst dat de upgrade het probleem niet oplost. Zit de applicatie zo in elkaar dat elke wijziging tien plekken raakt, dan houdt u na de upgrade dezelfde applicatie — alleen op een nieuwere versie. De winst zit dan niet in het versienummer maar in het losmaken van die verstrengeling, en dat is een ander gesprek.

Ook eerlijk: bij een verwaarloosde codebase is vooraf niet exact te zeggen wat een upgrade kost. Wat wel kan, is eerst een afgebakende inventarisatie doen en op basis daarvan beslissen. Dat is aanzienlijk goedkoper dan een vaste prijs op een aanname.