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

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

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

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

2. Créez un projet en utilisant la commande suivante:

   composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .

3. 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)

4. Initialiser le nouveau référentiel git à la racine du projet
5. Ajouter tous les fichiers non suivis à git et les valider
6. 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

1. Assurez-vous que toutes les autorisations du système de fichiers sont définies comme indiqué dans le guide officiel

2. 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 \ [email protected] \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1

3. Activer le travail cron des indexeurs, par exemple sur Ubuntu:

   echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -

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

5. [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

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.

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.

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)

1. effacer var/cache
2. effacer var/view_preprocessed
3. supprimer pub/static/*(ne pas supprimer le .htaccess)
4. effacer var/composer_home
5. courir php bin/magento cache:flush
6. courir php bin/magento setup:static-content:deploy %your_languages%
7. supprimer tous les thèmes / langues que vous n'utilisez pas actuellement de pub / static / frontend
8. supprimer les copies papier de moins de fichiers de pub/static/frontend
9. 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
10. 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
11. courir grunt less:your_theme

étapes de backend / di-setup

1. effacer var/cache
2. effacer var/generation
3. effacer var/composer_home
4. effacer var/di
5. courir php bin/magento cache:flush
6. courir php bin/magento setup:di:compile

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