Magento 2.4.x -päivityksen tarkistuslista: ennen, aikana ja jälkeen

Turvallisessa Magento 2.4.x -päivityksessä on kolme vaihetta. Ennen: tarkista, mikä versiolinja on vielä tuettu, varmista tavoiteversion edellyttämät PHP-, OpenSearch- ja tietokantaversiot ja käy jokainen laajennus ja oma moduuli läpi sitä vasten. Aikana: päivitä staging-kopiossa tuotantodatalla ja aja sitten regressiotestit kassalle ja jokaiselle integraatiolle. Jälkeen: julkaise suunniteltuna ajankohtana testatun rollback-suunnitelman kanssa ja seuraa virheitä, tilauksia ja suorituskykyä ensimmäisinä päivinä. Alla on tarkistuslista, jonka käymme läpi jokaisessa päivityksessä – kirjoitettu verkkokauppiaille ja toimistoille, jotka antavat päivitykset meidän hoidettaviksemme.

Alla olevat versiot ja päivämäärät on tarkistettu Adoben virallisesta dokumentaatiosta marraskuussa 2026. Adobe päivittää näitä sivuja säännöllisesti, joten tarkista ne uudelleen, kun suunnittelet päivitystä.

Ennen päivitystä

1. Tiedä, missä versiosi on menossa

Adobe antaa jokaiselle 2.4.x-versiolinjalle kolmen vuoden vakiotuen julkaisupäivästä alkaen, ja se sisältää laatukorjaukset ja tietoturvapäivitykset. Osa vanhemmista linjoista saa lisäaikaa. Magento Open Source -julkaisut seuraavat samoja 2.4.x-versiolinjoja ja patch-aikataulua kuin Adobe Commerce; elinkaaripäivämäärät Adobe julkaisee Adobe Commercelle.

Mitä tämä tarkoittaa käytännössä:

• Versiossa 2.4.4 tai 2.4.5: saat vain yksittäisiä tietoturvakorjauksia, et laatukorjauksia, eikä tätä jaksoa pidennetä. Suunnittele minor-päivitys nyt.
• Versiossa 2.4.6: vakiotuki on päättynyt. Aikaa on, mutta ei paljon.
• Versiossa 2.4.7 tai 2.4.8: asenna jokainen tietoturvapäivitys ( -pN-julkaisut) ja suunnittele seuraava minor-päivitys rauhassa.
• Adobe Commerce Cloudissa: 1.6.2027 alkaen Adobe lopettaa sellaisten Cloud-ympäristöjen ylläpidon, joissa on tukemattomia versioita.

Tarkista myös, että käytössäsi on versiolinjasi uusin patch. Adoben erilliset tietoturvapatch-tiedostot voi asentaa vain sen päälle, joten kauppaan, joka on useita patcheja jäljessä, ei saa hätäkorjausta nopeasti.

2.4.10-linja on kirjoitushetkellä alfavaiheessa. Älä suunnittele tuotantopäivitystä alfa- tai beetaversioon.

2. Tarkista alustan vaatimukset

Suuri osa päivityksen riskeistä on Magenton ulkopuolella: PHP, hakukone, tietokanta ja välimuisti. Adoben järjestelmävaatimukset kunkin linjan uusimmalle patchille (oma palvelin):

Kohdat, jotka yllättävät tiimit:

• PHP-hypyt. Siirtyminen 2.4.6:sta 2.4.9:ään tarkoittaa siirtymistä PHP 8.1/8.2:sta 8.5:een. Jokaisen oman moduulin ja laajennuksen on toimittava uudella PHP-versiolla, ei vain Magenton ytimen. PHP 8.2 itse saa tietoturvakorjauksia vain 31.12.2026 asti.
• Hakukone. Elasticsearch 7.17:n tuki päättyi 15.1.2026, ja 2.4.9 tukee vain OpenSearch 3:a. Jos käytät yhä Elasticsearchia, hakukoneen migraatio on osa projektia. Varaa budjettia uudelleenindeksointiin ja hakulaajennusten tarkistamiseen OpenSearchia vasten.
• Tietokanta. MySQL 8.0:n tuki päättyi 30.4.2026. Tarkista, mitä MySQL- tai MariaDB-versioita tavoiteversiosi tukee, ennen kuin kosket koodiin.
• Välimuisti. Uusimmissa patcheissa Redisin tilalla on Valkey. Hostingisi tai Cloud-ympäristösi on tarjottava se versio, jota tavoiteversio edellyttää.
• Commerce Cloudilla on oma vaatimustaulukkonsa, joka poikkeaa oman palvelimen taulukosta. Käytä Cloud-arvoja, jos olet Cloudissa.

3. Laadi laajennusten yhteensopivuusmatriisi

Listaa kaikki kolmannen osapuolen moduulit tiedostosta composer.json ja hakemistosta app/code ja täytä jokaisesta laajennuksesta yksi rivi:

