PHP 8.4 in produzione: checklist prima dell'upgrade

Portare PHP 8.4 in produzione non è un semplice aggiornamento di sistema. È una modifica che tocca compatibilità, runtime, estensioni, pipeline di deploy e monitoraggio post-rilascio.

Se gestisci più ambienti, la domanda giusta non è "funziona su staging?" ma "abbiamo verificato tutto quello che può rompersi in produzione?".

Questa checklist serve proprio a evitare upgrade frettolosi, rollback improvvisati e incidenti che si potevano prevenire con un po' di disciplina operativa.

Se vuoi far validare l'upgrade da qualcuno che gestisce server ogni giorno, puoi partire da un audit gratuito oppure dal servizio Gestione Server Quotidiana White-Label.

TL;DR

Prima di portare PHP 8.4 live, verifica almeno questi punti:

1. inventario reale di versioni, estensioni e dipendenze
2. compatibilità del codice e dei pacchetti Composer
3. test in staging con lo stesso stack della produzione
4. piano di rollback già pronto
5. monitoraggio serrato nelle prime ore dopo il deploy

Se uno di questi punti manca, non stai facendo un upgrade: stai facendo un azzardo.

1. Fai l'inventario reale dello stack

La prima causa di problemi è non sapere davvero cosa gira sul server.

Controlla:

• versione CLI di PHP
• versione FPM effettiva
• estensioni caricate
• pacchetti Composer e vincoli di piattaforma
• cron, worker, code queue e script legacy

php -v
php -m
composer show --platform
composer check-platform-reqs

Se hai pool separati per siti o clienti, l'inventario va fatto per ogni pool. Non dare per scontato che tutti usino la stessa configurazione.

2. Leggi le fonti ufficiali, non i riassunti casuali

Per PHP 8.4 la lettura minima è questa:

• la release announcement di PHP 8.4
• la migration guide ufficiale
• la pagina dei supported versions

Quello che ti interessa non è solo la novità funzionale, ma soprattutto:

• deprecazioni
• cambiamenti di comportamento
• estensioni o funzioni che il tuo codice usa ancora in modo fragile
• eventuali vincoli di compatibilità con librerie di terze parti

3. Clona in staging l'ambiente vero, non una copia approssimativa

Uno staging utile deve somigliare il più possibile alla produzione.

Se cambia anche solo una delle seguenti cose, il test perde valore:

• versione di PHP-FPM
• configurazione di opcache
• estensioni installate
• path dei binari
• permissions e owner dei file
• configurazione di Nginx o Apache

Esegui almeno questi controlli:

• php -l sui file toccati dal deploy
• suite di test applicativi, se esiste
• smoke test delle URL critiche
• login, checkout, form e dashboard principali
• job asincroni e cron

find app -name '*.php' -o -name '*.inc' | xargs -r -n 1 php -l
vendor/bin/phpunit

Se la tua applicazione non ha test automatici, il minimo sindacale è una checklist manuale ripetibile.

4. Verifica estensioni e dipendenze

Molti problemi non arrivano dal core PHP, ma da estensioni o librerie native.

Controlla in particolare:

• intl
• mbstring
• gd
• imagick
• soap
• redis
• opcache

Se usi moduli PECL o estensioni compilate a mano, non aspettare il giorno del deploy per scoprirlo.

In staging devi validare anche:

• build di eventuali container
• pacchetti di sistema richiesti
• script di deploy che richiamano PHP da path assoluti

5. Prepara il rollback prima di fare il deploy

Un rollback vero non si improvvisa.

Devi avere già pronti:

• snapshot o backup verificato
• configurazione precedente salvata
• tempi di ritorno al vecchio runtime
• persona responsabile del go/no-go
• finestra di manutenzione con margine

Tabella operativa

| Controllo | Cosa verificare | Perché conta | |---|---|---| | Backup | Restore testato, non solo esistente | Senza restore verificato non hai un backup utile | | Config | Vecchia versione di PHP salvata | Riduce il tempo di rollback | | Traffic | Picco orario e finestre di carico | Evita di cambiare runtime nel momento peggiore | | Deployment | Script ripetibile e documentato | Evita errori umani nel passaggio critico | | Communication | Chi avvisa il cliente e quando | Riduce confusione se qualcosa degrada |

6. Dopo il deploy, guarda i segnali giusti

Le prime ore sono quelle decisive.

Monitora almeno:

• errori PHP in log
• 5xx dal web server
• consumo RAM dei worker
• saturazione CPU
• code in backlog
• tempi di risposta delle URL critiche

Se vedi un aumento di warning o notice, non ignorarlo solo perché il sito "sembra online".

Una parte dei problemi di compatibilità emerge solo sotto carico o su percorsi poco usati.

7. Checklist finale prima di premere il bottone

Prima del go-live, verifica che tutte queste domande abbiano risposta positiva:

• abbiamo letto le note ufficiali di PHP 8.4?
• staging e produzione sono davvero allineati?
• abbiamo testato le aree critiche del sito o dell'app?
• il rollback è documentato e già provato?
• le estensioni native sono compatibili?
• abbiamo una persona di guardia dopo il deploy?
• abbiamo definito i criteri di successo e di stop?

Se la risposta a una sola di queste è "non lo so", fermati e chiudi il gap.

Fonti

• PHP 8.4 Release Announcement
• PHP 8.4 Migration Guide
• PHP Supported Versions

Vuoi farlo senza rischi?

Se stai pianificando un upgrade PHP su più siti o su un server già carico, possiamo aiutarti a:

• fare l'audit prima del cambio
• preparare il rollback
• controllare compatibilità e performance post-deploy

Parti da un audit gratuito oppure dal servizio Gestione Server Quotidiana White-Label.