Conférence Développeurs Magento. 27 novembre 2013 mageconf.org

Transcription

1 Conférence Développeurs Magento 27 novembre 2013 mageconf.org

2 Montée de version de Magento : la préparation, les étapes, les pièges à éviter Par Sébastien Lepers (SeL)

3 Montée de version : le contexte» S E-commerce : suivre (ou devancer) les tendances Version vieillissante Nouvelles fonctionnalités / améliorations» G Nécessité technique Correction de bugs Compatibilité avec d'autres bibliothèques / extensions»!risques commerciaux

4 Historique des versions de Magento CE EE PE RIP => Possibilités multiples de changement de version / édition

5 Anticipation»Version source / Version cible?»édition?» Principales différences & impacts?» Versions des modules communautaires utilisés?»qualité du code spécifique?»niveau de respect des bonnes pratiques? o N

6 La préparation : organisation» Versionning de sources (Git-+) Création d'une branche pour la migration» Récupération des archives de sources de Magento et des modules communautaires Downloader

7 La préparation : analyse de l'existant»code source modifié? app/code/core app/code/community lib js» Comparaison avec les sources de la version d'origine

8 La préparation : fusion des sources» Remplacement des sources Magento (core/libs/...)»! Attention à l'utilisation du glisser/déposer Risque de laisser des surcharges obsolètes»g Étape par étape» Recommandé pour les répertoires sans code spécifique : Suppression du répertoire Copie du répertoire de la nouvelle version

9 -- app --.htaccess -- Mage.php -- code -- community -- Find `-- Phoenix -- core -- Mage `-- Zend `-- local -- design -- adminhtml -- default `-- mydesign Dans le cas d'un design de BO spécifique -- frontend -- base `-- mydesign `-- install -- etc `-- modules `-- locale -- en_us `-- fr_fr Légende : Peut-être supprimé dans la plupart des cas Suppression / remplacement par la nouvelle version Fusion existant <> nouvelle version Mise à niveau -- downloader -- errors -- mydesign/* Dans le cas d'un design spécifique au projet `-- default/* php php -- default -- design.xml -- local.xml -- local.xml.sample -- processor.php `-- report.php Supprimer les fichiers de déclaration des modules supprimés dans la nouvelle version Remplacer par la version correspondante du module de traduction FR communautaire

