Cela pourrait être un type de discussion plus qu'une question.
Je voudrais savoir quelle politique de déploiement vous suivez avec Magento2 et local > staging > environnements de production
Après quelques essais, nous avons décidé que la meilleure approche (ou du moins la plus solide) serait ce fichier gitignore, y compris le dossier du fournisseur dans git.
.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess
/var/*
!/var/.htaccess
.unison*
/sync.shNous exécutons donc composer uniquement dans un environnement local: comme toute nouvelle extension ou mise à niveau logicielle est testée en local, puis validée et validée. Nous inclurions probablement le fichier app / etc / config.php dans git aussi, mais ce fichier est réécrit lors de l'exécution setup:upgrade, non?
Inclure le fournisseur signifie que la taille du référentiel sera plus grande que (peut-être) recommandée, mais de cette façon lors du déploiement de code, nous exécutons simplement la séquence:
bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deployInfos connexes: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2
Voyez pourquoi nous choisissons la commande de compilation comme Magento 2 facultatif - setup: di: compile ?
MISE À JOUR
La vérité est que nous rencontrons des problèmes lors du déploiement de modifications de code dans nos projets Magento 2 publiés
Les changements fonctionnent en local et en staging (vérifié dans les deux modes: développeur et production ... bien que nous configurions conceptuellement ces environnements en mode développeur), mais certains d'entre eux ne fonctionnent pas en environnement de production (en mode production), etc ... je ne suis donc pas sûr que nous suivions la bonne stratégie. J'aimerais voir quelle est la séquence de commande appropriée et la pertinence de l'ordre dans lequel les commandes
En fait, chaque jour, je suis moins convaincu de l'utilité du mode de production de Magento 2, sauf si vous n'allez rien changer dans le projet. Pouvez-vous changer d'avis?
la source
Réponses:
Je ne sais pas si je vous comprends bien, mais c'est exactement à cela que sert le mode de production : des systèmes de production où vous ne changez rien (au niveau du code). Jusqu'au prochain déploiement, bien sûr.
Je trouve que le déploiement basé sur Git que vous utilisez est moins adapté à Magento 2 qu'il ne l'était pour Magento 1, à cause de tout le prétraitement. La construction et le déploiement sont plus complexes et à mon humble avis, il n'y a aucun moyen de contourner un processus de construction automatisé
Ce que je recommanderais:
Pour ce faire, séparez la génération du déploiement et procédez comme suit dans le processus de génération:
composer install(l'ajoutvendorau référentiel à la place est également possible, mais si vous l'avez fait juste pour éviter d'exécuter composer sur le serveur pendant le déploiement, faites-le plutôt à l'étape de construction et ne conservez quecomposer.lockle dépôt)Génération de code (YMMV):
créer une archive (l' artefact de construction ) à partir du répertoire complet Magento, à l' exclusion
mediaetvar, mais y comprisvendor,pub,var/generatedetvar/di. A partir de magento-2.2 ,var/generatedetvar/disont déplacés versgenerated/codeetgenerated/metadata, ce qui le rend plus facile de les séparer du reste de cevarqui devrait être ignoré pour les déploiements.Dans le déploiement, copiez l'artefact de génération sur le serveur cible, extrayez-le dans un nouveau répertoire et:
media,var/session,var/log, ...)setup:upgradeCe processus de déploiement peut être facilement implémenté avec Deployer , qui est comme Capistrano mais en PHP. Une solution de déploiement complet pour Magento 2 basée sur deployer peut être trouvée ici: https://github.com/mwr/magedeploy2 (grâce à netz98!) Et en voici une autre que nous utilisons: https://github.com/staempfli / magento2-deployment-tool
app/etc/config.phpdans le référentiel est bon pour garder une trace des modules activés et désactivés.Ce n'est pas une instruction étape par étape, mais elle devrait vous donner un aperçu d'une alternative plus robuste à votre processus actuel. Jetez un œil aux outils liés pour voir à quoi pourrait ressembler une solution complète.
la source
.gitignorefichier n'est pas pertinent pour le problème réel. Vous pouvez simplement utiliser celui par défaut.À mon avis, attendez Magento 2.2 ou essayez de mettre en œuvre une approche similaire.
Magento 2.2 introduit le déploiement de pipeline en séparant par exemple le serveur de build du serveur de production.
Voici la documentation officielle: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/
De plus, j'utilise actuellement Ansible pour gérer un déploiement automatisé avec des modèles de configuration et une configuration d'environnement multiple.
la source