Magento2 - déploiement local / intermédiaire / de production et gitignore

11

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.sh

Nous 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:deploy

Infos 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?

Raul Sanchez
la source
Je vais dans le même sens: tout dans mon git repo. La machine de production n'a pas de compositeur donc il n'y a pas d'autre moyen pour moi. Puis-je vous demander comment vous gérez les référentiels .git dans le dossier du fournisseur? Lorsque je m'engage dans mon dépôt, ceux-ci sont considérés comme des sous-modules et ne se retrouvent donc pas dans mon dépôt.
omsta

Réponses:

18

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?

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:

  • Avoir des déploiements reproductibles , c'est-à-dire que vous devez être sûr que le même code se retrouve dans la production qui était en transit, y compris les fichiers générés .
  • 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'ajout vendorau 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 que composer.lockle dépôt)
    • Génération de code (YMMV):

      bin/magento setup:di:compile
      bin/magento setup:static-content:deploy
    • créer une archive (l' artefact de construction ) à partir du répertoire complet Magento, à l' exclusion mediaet var, mais y compris vendor, pub, var/generatedet var/di. A partir de , var/generatedet var/disont déplacés vers generated/codeet generated/metadata, ce qui le rend plus facile de les séparer du reste de ce varqui 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:

    • relier des répertoires persistants dans ce ( media, var/session, var/log, ...)
    • activer le mode de maintenance
    • changer la racine du document (généralement le docroot est un lien symbolique vers la dernière version, changez-le en la nouvelle version)
    • vider le cache
    • courir setup:upgrade
    • désactiver le mode de maintenance
  • Ce 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

  • Garder 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.

Fabian Schmengler
la source
Merci beaucoup Fabian ... Je cherchais quelque chose comme ça, car nous utilisons Capistrano dans Magento 1 et j'espérais trouver un outil similaire pour Magento 2 ... Je vais essayer pendant la semaine et vous donner plus de commentaires
Raul Sanchez
@ fabian-schmengler explique à peu près ce que nous faisons. Nous générons tout dans l'environnement de transfert et nous le testons en mode production, puis nous déplaçons le code généré de l'environnement de transfert vers l'environnement de production pour nous assurer que le code qui se termine dans l'environnement de production est exactement le même que celui que nous avons dans le transfert.
diazwatson
Merci pour l'explication. Ce serait bien d'avoir le contenu du fichier gitignore dans votre réponse.
Mehdi
@Mehdi, le .gitignorefichier n'est pas pertinent pour le problème réel. Vous pouvez simplement utiliser celui par défaut.
Fabian Schmengler
@FabianSchmengler, j'ai un problème similaire, toutes les modifications de validation de fichier se refléteront après chaque déploiement dans tous les systèmes, mais les paramètres de configuration d'administration que les configurations de thème ne refléteront pas, existe-t-il une solution pour éviter de configurer plusieurs fois les mêmes paramètres dans tout le système?
jafar pinjar
4

À 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.

Franck Garnier
la source