• asennettu versio ja toimittaja;
• versio, joka tukee tavoiteltua Magento-versiota ja PHP-versiota (toimittajan muutoslokista, ei pelkästä Marketplacen merkinnästä);
• lisenssin tai tuen tila, koska osa päivityksistä vaatii maksullisen uusinnan;
• onko moduuli ylipäätään enää käytössä.

Merkitse jokainen rivi: päivitä, korvaa, korjataan itse tai poista. Hylätyt moduulit ovat yleinen syy päivitysarvioiden kasvuun. Käyttämättömien moduulien poistaminen on usein halvin korjaus.

4. Käy läpi oma koodi ja vanhentuneet API:t

• Ytimen muutokset. Etsi muutoksia hakemistossa vendor/, ylikirjoitettuja ydinluokkia ja Composer-patcheja. Jokainen niistä on tarkistettava uudelleen uutta versiota vasten.
• Ydinluokkien pluginit ja preferencet hajoavat, kun metodien signatuurit muuttuvat.
• Taaksepäin yhteensopimattomat muutokset. Adobe julkaisee niistä listan jokaiselle versiolle. Esimerkiksi 2.4.9 siirtyy Symfony 7.4 LTS:ään, joten Symfonyn ydinluokkia laajentavat omat luokat tarvitsevat päivitetyt tyyppimäärittelyt ja metodisignatuurit. Lisäksi se hylkää API:n kautta ilman laskutusosoitetta luodut tilaukset, millä on merkitystä, jos ERP- tai markkinapaikkaliitäntä luo tilauksia.
• Adobe Commercessa aja Adoben Upgrade Compatibility Tool tavoiteversiota vasten. Se raportoi moduuliesi ja ytimen koodin kriittiset ongelmat, virheet ja varoitukset. Työkalu ei ole saatavilla Magento Open Sourcelle; siellä sama tarkistus tehdään käsin ja staattisella analyysillä.

5. Valmistele staging ja varmuuskopiot

• Tuotantoa vastaava staging-ympäristö: samat PHP-, hakukone-, tietokanta- ja välimuistiversiot kuin tavoiteversiossa, ei kuin tänään.
• Tuore kopio tuotantodatasta, anonymisoituna, jos staging-ympäristö on huonommin suojattu kuin tuotanto.
• Varmuuskopiot, jotka olet palauttanut ainakin kerran: tietokantadumppi, media/, app/etc/env.php ja julkaistu koodi (tai julkaisuartefakti). Varmuuskopio, jota ei ole koskaan palautettu, on toive eikä varmuuskopio.
• Sovittu koodijäädytys tai ainakin selkeä haarastrategia, jotta päivityksen aikana kehitettävät ominaisuudet eivät törmää siihen.

Päivityksen aikana

6. Päivitä pienin, tarkistettavin askelin

1. Päivitä ensin infrastruktuuri staging-ympäristössä: PHP, hakukone, tietokanta ja välimuisti.
2. Päivitä Magento ja laajennukset Composerilla ryhmä kerrallaan ja tee commit jokaisen vaiheen jälkeen.
3. Aja setup:upgrade, käännä DI ja julkaise staattinen sisältö, ja korjaa jokainen virhe ja vanhentumisvaroitus. Älä vaienna niitä.
4. Asenna Composer-patchit uudelleen tai poista ne; osa niistä käy tarpeettomiksi päivityksen jälkeen.
5. Rakenna frontend-resurssit uudelleen ja tarkista teema, varsinkin jos se ylikirjoittaa ytimen templateja.

7. Regressiotestaa se, mikä tuo rahaa

Automaattitestit auttavat, mutta kirjallinen testisuunnitelma, joka kattaa todelliset liiketoimintaprosessit, on vähimmäisvaatimus:

• Kassa: vierasostajana ja kirjautuneena, jokainen maksutapa (myös 3-D Secure ja lompakot), jokainen toimitustapa, kupongit, lahjakortit sekä verot ja valuutat jokaisessa store view’ssa.
• Asiakastili: rekisteröityminen, kirjautuminen, salasanan palautus, tilaushistoria, uudelleentilaus.
• Tuotekatalogi ja haku: kategoriasivut, suodatinnavigaatio, hakutulokset ja automaattinen täydennys uudelleenindeksoinnin jälkeen, konfiguroitavat tuotteet ja tuotepaketit, asiakasryhmäkohtaiset hinnat.
• Integraatiot: ERP- ja varastosynkronointi, tilausvienti, maksu- ja toimitus-webhookit, markkinapaikkasyötteet, sähköposti- ja markkinointityökalut, analytiikan ja tag managerin tapahtumat. Testaa molemmat suunnat oikeilla (sandbox-)tunnuksilla.
• Hallinta ja ylläpito: tilausten luonti ja laskutus, hyvityslaskut, tuonnit, cron-ajot, jonojen kuluttajat ja transaktiosähköpostit.
• B2B-ominaisuudet Adobe Commercessa: yritystilit, jaetut katalogit, tarjoukset, hankintalistat.

