Meilleures pratiques pour le déploiement de Magento
je cherche à mettre en place un processus de déploiement pour un site Magento hautement personnalisé, et je me demandais comment les autres personnes font cela.
je vais mettre en place les environnements dev, UAT et prod. Tous les fichiers Magento seront dans le contrôle source (SVN). À ce stade, Je ne vois pas d'exigences pour changer la base de données, donc les 3 bases de données seront manuellement maintenues.
plus Précisément,
- Comment appliquer les mises à niveau Magento? (Individuellement dans chaque env, ou sur dev ensuite, rouler, ou tout simplement abandonner sur les mises à niveau?)
- ce que les fichiers / dossiers font laisser seul dans chaque environnement (par exemple magento/app/etc/local.xml)
- est-ce que vous limitez les développeurs à éditer des fichiers/dossiers spécifiques?
- est-ce que vous limitez les concepteurs de thème à éditer des dossiers/dossiers spécifiques?
- comment gérez-vous les changements de base de données?
Designer Thème Des Fichiers/Dossiers
les Concepteurs peuvent restreint à l'édition des dossiers suivants -
app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/
Extension Développeur Fichiers/Dossiers
les développeurs D'Extension peuvent éditer les dossiers/fichiers suivants -
/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml
gestion de L'environnement de la base de données
comme L'URL de base du magasin est stockée dans la base de données, vous ne pouvez pas simplement copier des bases de données entre des environnements. Les Options comprennent-
- outrepasser la base url en php. Blog article sur la mise en place de dev et la mise en scène les bases de données
- modification de l'url de base dans la base de données après copie. (Où est-ce stockées?)
- faire une sauvegarde ou une sauvegarde MySQLDump, puis faire un remplacement sur L'URL dans le fichier SQL.
5 réponses
Appliquer des mises à jour: Faire le dev. Créez une branche (c'est ici que git brille vraiment), appliquez les fichiers patch ou encore mieux, déballez une nouvelle version Magento et pointez-la sur votre ancienne base de données. Pas encore d'extensions. Ouvrez l'administrateur dans la nouvelle installation de Magento un espoir pour le meilleur. Mise à jour entre les versions mineures ne sera probablement pas un problème. Vous aurez probablement à réindexer après toutes les nouveautés installe. Faites un commit une fois que celui-ci est stable, puis apportez graduellement dans la branche vos extensions et vos thèmes, faites des ajustements de code, puis faites un commit après chaque étape s'avère stable.
dépendant de l'Environnement des fichiers: .htaccess et app/etc/locale.XML. Je fais une version distincte pour chaque: local.dev.xml, htaccess-dev local.Staging.xml, htaccess-mise en scène local.production.XML, htaccess-production
...et ensuite leur faire des liens doux pour chaque environnement:
ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml
et ainsi de suite.
Restreindre l'accès à certains développeurs: je ne peux pas faire cela. Cependant, vous pouvez développer une stratégie de déploiement en git qui permet à un responsable de publication de décider ce qui entre et ce qui ne va pas.
Gestion des modifications de base de données: C'est la partie la plus délicate. Nous utilisons juste mysqldump de la production, et avons quelques prêts à l'emploi "env-setup.fichiers sql" pour chaque environnement. Quelque chose comme ceci (votre id peut varier):
UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4);
j'ajoute habituellement d'autres instructions qui modifieront les passerelles de paiement pour tester les environnements, modifier les e-mails sortants, etc. La plupart d'entre eux se trouvent dans core_config_data.
rappelez-vous que les modules font généralement leurs propres modifications à la base de données, donc appliquer un module bien fait prend généralement soin de lui-même. Dans tous les cas, n'appliquez jamais de modifications non testées à prod, faites toujours "répétitions" sur des environnements locaux et de mise en scène.
vous pouvez extraire les données CMS (pages et blocs statiques) de la base de données en déchargeant et en chargeant uniquement les tables cms_* à partir de n'importe quel environnement sur lequel le développement a été fait.
Bonne chance!
j'utilise les mêmes bonnes pratiques que pour toute application web tout en développant magento. J'évite aussi religieusement d'apporter des modifications aux fichiers de base (de nombreux documents sur le wiki magento vous demandent de modifier les fichiers de base).
j'utilise git pour gérer tous mes projets et déploiements Magento. Il est beaucoup plus facile de fusionner de nouvelles versions, surtout si vous utilisez le miroir Magento que je maintiens sur github. ()
en ce qui concerne votre question spécifique sur l'endroit où l'url de base est stockée dans la base de données, essayez ceci:
SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url";
vous pouvez éviter la Manipulation DB (en allemand)): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html
après beaucoup d'essais et d'erreurs, nous avons trouvé un flux de travail qui nous convient bien:
http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git
inclut la gestion de base de données, tout le code sous contrôle source (avec Git), les déploiements, les sites de mise en scène et de développement, les développeurs multiples, les environnements multiples, etc...
J'espère que cela aidera quelqu'un!