Mettre à niveau la version de Commerce

Pour installer ou mettre à jour les services dans les environnements Staging et Production uniquement, envoyez un ticket d’assistance Adobe Commerce.

Dans le ticket, spécifiez les changements de service requis, incluez les fichiers .magento.app.yaml et .magento/services.yaml mis à jour et notez la version PHP cible.

La version PHP, les mises à jour du compositeur, les extensions et les paramètres d’environnement sont des changements en libre-service. Adobe peut avoir besoin de mettre à jour l’agent New Relic pour assurer la compatibilité des versions PHP. Voir Paramètres PHP dans Configuration des applications.

Confirmez le planning de mise à niveau via le processus en deux parties d’Adobe : vous confirmez d’abord la date et l’heure demandées, puis l’assistance les soumet à l’équipe d’infrastructure pour confirmation finale.

Les changements de production (Pro uniquement) nécessitent un préavis d’au moins deux jours ouvrables, à l’exclusion des week-ends. Par exemple, l’équipe d’infrastructure cloud doit confirmer une mise à niveau du lundi avant le mercredi précédent. Attendez-vous à un délai d’avance supplémentaire pendant les pics de demande. Pour éviter les retards, répondez à la demande initiale au moins 48 heures avant la fenêtre. La mise à niveau n’est pas considérée comme planifiée tant que vous n’avez pas reçu la confirmation finale.

Validez la mise à niveau dans un environnement d’évaluation ou d’intégration avant de la planifier en production.

Les problèmes causés par des modules tiers, du code personnalisé ou la compatibilité des dépendances apparaissent souvent lors du redéploiement qui suit une mise à niveau du service. Pour valider plusieurs mises à niveau de service une par une, un ordre raisonnable est Valkey ou Redis, puis RabbitMQ, puis OpenSearch, puis MariaDB. Cette séquence n’est pas obligatoire. Les mises à niveau de bases de données ont l’impact opérationnel le plus important et méritent la plus grande prudence.

Adobe ne garantit pas à l’avance la durée exacte d’une fenêtre de maintenance de production, car le timing dépend de l’environnement et des services impliqués. Utilisez le temps nécessaire à la mise à niveau intermédiaire comme une estimation pratique lors de la planification de la fenêtre Production.

Redéployez l’environnement une fois que Adobe a terminé la mise à niveau du service afin que la modification prenne effet, même si la version de l’application Adobe Commerce ne change pas.

Si la mise à niveau inclut OpenSearch, prévoyez également une réindexation complète. Adobe ne peut pas garantir un temps d’arrêt nul pour une mise à niveau du service. Planifiez donc une fenêtre de maintenance qui laisse le temps de redéployer, de réindexer si nécessaire et de valider le storefront et l’administrateur avant de rouvrir le site.

Ajoutez les allow-plugins suivantes à la section config :

"config": {
   "allow-plugins": {
      "dealerdirect/phpcodesniffer-composer-installer": true,
      "laminas/laminas-dependency-plugin": true,
      "magento/*": true
   }
},

Ajoutez le module externe suivant à la section require :

"require": {
    "magento/composer-root-update-plugin": "^2.0.3"
},

Ajoutez le composant suivant à la section extra:component_paths :

"extra": {
   "component_paths": {
      "tinymce/tinymce": "lib/web/tiny_mce_5"
   },
},

Enregistrez le fichier. Ne validez pas et n’envoyez pas encore de modifications à votre branche.

Poursuivez le processus de mise à niveau.

Créez une sauvegarde locale de la base distante.

magento-cloud db:dump

Sauvegardez le code et le média.

php bin/magento setup:backup --code [--media]

Vous pouvez éventuellement omettre [--media] si vous disposez d’un grand nombre de fichiers statiques qui se trouvent déjà dans le contrôle de code source.

Utilisez SSH pour vous connecter à l’environnement distant.

Créez une image mémoire de la base de données. Pour choisir un répertoire cible pour l’image mémoire de la base de données, utilisez l’option --dump-directory.

vendor/bin/ece-tools db-dump

L’opération de vidage crée un fichier d’archive dump-<timestamp>.sql.gz dans votre répertoire de projet distant. Voir Sauvegarde de la base de données.

Sur votre station de travail locale, accédez au répertoire du projet.

Définissez la contrainte de version pour la version de mise à niveau cible. Cette étape n’est nécessaire que si la version cible se trouve en dehors de la contrainte existante.

composer require-commerce "magento/magento-cloud-metapackage":">=CURRENT_VERSION <NEXT_VERSION" --no-update

Mettez à jour votre fichier composer.json avec la version de mise à niveau de Commerce principale.

composer require-commerce magento/product-enterprise-edition 2.4.8 --no-update

Si vous utilisez le B2B, mettez à jour votre fichier composer.json avec la version prise en charge pour Commerce.

composer require-commerce magento/extension-b2b 1.5.2 --no-update

Mettez à jour les dépendances de projet.

composer update

Examinez les correctifs actuellement appliqués :

• Si des correctifs sont installés dans le répertoire m2-hotfixes, envoyez un ticket d’assistance Adobe Commerce et contactez l’assistance Adobe Commerce pour vérifier quels correctifs peuvent toujours être appliqués à la nouvelle version. Supprimez le ou les correctifs non applicables du répertoire m2-hotfixes.

• Si des [correctifs de qualité] sont appliqués dans le fichier .magento.env.yaml, vérifiez s’ils peuvent toujours être appliqués à la nouvelle version. Supprimez le ou les correctifs non applicables de la section QUALITY_PATCHES du fichier .magento.env.yaml.

Méthode 1 : vérifiez les versions applicables dans les notes de mise à jour des correctifs de qualité

Méthode 2 : affichage des correctifs et de l’état disponibles

Méthode 3 : Rechercher des correctifs

Ajout, validation et modifications de code push.

git add -A

git commit -m "Upgrade"

git push origin <branch-name>

git add -A est nécessaire pour ajouter tous les fichiers modifiés au contrôle de code source en raison de la manière dont le compositeur marshale les packages de base. composer install et composer update marshalent les fichiers du package de base (magento/magento2-base et magento/magento2-ee-base) dans la racine du package.

Les fichiers que le compositeur marshale appartiennent à la nouvelle version d’Adobe Commerce, afin de remplacer la version obsolète de ces mêmes fichiers. Actuellement, le marshalling est désactivé dans Adobe Commerce, vous devez donc ajouter les fichiers marshalés au contrôle de code source.

Pour terminer la mise à niveau, attendez le déploiement.

Vérifiez la mise à niveau dans votre environnement d’intégration, d’évaluation ou de production à l’aide de SSH pour vous connecter et vérifier la version.

php bin/magento --version

Créez une branche sur votre station de travail locale.

Désactivez vos extensions selon vos besoins.

Lorsqu’elles sont disponibles, téléchargez les mises à niveau d’extension.

Installez la mise à niveau comme indiqué dans la documentation tierce.

Activez et testez l’extension.

Ajoutez, validez et envoyez les modifications de code à la télécommande.

Envoyez et testez dans votre environnement d’intégration.

Pour effectuer des tests dans un environnement de pré-production, effectuez des transferts vers l’environnement d’évaluation.

Sur votre station de travail locale, accédez au répertoire du projet.

Utilisez SSH pour vous connecter à l’environnement distant.

magento-cloud ssh

Ouvrez le fichier ./app/var/report/<error number>.

Examinez les journaux et déterminez la source du problème.

Ajout, validation et modifications de code push.

git add -A && git commit -m "Fixed deployment failure" && git push origin <branch-name>