GIT et stratégie de déploiement des projets Magento2

92

Avec Magento 1, j’utilisais un outil de déploiement qui intégrait le dépôt GIT, exécutait des commandes telles que modman deploy-allet s’assurait que le varrépertoire était accessible en écriture. Pour le .gitignorej'ai utilisé celui-ci qui a plutôt bien fonctionné.

Mais qu'en est-il de Magento 2 ?

Qu'est-ce qui fonctionne le mieux avec gitignore, comment déployez-vous votre projet et quelle commande doit-on exécuter avant et après le déploiement? Au plaisir d'entendre quelques idées de la communauté.

La question restera ouverte pendant un certain temps

magento2

— Sander Mangel
source

Bonne question @sander Mangel

— Amit Bera

1

Par définition, il ne peut y avoir de réponse canonique à cette question, elle est donc probablement trop large et également mal adaptée à la nature des questions-réponses du site. Devrait probablement être méta. Mais vous le savez déjà. Cela dit, je le laisserai jusqu'à l'expiration de la prime.

— philwinkle

@philwinkle, il pourrait être large mais apparemment pas trop large puisque déjà 3 réponses ont été données. Comme discuté ici: meta.magento.stackexchange.com/questions/745/… Meta doit être utilisé pour des questions sur MageSE, pas pour des publications aléatoires / des questions. Si vous souhaitez le supprimer, je ne peux pas vous arrêter, mais il semble que beaucoup de les gens sont intéressés par la question et à mon avis, c'est une question valable, que ce ne soit pas trop spécifique.

— Sander Mangel

Deux choses: d' abord, Sander est correct sur Meta - il doit seulement être utilisé pour des questions sur la plate - forme S'en ce qui concerne Magento SE (NB: nous avons peut - être pas assez bien policée Meta pour renforcer cette règle). Deuxièmement, "beaucoup de gens [étant] intéressés par" une question n'a aucun rapport avec le fait de savoir si une question peut recevoir une réponse canonique ou non (et donc avec l'adéquation d'une question au format StackExchange). C'est frustrant à coup sûr (je me suis heurté à cela moi-même). Je suis enclin à voir où ce fil Q / A va. Peut-être qu'un A peut être assez bien déclaré pour être exclusivement "correct" ...

— benmarks

@benmarks dans ce cas, j'ai choisi la raison ou le sujet de la prime, mais ma motivation était de récompenser celui qui prenait le temps d'écrire une réponse complète à cette question. Si ce fil n'appartient pas à cet endroit, je le copierai et le posterai quelque part en ligne, en créditant les auteurs, car j'estime qu'il a toujours de la valeur. S'il vous plaît, informez-moi si avant de supprimer

— Sander Mangel

56

Les étapes ci-dessous décrivent comment configurer l'environnement pour le développement de modules personnalisés et non pour la production.

Initialisation du projet

Ajoutez les informations d'identification repo.magento.com et le jeton d'accès github à auth.json dans le répertoire de base du compositeur
Créez un projet en utilisant la commande suivante:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
Prenez ce .gitignore et mettez-le dans la racine de votre projet. Presque tous les fichiers / répertoires principaux sont déjà ajoutés à la racine .gitignore, mais il est préférable d’ajouter également les 2 suivants /updateet /phpserver(ajoutez simplement ces 2 lignes à .gitignore)
Initialiser le nouveau référentiel git à la racine du projet
Ajouter tous les fichiers non suivis à git et les valider
Commencez le développement de vos modules comme d'habitude (mettez-les sous app/code/VendorName/ModuleName), vous n'aurez plus que votre code personnalisé dans votre dépôt git

Installation de Magento

Assurez-vous que toutes les autorisations du système de fichiers sont définies comme indiqué dans le guide officiel
Installez Magento en ligne de commande, par exemple:

${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1
Activer le travail cron des indexeurs, par exemple sur Ubuntu:

echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -
Magento fonctionnera en defaultmode et tout le contenu manquant sera généré automatiquement à la première demande. Donc, pas besoin d'exécuter le compilateur ou le déploiement de contenu statique
[facultatif] Si vous utilisez PHP Storm, exécutez la commande suivante pour activer le support XSD:

bin/magento dev:urn-catalog:generate .idea/misc.xml

— Alex Paliarush
source

Salut Alex. Étape 3 d'initialisation du projet - pourriez-vous l'étendre un peu? Avez-vous trouvé que vous deviez copier manuellement ce sous-répertoire dans la racine? (Je me demande si quelque chose ne fonctionne pas correctement - je ne m'attendais pas à cette étape.)

— Alan Kent

@AlanKent vous obtenez actuellement tous les fichiers liés à Magento téléchargés vendor, y compris magento2-base, ce qui n'est qu'un squelette pour un nouveau projet. Vous ne savez pas pourquoi cette étape n'est pas configurée pour être effectuée automatiquement par le compositeur, tentera de le savoir. En ce qui concerne la .gitignorecopie à partir d'un autre référentiel, il est déjà question de la manière d'éliminer / simplifier cette étape.

— Alex Paliarush

L'étape 3 n'est pas requise. Le marshaling des fichiers / dossiers est effectué à l’étape 2.

— Maddy

Merci @Maddy. @AlanKent, la copie magento2-baseà la racine n'est plus nécessaire (juste vérifiée), semble avoir été corrigée récemment. Supprimé cette étape de la réponse.

— Alex Paliarush

1) Je mets tout mon code sur le repo, déjà non installé et tout, quand je tire de ce repo et que je modifie les paramètres de l'administrateur pangel et des informations d'identification de la base de données, tout fonctionnera-t-il correctement? 2) depuis que j'ai oublié d'exclure var / et pub / folder pendant le push, puis-je les supprimer complètement, afin qu'ils puissent supprimer sur le repo distant, vont-ils se régénérer? Merci.

— Lachezar Raychev

25

Pour l’initialisation et l’installation, suivez les étapes de la réponse d’Alex pour la plupart des étapes. Seules les différences que je recommanderais:

Configuration Git

Ne stockez que les fichiers suivants dans votre référentiel Git:

composer.json
composer.lock
app / etc / config.php

Pour le code personnalisé de votre projet, utilisez également des modules distincts que vous incluez dans composeur. La gestion de ce composeur est plus facile car vous pouvez verrouiller une version / version spécifique que vous souhaitez déployer. Cela vous oblige également à utiliser la même approche pour les modules internes et externes.

Déploiement

Pendant le développement, vous mettez à jour les modules de votre environnement (dev / test) avec la commande:

composer update

Cela mettra à jour le fichier composer.lock avec les versions installées sur cette installation.

Lors de la préparation, de la pré-production et de la production, vous pouvez créer / installer la même configuration à l’aide de la commande suivante:

git pull
composer install

Ceci installera tous les mêmes modules que ceux utilisés dans dev / test pour garantir que les tests avant la publication en production sont effectués avec les mêmes versions de module que celles avec lesquelles il a été développé.

Après l'installation, exécutez les commandes suivantes:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Cela mettra à jour la base de données (mise à niveau du schéma et des données), générera la configuration DI et déploiera tous les fichiers de vue statique.

— Vladimir Kerkhoff
source

Peut-être qu'il serait judicieux d'utiliser des exemples de données au lieu de générer des fixtures? Les projecteurs ne peuplent que les modules les plus critiques et semblent être utiles uniquement pour les tests de performance.

— Alex Paliarush

Merci d'avoir supprimé cette partie, car elle n'est pas nécessaire pour utiliser un site en production.

— Vladimir Kerkhoff

Cela suit de très près l'approche que j'utilise également. Cela fonctionne aussi bien avec Magento 1 également (avec un processus de construction moins complexe). Laissez mon compositeur faire son travail, cela fonctionne très bien pour les déploiements selon mon expérience, et nous n’avons pas vu beaucoup d’inconvénients autres que la complexité de la stratégie .gitignore ne suivez pas l'empreinte plus petite dans git.

— Aepod