10 -- includes -- js -- calendar -- extjs -- flash -- jscolor -- lib -- mage -- prototype -- scriptaculous -- tiny_mce -- varien `-- [...] -- lib -- 3Dsecure -- flex -- googlecheckout -- LinLibertineFont -- Mage -- PEAR -- phpseclib -- Varien -- Zend `-- [...] -- media -- pkginfo -- shell -- skin -- adminhtml -- mydesign/* Dans le cas d'un design de BO spécifique `-- default -- frontend -- base -- mydesign/* `-- default `-- install `-- var -- backups -- cache -- locks -- log -- report `-- session.htaccess index.php cron.php cron.sh get.php Toute autre bibliothèque JS d'une version spécifique de Magento Toute autre bibliothèque PHP d'une version spécifique de Magento Légende : Peut-être supprimé dans la plupart des cas Suppression / remplacement par la nouvelle version Fusion existant <> nouvelle version Mise à niveau

11 La préparation : modules communautaires» Mise à jour des sources des modules complémentaires Module de paiement Module de livraison Traduction...»Mêmes recommandations que pour la fusion des sources Magento»Vérifier si les sources du module n'ont pas été modifiées lors des développements (mauvaise pratique très courante)

12 La préparation : thèmes» Fusion entre les templates / layouts» Nouvelle version du Thème de base vs Thème spécifique Mise à jour des appels à des méthodes/blocks/models obsolètes Améliorations Nouvelles fonctionnalités dans des templates existants dans la version antérieure»thèmes : Frontend Adminhtml (peu courant) Errors (souvent oublié...)

13 La préparation : BDD» Toutes les données sont-elles indispensables?»par exemple, les tables : report_compared_product_index? report_viewed_product_index? log_*?»les vider avant la migration peut faire gagner en stabilité et en temps d'exécution des scripts d'upgrade Alternative à la suppression des données : dump avant migration + import après.» BDD volumineuse et temps d'upgrade longs? Testez Magento-Upgrade-Replay :

14 La préparation : mise en maintenance < v 1.4.htaccess : filtrage sur IP lors de la migration Préparation d'une page de maintenance statique (HTML/CSS) >= v 1.4 Utilisation du fichier maintenance.flag : errors/default/503.phtml

15 La préparation»ce1.8 ou EE1.13 : upgrade spécifique :

16 Répétition générale»copie de la BDD de prod» T Mesure du temps d'exécution des scripts d'upgrade»! Volume de données Catalogue Clients Commandes» Anticipation des problèmes»préparer le rollback en cas de gros problème -

17 Le jour J»Tout est prêt? Équipe au taquet Client et internautes prévenus d'une coupure de quelques minutes / heures...»go!

18 Site accessible par tous Le jour J : H0»Copie de toutes les sources de la nouvelle version sur le serveur (dossier séparé : 'monsite.new')»copie des médias» Copie du fichier app/etc/local.xml modification temporaire du nœud XML : <initstatements>set NAMES utf8; SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;</initStatements>» Préparation du.htaccess pour restreindre l'accès

19 Site complètement inaccessible Le jour J : H + 30min» Mise du site en maintenance (.htaccess)»sauvegarde de la base de données»copie de cette sauvegarde en lieu sûr e»vider les tables : report_compared_product_index? report_viewed_product_index? log_*?» Renommage de l'ancien répertoire racine du projet Magento : par ex : monsite -> monsite.back» Renommage du nouveau répertoire avec le nom de l'ancien répertoire : par ex : monsite.new -> monsite

20 Site complètement inaccessible Le jour J : H + 1»Vider les dossiers : var/cache/ var/full_page_cache/»exécuter le premier appel à l'application, de préférence en ligne de commande : $ nohup php index.php > var/log/upgrade.log & R... Patienter jusqu'à la fin de l'exécution des scripts d'upgrade : Quelques minutes ou quelques heures en fonction de la volumétrie de la BDD (et de l'écart de versions)

21 Site publiquement inaccessible Site accessible par tous Le jour J : H + 2» Modification du fichier app/etc/local.xml Remettre le nœud XML initstatements à sa valeur d'origine : <initstatements>set NAMES utf8;</initstatements>» Ouverture de l'accès au site pour l'équipe interne» Contrôle général du site»tout est OK? 8 Ouverture au public! Modification du htaccess ou suppression du fichier maintenance.flag»! Suppression des fichiers de log, archives de livraison, données sensibles...

22 En cas de problème»malgré tout le soin apporté, ça a foiré?»remise en place du dossier initial : par ex : monsite -> monsite.bad et : monsite.back -> monsite»import de la base de données dans son état initial» Réouverture du site dans son état initial» Analyse des problèmes rencontrés (logs,...)» Déterminer la cause» Revoir la préparation de la migration

23 Conclusions»! Adapter la méthodologie proposée aux spécificités de votre projet (hébergement, cache,...)» Importance du respect des bonnes pratiques : Ne pas toucher au core Ne pas toucher aux sources des modules communautaires! Limiter l'utilisation des rewrites Limiter la duplication de templates Réserver l'utilisation des surcharges dans app/code/local/mage aux corrections de bugs du core» Magento 2 simplifiera ce process douloureux Un unique répertoire pour toutes les ressources d'un module (PHP, layout, templates, CSS, images,...)» Possibilité d'améliorer : Contrôler les violations de contraintes de clés étrangères

24 Des questions?

25 Merci! Présentation à retrouver sur :