La settimana scorsa è uscita la Magento 2.3.7, e vale la pena fermarsi un attimo a leggerla per quello che è: non tanto una release ricca di novità, quanto un segnale. È l’ultima minor prevista per la linea 2.3. Da qui in avanti, chi resta su 2.3 riceverà solo patch di sicurezza puntuali, e per un periodo limitato. Il resto dell’attenzione di Adobe è già tutto sulla 2.4.
Lavoro su questa piattaforma dal 2011, quando ancora si chiamava Magento 1, e ho imparato a riconoscere il momento in cui una linea entra in fase di chiusura. Non è un allarme, ma è il punto in cui smettere di rimandare la pianificazione dell’upgrade diventa una scelta consapevole e non più un rinvio comodo.
Cosa porta davvero la 2.3.7
Se vi aspettate feature nuove, resterete delusi, ed è giusto così. La 2.3.7 è una quality & security release, e il suo valore sta esattamente lì. Il grosso del changelog riguarda i security fix: correzioni a vulnerabilità legate a cross-site scripting, controlli sui permessi e sull’input, il tipo di problemi che non si vedono finché non fanno danni. Su un e-commerce che processa pagamenti e dati personali, questa è la parte che conta di più.
Accanto ai security fix ci sono le solite correzioni di qualità: comportamenti anomali dell’indexer, piccole regressioni del checkout, dettagli dell’area admin. Nulla di clamoroso, ma la 2.3.7 rende una 2.3 più stabile e più difendibile di quanto non fosse la 2.3.6. Chi è ancora su 2.3, questa patch la applica e basta: non è in discussione.
Il punto è un altro. Applicare la 2.3.7 non è pianificare il futuro, è mettere in ordine il presente. È l’ultimo giro di manutenzione ordinaria prima che la linea 2.3 esca dai radar dello sviluppo attivo.
Perché la 2.3.7 è un segnale, non un traguardo
La mia opinione, netta: se oggi siete su una qualsiasi 2.3, la 2.3.7 è il momento in cui aprire ufficialmente il dossier “upgrade alla 2.4”. Non domani, non al prossimo budget. Adesso.
Il motivo è che la 2.3 e la 2.4 non sono lo stesso software con qualche patch in mezzo. Sul passaggio ci sono cambiamenti infrastrutturali che vanno digeriti, e il più grosso è Elasticsearch diventato requisito obbligatorio per la ricerca del catalogo. Chi è rimasto con MySQL search si trova davanti non un aggiornamento di codice, ma un pezzo di infrastruttura nuovo da installare, configurare e mettere in produzione. Poi ci sono i requisiti di piattaforma più recenti (PHP su tutti) e, dettaglio non da poco, un Message Queue basato su RabbitMQ che sulla linea 2.4 pesa di più nell’architettura di riferimento.
Tradotto: l’upgrade da 2.3 a 2.4 è un progetto, non un comando da lanciare di venerdì sera. E i progetti hanno una caratteristica fastidiosa: più li rimandi, più diventano cari, perché nel frattempo continui ad accumulare moduli custom, integrazioni ed estensioni di terze parti che dovranno essere tutte verificate e, dove serve, riscritte.
Open Source o Adobe Commerce, il ragionamento non cambia
Faccio una precisazione, perché da aprile il vocabolario è cambiato e vedo ancora un po’ di confusione. Adobe ha ufficializzato il rebrand: la versione enterprise ora si chiama Adobe Commerce, mentre la versione gratuita è Magento Open Source. Il nome “Magento” resta nella tecnologia, ma commercialmente le due edizioni hanno ora etichette distinte.
Cambia il marketing, non la sostanza tecnica del discorso. Che siate su Adobe Commerce o su Magento Open Source, la linea 2.3 chiude e la 2.4 è la destinazione. La differenza pratica è che con Adobe Commerce avete supporto e strumenti in più per gestire la migrazione, mentre su Open Source la responsabilità dell’upgrade è tutta vostra o del vostro partner tecnico. Ma la direzione è identica.
Come affronto un upgrade major di minor in produzione
“Major di minor” lo scrivo apposta: sulla carta è un salto tra versioni minor (2.3 → 2.4), nella pratica ha l’impatto di un progetto major. Ecco come lo gestisco quando c’è un negozio vivo di mezzo, con ordini che entrano ogni ora.
Primo: censimento onesto del custom. La prima cosa che faccio non è toccare il codice, è fare l’inventario. Ogni modulo custom, ogni estensione di terze parti, ogni integrazione con ERP, PIM, gateway di pagamento e sistemi di spedizione. Su un merchant fashion mid-market su cui ho lavorato, il grosso del tempo di un upgrade se n’è andato non sul core Magento, ma sui venti e passa moduli di terze parti da verificare uno per uno. È lì che si nascondono le sorprese, quasi mai nel core.
Secondo: staging che rispecchia la produzione. Un upgrade non si prova sul portatile dello sviluppatore. Serve un ambiente di staging con lo stesso stack (PHP, database, Elasticsearch, Redis, cache) e possibilmente un dump recente dei dati reali, anonimizzati dove serve. La maggior parte dei disastri da upgrade non nasce dal codice, ma dalla differenza tra “funzionava in locale” e la realtà della produzione.
Terzo: Elasticsearch prima di tutto. Se venite da MySQL search, questo è il pezzo che tratto come un mini-progetto a sé. Installazione, configurazione, reindicizzazione completa del catalogo e verifica dei risultati di ricerca, perché una search che restituisce risultati diversi rispetto a prima è un problema di conversione, non un dettaglio tecnico.
Quarto: regression testing sui flussi che generano fatturato. Non serve testare tutto allo stesso modo. Serve testare bene le cose che, se si rompono, fanno perdere soldi: il checkout end-to-end, il calcolo di spedizioni e tasse, l’applicazione dei carrelli e delle promozioni, il flusso di pagamento con il gateway reale in sandbox. Il resto viene dopo.
Quinto: go-live con rete di sicurezza. Backup completo prima di iniziare, finestra a basso traffico, e un piano di rollback deciso prima di premere il pulsante, non improvvisato mentre qualcosa va storto. Nel go-live conta più avere una via d’uscita pronta che sperare che vada tutto bene.
La mia posizione, senza giri di parole
La 2.3.7 fate bene ad applicarla subito: è sicurezza e stabilità, e non ci sono buone ragioni per rimandarla. Ma non scambiatela per un punto d’arrivo. È l’ultima manutenzione ordinaria di una linea che sta chiudendo, e il vero lavoro che vi aspetta è la pianificazione del salto alla 2.4. Chi apre quel dossier oggi, con calma, arriva al momento della migrazione con un preventivo realistico e nessuna corsa contro il tempo. Chi aspetta che le patch di sicurezza finiscano, quel lusso non ce l’avrà.
Mini-FAQ
La 2.3.7 è l’ultima release della linea 2.3?
È l’ultima minor prevista per la linea 2.3. Dopo la 2.3.7, la 2.3 riceve solo patch di sicurezza puntuali e per un periodo limitato, mentre lo sviluppo attivo è concentrato sulla 2.4.
Devo applicare subito la 2.3.7?
Sì, se siete su 2.3. È una release di sicurezza e qualità, con fix a vulnerabilità XSS e ai controlli sui permessi. Applicarla mette in ordine il presente; non sostituisce la pianificazione dell’upgrade alla 2.4.
Qual è il cambiamento più impattante nel passaggio da 2.3 a 2.4?
Elasticsearch diventato requisito obbligatorio per la ricerca del catalogo. Chi viene da MySQL search deve installare e configurare un pezzo di infrastruttura nuovo, non solo aggiornare il codice.
Il rebrand Adobe Commerce cambia il discorso sull’upgrade?
No. Adobe Commerce è la versione enterprise e Magento Open Source è quella gratuita, ma la linea 2.3 chiude in entrambi i casi e la destinazione è la 2.4.
Perché un upgrade di minor viene trattato come un progetto major?
Perché tra 2.3 e 2.4 cambiano requisiti di piattaforma (PHP, Elasticsearch, Message Queue) e vanno verificati tutti i moduli custom e le estensioni di terze parti. Il tempo si consuma lì, non sul core.
Fabio Canovi lavora su Magento e Adobe Commerce dal 2011 ed è tra i primi in Italia ad aver conseguito la certificazione Adobe Commerce. Su questo blog racconta, da insider, cosa succede nell’ecosistema Adobe Commerce e cosa significa per chi vende online.