Tee myös nopea suorituskykytarkistus: full page cachen osumaprosentti, palvelimen vasteaika tärkeillä sivuilla ja Core Web Vitals muuttamissasi templateissa.

8. Suunnittele julkaisuikkuna ja rollback

• Valitse hiljaisen liikenteen ajankohta kampanjoiden, alennusmyyntien ja muiden sesonkihuippujen ulkopuolelta.
• Kirjoita julkaisun runbook: vaiheet, kuka tekee mitä, arvioitu kesto ja rollback-päätöksen hetki.
• Määrittele rollback-kriteerit ennen julkaisua (esimerkiksi: kassa rikki, maksut epäonnistuvat, integraatiovirheitä, joita et saa korjattua ikkunan aikana).
• Pidä edellinen julkaisu ja tuore tietokantavarmuuskopio valmiina ja tiedä, kauanko palautus kestää. Kun tietokannan päivityksen jälkeen tulee uusia tilauksia, tietokannan palauttaminen tarkoittaa niiden menettämistä, joten rollback-ikkuna on lyhyt.
• Laita kauppa huoltotilaan vain niiden vaiheiden ajaksi, jotka sitä vaativat, ja kerro aikataulu etukäteen asiakaspalvelulle ja markkinoinnille.

Päivityksen jälkeen

9. Seuraa ensimmäisiä päiviä tarkasti

• Virheet: PHP- ja poikkeuslokit, epäonnistuneet cron-ajot, jumiin jääneet jonojen kuluttajat.
• Tilaukset: vertaa tilausmäärää ja epäonnistuneiden maksujen osuutta tavalliseen viikkoon. Hiljainen notkahdus on usein ensimmäinen merkki maksu- tai kassaongelmasta.
• Integraatiot: varmista, että tilaukset menevät ERP:hen, varastosaldot palaavat ja webhookit onnistuvat.
• Haku ja indeksointi: indeksit kunnossa, hakutulokset järkeviä, ei kasvavaa uudelleenindeksoinnin jonoa.
• Suorituskyky: vasteajat, välimuistin osumaprosentti ja Core Web Vitals verrattuna päivitystä edeltävään tilanteeseen.

10. Vie työ loppuun

• Poista korvatut moduulit ja patchit ja siivoa vanhat julkaisuartefaktit.
• Päivitä dokumentaatio: versiot, laajennusmatriisi, runbook.
• Merkitse seuraava tietoturvapäivitys kalenteriin. Kun pysyt linjasi uusimmassa patchissa, seuraava minor-päivitys pysyy pienenä.

Patch-, minor- tai vanhemman version päivitys: mitä odottaa

• Patch-päivitys (esimerkiksi 2.4.8-p4:stä 2.4.8-p5:een): pieni laajuus, enimmäkseen testausta. Sen pitäisi olla rutiinia.
• Minor-päivitys (esimerkiksi 2.4.7:stä 2.4.8:aan tai 2.4.9:ään): uudet PHP- ja palveluversiot, laajennuspäivitykset ja oman koodin korjaukset. Tämä on projekti, ei yksittäinen tehtävä.
• Päivitys versiosta 2.3 tai vanhemmasta: varaudu suurempaan työmäärään, koska välissä on useita PHP-versioita ja paljon vanhentuneita komponentteja.

Jos harkitset myös Luman vaihtamista, lue ensin Milloin Hyvä kannattaa?. Hyvä-migraation voi yhdistää minor-päivitykseen; jos versio ei ole enää tuettu, päivitys tehdään ensin.

Apua päivitykseen

Jos haluat toisen silmäparin ennen aloittamista, tarjoamme maksuttoman pika-auditoinnin: versiot, patch-taso, suorituskyky ja perustietoturva, lyhyt raportti ja 20 minuutin puhelu. Itse päivitykseen on tarjolla kiinteähintaisia päivityspaketteja , hinnat alkaen 300 € (patch-päivitys) ja 1 000 € (2.4.x-minor-päivitys PHP-päivityksineen). Lopullinen hinta sovitaan auditoinnin jälkeen. Jotta kauppa pysyy jatkossakin ajan tasalla, katso Magento-ylläpitosopimukset.

Lähteet (englanniksi): Adobe Experience League: Elinkaarikäytäntö, Järjestelmävaatimukset, Julkaistut versiot, Julkaisuaikataulu, Magento Open Source 2.4.9:n julkaisutiedot, Upgrade Compatibility Tool; Adobe Developer: Taaksepäin yhteensopimattomat muutokset; PHP:n tuetut versiot.