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

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?

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 magento-2.2 , 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.

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