Cette installation ressemble à la méthode "intégrateur". Il ajoute les dépôts dans vendor / magento / *. Aucun code ne sera dans app / code / .. ni dans d'autres répertoires. Comment aurais-je les répertoires principaux de Magento 2 comme dans l’archive .zip? Est-il possible d’ajouter via le composeur un module (autre git repo) et de se retrouver automatiquement dans app / code / ...?

— obscure

4

risqué, composer n'est pas un outil de déploiement. si quelque chose ne fonctionne pas sur l'installation du compositeur lors de l'exécution en production ...

— Claudiu Creanga

3

Encore une fois, la réponse officielle de Magento 2.2 sera "config.php va dans git, env.php ne le fait pas".

Nous examinons des plugins de composition tels que Mediawiki pour rapprocher les développeurs internes du développement d’extensions et des sites clients. Encore à explorer, pas encore définitif.

J'aimais bien utiliser le type de référentiel Composer "Path" avec un chemin ../othergitrepo/app/code/*/*permettant de récupérer les modules, mais il utilise des liens symboliques qui ne fonctionnent pas très bien avec les environnements de développement utilisant Unison ou similaire.

— Alan Kent
source

3

nous utilisons une approche différente qui ne nécessite pas un processus / serveur de construction séparé , nous développons localement comme si nous étions en production

nous validons ensuite tous les fichiers nécessaires à la production . nous déployons ensuite simplement les changesets sur le serveur et exécutons la commande upgrade.

arriver à une version qui convient au développement mais qui fonctionne aussi en mode de production était la partie la plus délicate et n’était toujours pas parfaite, mais nous avons maintenant une recette qui fonctionne.

La raison en est que nous voulons avoir un contrôle à 100% sur le code utilisé pour la production. Puisque magento2 génère une tonne de code, nous devons l'exécuter localement pour pouvoir comprendre tous les effets et pouvoir déboguer comme si c'était en production.

Je suis conscient que ce n'est pas ce que beaucoup de gens recommandent de faire, mais pour nous, cela fonctionne mieux.

étapes d'installation frontale

Pour que ces scripts fonctionnent, réglez votre boutique en mode de production dans votre env.php et configurez votre thème dans dev/tools/grunt/configs/themes.js. (les étapes suivantes ont été placées dans un livre de jeu ansible)

effacer var/cache
effacer var/view_preprocessed
supprimer pub/static/*(ne pas supprimer le .htaccess)
effacer var/composer_home
courir php bin/magento cache:flush
courir php bin/magento setup:static-content:deploy %your_languages%
supprimer tous les thèmes / langues que vous n'utilisez pas actuellement de pub / static / frontend
supprimer les copies papier de moins de fichiers de pub/static/frontend
courir php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
facultatif: nous utilisons un script bash pour changer les liens symboliques absolus créés à l'étape 9 en liens relatifs, ce qui permet d'exécuter grunt de l'extérieur de la machine virtuelle
courir grunt less:your_theme

étapes de backend / di-setup

effacer var/cache
effacer var/generation
effacer var/composer_home
effacer var/di
courir php bin/magento cache:flush
courir php bin/magento setup:di:compile

— greenone83
source

Merci pour cette @ greenone83, c’est l’approche que j’ai adoptée, bien que je génère mon backend dans le cadre du front-end. Je n'ai jamais utilisé setup: di: compiler car je trouve que ça bousille! Une chose que je ne comprends pas, c’est pourquoi la configuration: static-content: deploy crée des fichiers dans le code généré / (l’emplacement a été modifié depuis votre publication)? J'ai constaté que si je supprime tout le code généré /, lorsque mon site est en mode de production, ces fichiers sont automatiquement créés lorsque je navigue sur le site.

— PedroKTFC

2

Vous devez également ignorer ces fichiers
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

— Mrtuvn
source

2

Si vous ignorez le fichier config.php, vous devrez réactiver la nouvelle extension après le transfert vers un autre environnement. Il est donc préférable de l'inclure dans votre référentiel.

— Vladimir Kerkhoff