Comment mettre à jour Magento 2 sans planter sa production ?

Je ne sais pas si vous avez remarqué, mais à aucun moment, Magento ne parle de production dans sa documentation consacrée à la mise à jour de Magento 2. On peut le comprendre : Magento est un éditeur qui fournit une solution, mais ne l’exploite pas au quotidien. Par contre, nous, commerçants et intégrateurs, avons besoin de réussir les mises à jour en production !

Comment s’y prendre ? Comment minimiser les risques ? Un parcours semé d’embûches, nous allons le voir…

La méthode officielle… à ne pas suivre !

La documentation officielle de Magento 2 propose deux approches de mise à jour :

• par un assistant, via le backend ;
• en ligne de commande.

Premier détail important : ces deux approches ne fonctionnent que pour les plateformes qui ont été installées via Composer ou en utilisant une archive Magento officielle. Les développeurs disposent d’une troisième possibilité que nous ne détaillerons pas ici car elle est réservée aux développements de Magento (clone du dépôt Magento 2 sur GitHub).





Revenons sur la première approche de mise à jour de Magento 2 par assistant. Elle existait déjà dans Magento 1, même si techniquement tout a été refondu. Sur le principe, rien de bien compliqué, il suffit de suivre les étapes cachées derrière System > Tools > Web Setup Wizard.

Comme tout va bien se passer (…), vous avez fini !

Enfin… presque, ce serait trop beau. Il reste des manipulations à faire. Et comme vous n’avez pas fait beaucoup d’efforts jusque là, il faut faire ça en ligne de commande ! Ce qui veut dire accessoirement que vous devez avoir un accès au serveur. Que reste-il à faire ? Simplement à purger les dossiers de cache (var/cache, var/page_cache, var/generation) et relancer le service Varnish.

La seconde approche de mise à jour par ligne de commande réalise globalement le même travail que le Web Setup Wizard :

Au final, ce n’est pas insurmontable. Donc où est le problème ?

Le problème, c’est que personne ne prendra jamais le risque de faire cette opération sur un serveur en production ! Il y a des milliers de raisons pour que ça ne se passe pas comme prévu : modules ou extensions incompatibles, droits insuffisants sur le système de fichiers, absences des éléments de setup, composants serveur à mettre à jour, etc. Le risque est d’autant plus grand que le nouveau système de mise à jour est très bien conçu (vérification des composants) et ne laisse rien passer des erreurs que vous pouvez commettre !

Et même, imaginons que tout se passe comme prévu. Avez-vous les moyens de couper le site le temps de réaliser toutes les étapes, notamment la sauvegarde de la base et des fichiers ?

Il faut donc anticiper et préparer cette mise à jour en amont du serveur de production.

La méthode raisonnable… non prévue !

La documentation de Magento, sans être fausse, fait complètement l’impasse sur les réalités du terrain. En pratique, il nous faut préparer la mise à jour, la faire sur des postes de développement, la tester sur des serveurs (test, QA, intégration continue, pré-production, appelez-les comme vous voulez), puis déployer les changements en production : code source de la nouvelle version, mais aussi adaptations des modules spécifiques, des thèmes, des données dans la base…

Ce n’est donc pas une instance de Magento qu’il faut mettre à jour, mais peut-être 30 dans le cas d’un gros site Magento 2. Personne ne fera 30 fois les mêmes manipulations sur des machines différentes, d’abord parce que ça prend du temps, mais aussi parce que personne ne pourra garantir d’avoir exactement le même résultat que le voisin !

Heureusement, il existe une solution déjà ancienne, très efficace et majoritairement utilisée par les équipes qui gèrent des sites sous Magento 1 : le déploiement automatisé.

Petit tour sur la documentation officielle : il y a bien une page sur le sujet, on reste confiant !

Mais on déchante vite quand on accède à la page Deployment steps.





En résumé, Magento 2 est une belle solution qui n’est pas encore prévue pour être mise en production sans risque !

L’écosystème Magento à la rescousse

Heureusement, Magento a un avantage capital : la force de son écosystème. L’éditeur lui-même estime en effet que 250 000 développeurs travaillent sur cette solution, générant 4,2 milliards de dollars de revenus pour 3 900 sociétés dans le monde !

Les initiatives externes à Magento sont donc nombreuses et les échanges permanents entre acteurs assurent l’émergence de solutions de référence, à défaut d’être des solutions officielles.

Par exemple, Davis Alger nous propose une réponse intéressante autour de Capistrano, encore embryonnaire mais avec une bonne compréhension des enjeux du déploiement en production. De plus, il reprend des technologies et des processus déjà mis en œuvre par la plupart des partenaires Magento pour les déploiements de Magento 1. Un article (en anglais) détaille cet outil : Deploying Magento 2 Using Capistrano.

De notre côté, nous avons repris nos outils de déploiement Magento 1 et les avons adaptés à Magento 2. Des différences majeures existent entre les deux versions de Magento, ce qui oblige à repenser une bonne partie du processus de déploiement.

Notre approche fait une séparation très nette entre la mise à jour de Magento, les développements spécifiques et le déploiement. Pour simplifier, nos dépôts de code source (sous Git) ne contiennent pas la totalité des fichiers de Magento 2, mais seulement leur description (metapackage). Cela nous permet de déclencher une mise à jour automatique sur n’importe quelle machine, à partir des mêmes éléments de départ.

Lorsque nous avons besoin de dépasser le cadre du développement (test, intégration continue, recette, pré-production, production), nous utilisons le même procédé, mais nous créons un artefact de la plateforme en fin de traitement. Il servira à déployer une version au comportement unique sur tous les serveurs, jusqu’à la production.

De plus, Capistrano nous assure de déployer la nouvelle version sans couper le site !

En résumé

Si vous devez mettre à jour Magento 2, ne le faites pas directement en production. Ce n’est conseillé pour aucune application web critique et Magento ne fait pas exception.

La documentation officielle n’apporte pas encore de réponse pour assurer une mise à jour sécurisée de sa plateforme en production, mais l’écosystème Magento (en particulier les agences partenaires) ont déjà des solutions efficaces.

Il est vivement conseillé de faire appel à un spécialiste Magento 2 avant de cliquer sur le bouton de mise à jour ! Si vous avez besoin de notre aide, n’hésitez pas à nous envoyer un message. Nous serons ravis de mettre à profit notre expertise pour vous aider à monter en version.