La 2.4.5 è uscita da pochi giorni, il 9 agosto, e come ogni volta la prima domanda che mi arriva dai team con cui lavoro è sempre la stessa: “devo aggiornare adesso o posso aspettare?”. La mia risposta breve è che questa non è una release da rimandare a tempo indeterminato. Non perché ci sia una funzionalità che cambia la vita, ma perché tocca due punti che riguardano tutti: la sicurezza e la piattaforma su cui gira il vostro store. Provo a spiegare come la leggo io, dopo aver passato in rassegna le release notes e aver iniziato a testarla su qualche ambiente di staging.
Cosa porta davvero la 2.4.5
Tolgo subito di mezzo l’aspettativa sbagliata: la 2.4.5 non è una release “di funzionalità”. È una release di consolidamento, e va benissimo così. I tre blocchi che contano sono questi.
Security fix. Adobe Commerce e Magento Open Source 2.4.5 chiudono un gruppo di vulnerabilità, alcune delle quali richiedono anche interventi di configurazione lato server oltre al semplice aggiornamento del codice. Non entro nel dettaglio dei singoli CVE perché il punto per chi vende online è un altro: la sicurezza in Magento non è mai “aggiorna e dimentica”. Alcune protezioni vanno abilitate a mano.
Compatibilità con PHP 8.1 e Composer 2.2. Il supporto a PHP 8.1 era già arrivato con la 2.4.4 a marzo, ma sul campo l’ecosistema di terze parti non era ancora del tutto pronto. Con la 2.4.5, e con i vendor che nel frattempo hanno allineato i loro moduli, PHP 8.1 diventa per me una scelta che si può portare in produzione con serenità. Sul fronte dependency management, la 2.4.5 richiede Composer 2.2, che è la versione LTS: significa meno sorprese negli aggiornamenti e una base più stabile per la pipeline di build.
Centinaia di miglioramenti di qualità. La release porta con sé oltre trecento fix di qualità distribuiti su carrello, checkout, gestione catalogo, import/export, GraphQL e pannello di amministrazione. Presi uno per uno sono poco spettacolari. Presi insieme sono esattamente il tipo di lavoro che riduce i ticket noiosi che nessuno vuole gestire il lunedì mattina.
PHP 8.1 in produzione: la mia lettura
Qui voglio essere netto, perché è il punto su cui vedo più esitazione. Molti merchant sono rimasti su PHP 7.4 ben oltre la sua fine vita, e ogni volta la giustificazione è la stessa: “funziona, non tocchiamo niente”. Il problema è che un runtime non più supportato è un rischio di sicurezza che non si vede finché non è troppo tardi. La 2.4.5 è l’occasione buona per chiudere quel capitolo.
Su un paio di progetti, un merchant fashion intorno ai 15 milioni di GMV e un B2B con un catalogo pesante, il passaggio a PHP 8.1 ha dato benefici concreti in termini di tempi di risposta lato applicativo. Non parlo di numeri da conferenza, parlo di qualche decina di millisecondi in meno sulle pagine più calde, che a volume si sente. Ma il vero motivo per cui spingo su 8.1 non è la performance: è avere una piattaforma supportata, con un ciclo di patch attivo. In sicurezza, la noia è una virtù.
Se siete già sulla 2.4.4
Chi è sulla 2.4.4 è nella posizione migliore, e proprio per questo dovrebbe pianificare il salto alla 2.4.5 presto, non “quando capita”. Il delta tra due minor consecutive è gestibile: poche incompatibilità note, di solito concentrate su qualche modulo di terze parti e su eventuali customizzazioni fatte a mano nel checkout. Se avete un ambiente di staging serio e una suite di test decente, è un aggiornamento che si pianifica in una finestra ragionevole, senza dramma.
La mia raccomandazione: non fatelo diventare un progetto da sei mesi. Le minor si accumulano, e chi rimanda oggi la 2.4.5 si ritroverà tra un anno con un salto più grande e più costoso da fare. Il debito di aggiornamento è come qualsiasi altro debito: gli interessi li paga sempre chi rimanda.
Se siete indietro, molto indietro
Poi c’è l’altra categoria, quella che mi preoccupa di più: chi è fermo a una 2.4.3, 2.4.2 o peggio, e in qualche caso ancora su rami che dovrebbero essere solo un ricordo. Qui il discorso cambia. Non state rimandando un aggiornamento, state accumulando un rischio di sicurezza e un debito tecnico che a un certo punto esplode.
A chi è in questa situazione dico una cosa impopolare: fate il salto e usate la 2.4.5 come destinazione. Sì, sarà un progetto vero, con testing, sistemazione dei moduli di terze parti, probabile aggiornamento di PHP e della toolchain. Ma proprio perché è un progetto, tanto vale arrivare all’ultima versione stabile e non a una tappa intermedia che tra sei mesi sarà di nuovo da rifare. Ho visto merchant spendere due volte perché avevano scelto un target di aggiornamento “prudente” che era già vecchio il giorno del go-live.
Testing e tempi: come lo farei io
La parte che troppi sottovalutano è il testing, ed è esattamente quella che fa la differenza tra un aggiornamento noioso e un weekend rovinato. Il mio approccio, sintetico.
- Ambiente di staging identico alla produzione. Stessa versione di PHP, stessa configurazione di Elasticsearch/OpenSearch, stessi dati (anonimizzati) di catalogo e ordini. Un aggiornamento testato su un ambiente “diverso” non è testato.
- Inventario dei moduli di terze parti. Prima ancora di toccare il core, verificate quali estensioni dichiarano compatibilità con la 2.4.5 e con PHP 8.1. È qui che si annidano il 90% delle sorprese.
- Regression sui flussi che generano fatturato. Checkout, metodi di pagamento, calcolo spedizioni, applicazione dei carrelli promozionali. Se qualcosa deve funzionare, è questo.
- Prova di rollback. Non date per scontato di poter tornare indietro: provateci davvero, in staging, prima del go-live.
Sui tempi: per chi parte dalla 2.4.4 con un progetto in salute, una finestra di due o tre settimane tra inizio del testing e messa in produzione è realistica. Per chi arriva da versioni molto più vecchie, ragionate in mesi, non in giorni, e mettete in conto un intervento sui moduli custom. La fretta, in un upgrade Magento, si paga sempre in ambiente di produzione.
In sintesi
La 2.4.5 non è una release che vi farà vendere di più domani mattina. È una release che vi tiene sicuri, supportati e su una piattaforma moderna, e questo per un merchant serio conta più di qualsiasi feature appariscente. Chi è sulla 2.4.4 la pianifichi presto. Chi è indietro la usi come traguardo del prossimo progetto di aggiornamento. In entrambi i casi, il testing non è un optional: è il progetto.
Mini-FAQ
Quando è uscita Adobe Commerce 2.4.5?
Adobe Commerce e Magento Open Source 2.4.5 sono disponibili dal 9 agosto 2022.
La 2.4.5 supporta PHP 8.1?
Sì. La 2.4.5 supporta PHP 8.1 (oltre a PHP 8.0) e richiede Composer 2.2, la versione LTS. PHP 7.4 non è più supportato.
Chi è sulla 2.4.4 dovrebbe aggiornare subito?
Sì, conviene pianificarlo presto. Il salto tra 2.4.4 e 2.4.5 è contenuto e rimandarlo non fa che aumentare il costo del prossimo aggiornamento.
E chi è su versioni più vecchie della 2.4.4?
Meglio pianificare un progetto di aggiornamento vero con la 2.4.5 come destinazione finale, per non fermarsi a una tappa intermedia già superata.
Quanto tempo serve per aggiornare?
Partendo da una 2.4.4 in salute, due o tre settimane tra testing e go-live sono realistiche. Da versioni molto più vecchie il tempo si misura in mesi.
Chi sono. Mi occupo di Adobe Commerce e Magento Open Source da oltre dieci anni, come consulente e progettista di soluzioni e-commerce per merchant mid-market. Sono tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce. Su questo blog racconto la mia lettura da insider di ciò che succede nella piattaforma e nell’ecosistema, senza vendere nulla.