Vue d'ensemble:

Cette question avait été initialement posée et ensuite fermée sur StackOverflow . Nous avons déclaré en méta que voici le bon endroit pour cette question.

Cette question est utile pour aider beaucoup de gens à trouver le bon moyen d'estimer les mises à jour de Magento.

La question:

Je suis intéressé de savoir comment mesurer le temps nécessaire à la mise à niveau de Magento. Je suppose que la plupart d'entre vous ont eu du mal à répondre à la question du client: "Combien de temps faudra-t-il pour mettre à niveau mon magasin Magento?"

En général, le client n'a besoin d'entendre qu'un numéro, par exemple: "Cela prendra X heures et cela coûtera Y dollars."

L'idée principale de la question concerne l'aspect technique et que vérifie-t-on en tant que développeur pour effectuer vos propres calculs pour les mises à niveau de Magento?

J'ai créé la liste de contrôle suivante, juste pour mes propres calculs:

• Le noyau de Magento est-il touché?
• Le schéma de la base de données Magento est-il touché?
• Avons-nous des données incohérentes dans la base de données?
• Combien d'extensions personnalisées sont installées dans le pool de codes local et de communauté?
• L'extension personnalisée est-elle compatible avec la dernière version de Magento?
• Le développeur de thème a-t-il utilisé le fichier local.xml pour les directives de présentation ou a-t-il simplement copié des fichiers XML à partir du répertoire base / défaut / présentation dans le répertoire de présentation du thème personnalisé?
• Avons-nous des directives / méthodes de mise en forme obsolètes dans les fichiers XML de mise en page?
• Ai-je développé cette boutique Magento?

Pensez-vous que quelque chose me manque et si oui, aimeriez-vous partager avec moi et la communauté vos points supplémentaires pour la liste de contrôle?

L’estimation de la mise à niveau de Magento consiste à collecter des informations sur les modifications apportées à l’installation que vous êtes sur le point de mettre à jour, à vérifier si ces modifications peuvent poser problème et à évaluer le temps requis pour les résoudre.

Toutes les modifications peuvent être littéralement divisées en non -core et in-core .

Les modifications hors cœur sont celles qui ne seront pas écrasées par la mise à niveau. Il s’agit d’ extensions tierces , de fichiers principaux placés dans une portée locale (app / code / local / Mage) et d’un thème personnalisé .

Les modifications in-core sont appliquées directement sur les fichiers de base de Magento (app / code / core), les fichiers de localisation (app / locale / en_US), les modèles de base et certaines choses comme les javascripts , les bibliothèques externes qui sont rarement personnalisées doivent néanmoins être prises en compte .

Modifications hors cœur

Extensions tierces

Lors des mises à niveau, les extensions tierces constituent la principale source de problèmes. Ce qui signifie que plus vous aurez d’extensions, vous aurez plus de temps pour les analyser.

La première chose à vérifier est de savoir si la fonctionnalité fournie par l'extension n'est pas encore implémentée dans une version de Magento vers laquelle vous effectuez la mise à niveau. Par exemple, certaines extensions telles que Yoast_CanonicalUrl, Mxperts_CustomerAddressou Fontis_Wysiwygétaient largement utilisées dans Magento 1.3.xx et plus, mais font maintenant partie des fonctionnalités de base de Magento et ne sont plus nécessaires.

Ensuite, c'est une bonne idée de vérifier (demandez à votre client) si vous avez vraiment besoin de toutes les extensions que vous avez. Vous avez peut-être installé des extensions que vous n’avez jamais vraiment utilisées. Donc, à ce stade, il est bon de faire une sorte de nettoyage.

Il est ensuite important de vérifier la compatibilité de chacune des extensions restantes avec une version de Magento vers laquelle vous effectuez une mise à niveau. Si certaines extensions ne sont pas compatibles et qu'aucune extension similaire n'est disponible, vous aurez le choix difficile de perdre certaines fonctionnalités ou de modifier les extensions existantes pour les rendre compatibles.

Remarque: ne modifiez pas directement l'extension tierce, mais créez une nouvelle extension qui étendra une extension obsolète, puis définira une dépendance dans une XML d'amorçage de la nouvelle extension.

Une fois toutes ces tâches effectuées, l’analyse de chacune des extensions restantes peut être fournie. Il doit toujours commencer par l'examen du etc/config.xmldossier. Il y a 3 choses à rechercher:

• La réécriture de classe n’est pas une technique propre en soi, mais dans certains cas, il n’ya pas d’autre solution. Donc, si la classe réécrite était modifiée dans la nouvelle version de Magento, cela pourrait être un problème potentiel.
• Les mises à jour de mise en page poseront probablement moins de problèmes avec votre mise à niveau, mais si l'extension fait référence à un bloc obsolète dans une nouvelle version de Magento, vous devrez vous en occuper.
• Les mises à jour SQL sont une source de problèmes fortement sous-estimée lors des mises à niveau. Le problème se produit lorsque l'extension tierce crée une clé étrangère faisant référence à un champ de la table Magento par défaut. En conséquence, ce champ est verrouillé contre les modifications. Et puis, si le script d'installation natif tente de mettre à jour ce champ, il échouera de manière silencieuse. Après cela, chaque script d’installation suivant faisant référence à ce champ plantera votre mise à niveau.

app / code / local / mage

Après avoir terminé vos extensions, il est temps de jeter un coup d'œil à votre app/code/local/Magerépertoire. Vous trouverez ici les fichiers de base modifiés déplacés dans une localétendue. Chacune d'entre elles vous coûtera sûrement des cheveux gris, car vous ne saurez jamais (si ce n'est vous qui les avez mis là) ce qui a été modifié et pour quelle raison. Vous devez donc comparer chacune d'elles avec une origine et migrer les fonctionnalités ajoutées vers le fichier correspondant de la nouvelle version.

Thème personnalisé

La dernière modification hors groupe est le thème personnalisé. Cela peut sembler être peu grave, mais en réalité, il s’agit d’une zone grise. Le thème de base de Magento est modifié de version en version et chaque thème personnalisé doit imiter certaines de ces modifications. Malheureusement, il n’ya pas de solution miracle pour déterminer ce qu’il faut rechercher et ce qui doit être migré. Préparez-vous donc à des surprises majeures et à des reproches mineurs après votre mise à niveau.

Modifications In-Core

Dans le monde parfait, il n'y en a pas. Mais lorsque vous obtenez une installation Magento après avoir été utilisée de manière abusive par des développeurs tiers, qui offrent beaucoup pour pas cher, vous pouvez vous attendre à tout. Les modifications dans le noyau sont donc celles qui seront écrasées au cours du processus de mise à niveau. Dans la plupart des cas, cela ne produira aucune erreur, mais vous perdrez la fonctionnalité ajoutée de manière aussi brutale.

Le seul moyen de détecter les modifications internes consiste à comparer tous les fichiers de votre installation Magento avec des fichiers propres de la même version. Je recommande de le faire avec git. Pourquoi? Tout simplement parce qu'il gérera toutes les nouvelles lignes et les espaces.

Même si votre installation de Magento n'est pas sous git, vous pouvez toujours copier vos fichiers dans un répertoire séparé, puis exécuter git init. Effectuez ensuite la validation initiale, copiez les fichiers «propres» Magento et exécutez-les git status. Vous obtiendrez quelque chose comme ceci:

Maintenant, en fonction du nombre de fichiers modifiés, vous pouvez exécuter simultanément git diffsur chaque fichier ou sur tout le lot. Cela vous donnera une référence complète de toutes les modifications apportées dans le cœur. Si vous avez une visualisation git telle que phpStorm, la vie est beaucoup plus facile pour vous:

Je suggère de le faire git diff > changes.txt, vous aurez toujours une liste de modifications à la main.

Ayant la liste des modifications de base, vous pouvez estimer ce qui doit être transféré dans une nouvelle version et combien de temps il faudra pour le faire.

Maintenant, je voudrais donner quelques conseils pour une mise à niveau réelle. Ce processus est bien documenté, je ne vais donc pas écrire les commandes à exécuter ni les endroits où cliquer. Cependant, je veux mettre l'accent sur plusieurs choses importantes:

• Nous supposons que vous effectuez une mise à niveau dans votre environnement de développement. Exécuter une mise à niveau sur votre serveur de production est un suicide.
• Ne les laissez pas changer en production pendant la mise à niveau. Mettez votre Magento sous contrôle de version ou même des fichiers de verrouillage temporaires en écriture.
• Désactivez toutes les extensions tierces, mais notez celles qui ont été initialement désactivées afin de ne pas les activer par la suite.
• Vérifiez si un script de nettoyage Magento est en cours d'exécution sur le serveur. Sinon tronquer toutes les tables en commençant par dataflow_*, log_*, report_*.
• Revenir au thème par défaut lors de la mise à niveau.

Une fois le script de mise à niveau terminé:

• En faisant référence à ce que changes.txtvous avez fait avant de migrer, toutes les modifications dans le noyau qui méritent vraiment la migration.
• Migrer les app/code/local/Magemodifications trouvées avant la mise à niveau.
• Un par un, activez les extensions tierces.
• Remettez votre thème et comparez le résultat avec le serveur de production.
• Déployez en production une fois que vous êtes satisfait du résultat.

Conclusion

Je sais que tout cela semble effrayant, mais si vous effectuez régulièrement des mises à niveau, gardez votre noyau propre et installez des extensions uniquement auprès de fournisseurs en qui vous avez confiance et si vous en avez vraiment besoin, vous ne rencontrerez pas la plupart des difficultés décrites dans cet article. Gardez votre système Magento EcoSystem en bonne santé et vous serez récompensé.

Post Scriptum

Dans des cas très complexes, il est logique de tout recommencer avec une nouvelle installation de Magento, puis de migrer le thème et les fonctionnalités de votre magasin, étape par étape. Cela va certainement prendre du temps, mais à la fin, vous aurez un système Magento en bonne santé et pleinement conscient de ce qui se passe.

De manière générale, le code principal ne doit jamais être touché lors du développement. Il existe de nombreux mécanismes dans Magento pour vous permettre de contourner tous les problèmes, même les bugs internes. Cela étant dit, il y a d'autres problèmes à surveiller également.

1. Des modules de la communauté ou locaux remplacent-ils le code principal (peut être recherché dans le dossier modules <rewrite>, ce qui est une mauvaise pratique, car ils doivent utiliser un code non envahissant, tel que des événements)
2. Magento essaie de garder le code compatible avec les versions antérieures, mais parfois, le code change de manière significative ( peut être trouvé ici ), si les modifications incompatibles avec les versions antérieures sont nombreuses, cela pourrait ajouter du processus.
3. Est-il facile / possible de dupliquer le code dans un environnement de développement? si c'est le cas, il suffit d'exécuter la mise à niveau et les tests.
4. La mise à niveau est-elle nécessaire? La nouvelle version contient-elle des fonctionnalités que le client ne peut pas quitter? Tous les problèmes de sécurité (plusieurs fois, Magento fournit également des correctifs)

En ce qui concerne le modèle, d’expérience, je peux vous dire qu’il se casse à peine, à moins que le développeur ne soit fou du codage du modèle (qui devrait de toute façon être en blocs).

Voici quelques points à garder à l'esprit:

• Vérifiez si le thème est compatible (vérifiez si le codage est complet dans les fichiers de modèle - parfois les développeurs débutants le font)
• Vérifiez la manière dont le support est stocké (utilisent-ils des CDN, etc.)
• Vérifiez si des méthodes de cache spéciales sont en place (APC Memcached, etc.)

Une façon de traiter ce type de demande client consiste à effectuer une révision d'estimation.

Cela implique de dire au client que vous passerez un peu de temps (facturable) à le regarder et que vous lui donnerez un calendrier / coût plus précis pour la réalisation du projet.

En choisissant cette voie, vous et votre client profiterez.

Le client se sentira généralement plus confiant dans votre estimation et respectera vos recommandations, ce qui vous sera bénéfique en réduisant le stress possible.

Estimation de l'estimation:

L’examen de l’estimation réelle serait dans ce sens:

• Dump de la base de données live et importez-la sur une machine de développement
• Copiez les fichiers magento de leur machine live sur votre machine de développement
• Assurez-vous que tout va bien et fonctionne
• Essayez la mise à niveau et faites des tests initiaux pour voir ce qui pourrait se casser

Ce processus devrait prendre en moyenne deux heures facturables et vous donnera les informations nécessaires sur le système actuel.

Nous avons effectué diverses mises à niveau sur Magento CE, la pire étant passée de 1,3 à 1,7, ce qui nous a pris presque 4 jours complets. L'estimation initiale était de 1-2 jours. Je suppose que passer de la version 1.x à la version 2.x constituera une entreprise tout aussi gigantesque. Même si les outils de migration étaient fournis par l'équipe principale, il serait peut-être plus simple de tout recommencer à zéro.

Je veux ajouter une chose aux excellentes réponses données ci-dessus:

• Vérifiez si un VCS et un processus de déploiement approprié sont en place.

Je ne ferai pas de mise à niveau sans des processus appropriés et la possibilité de prendre du recul lorsque des problèmes surviennent (encore plus si je ne travaillais pas sur le site auparavant). Environ 90% des clients qui nous sollicitent pour une mise à niveau de Magento (qui n’avaient pas été nos clients auparavant) disposent uniquement d’un environnement en direct sans aucun test / transfert, ni aucun système VCS en place.

L'intégration avec d'autres entités est une question importante à poser. C’est quelque chose que vous ne pourrez peut-être pas remarquer en consultant le site. Il est courant par exemple que les clients demandent aux systèmes back-end de récupérer les commandes via l’API Magento, et si vous ne gérez pas la continuité de cette intégration lors de la mise à niveau. peut entrer dans un désordre.

Lorsque vous examinez des composants, recherchez ceux qui communiquent avec d'autres systèmes - chacun de ces composants sera difficile à tester, car vous ne souhaitez pas forcer accidentellement les données de test sur un système actif. Il existe souvent un noeud final de test utilisé par les développeurs d'origine, mais il est possible que vous ne disposiez plus de ces informations lors de la mise à niveau.