Processus de déploiement de Magento 2

8

Actuellement, nous nous engageons composer.lockdans le référentiel, puis nous exécutons composer install --no-devsur le serveur de production. Je ne pense pas que ce soit la meilleure façon de le faire car il faut quelques minutes au compositeur pour générer tous les fichiers et c'est risqué.

Je me demande s'il est préférable de valider le dépôt tous les fichiers nécessaires pour fonctionner en mode production.

Comment les autres gèrent-ils le processus de déploiement avec magento 2?

magento2 composer deployment Claudiu Creanga
la source
Pourquoi est-ce risqué? Cela ne doit être fait qu'une fois par installation / configuration, et une fois que composer a téléchargé un package, il est mis en cache.
user3668514
peut-être que je manque quelque chose, mais si vous n'avez pas le dossier du fournisseur dans le référentiel, comment installeriez-vous de nouveaux modules sans exécuter composer installen production? letscodejavascript.com/v3/blog/2014/03/the_npm_debacle
Claudiu Creanga
Le point est de courir composer install. Avez-vous cherché un crochet git pour automatiser le processus?
user3668514
@ user3668514 que se passe-t-il si, lorsque vous exécutez l'installation de composer en production, certains packages distants sont arrêtés, comme cela s'est produit avec npm?
Claudiu Creanga
à quelle fréquence cela se produit-il? Magento2 est désormais livré avec un .gitignore qui ignore explicitement / vendeur entre autres. Comme il s'agit de la nouvelle `` méthode Magento '', je la suis pour que d'autres développeurs puissent travailler sur le projet sans problème
user3668514

Réponses:

5

D'accord à 100% avec claudiu-creanga pour ne pas engager le vendeur et éviter également d'exécuter l'installation du compositeur en production.

La façon dont nous avons géré cela est d'avoir un dossier actif et un dossier de version candidate. C'est dans le dossier release-candidate que nous exécutons les commandes git pull et composer install --no-dev. Notre processus peut se résumer ainsi:

  1. Dans le dossier de version candidate:

    • Vérifier les changements inattendus
    • Mettre à jour le référentiel
    • Installation du compositeur

  2. Synchroniser les fichiers avec le dossier du site en direct

  3. Dans le dossier du site en direct:
    • Déployer des fichiers statiques
    • Activer le mode de maintenance
    • Activer les modules
    • Exécuter des scripts de configuration
    • Compiler DI
    • Vider le cache
    • Désactiver le mode de maintenance
    • Mettre à jour les autorisations

J'ai écrit un article de blog plus long donnant les commandes et le raisonnement réels derrière cela: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

MISE À JOUR: Nous copions maintenant la base de données en direct dans une base de données intermédiaire et nous l'utilisons pour exécuter des scripts de configuration, déployer des fichiers statiques et compiler DI tous hors ligne. Cela peut ensuite être déployé pour vivre, y compris les fichiers pub / statiques et var. Nous supprimons encore brièvement le site si des scripts de configuration sont en cours d'exécution, mais sinon le site est laissé en place. Plus de détails sur https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

MISE À JOUR: J'ai changé d'avis sur la validation du dossier du fournisseur - en validant le dossier, vous avez la possibilité de suivre l'historique de la façon dont ces fichiers changent, voyez si vous avez accidentellement changé quoi que ce soit, et surtout, vous évitez d'avoir à exécuter le compositeur au moment du déploiement. Ce dernier est vital maintenant que nous comptons sur des fournisseurs externes de référentiels. Et si l'un d'eux n'est pas disponible? Soudain, vous ne pouvez pas vous déployer. Les inconvénients sont un plus grand référentiel, le risque de commettre des hacks de base et la méfiance instable des développeurs comme moi :)

Robert Egginton
la source
Nous avons également commencé à valider app / etc / config.php. Ceci est par défaut ignoré par .gitignore de Magento 2, mais en validant cette activation et désactivation se fait pendant le développement et cette décision est ensuite validée et peut être propagée et testée via CI.
Robert Egginton
Vous mettez sérieusement votre site hors ligne? Ce n'est pas une option pour nous. Notre entreprise
gagne de l'
À l'heure actuelle, oui, nous mettons brièvement les sites hors ligne car nous ne sommes pas sûrs à 100% que les utilisateurs ne verront pas un site partiellement opérationnel. Grâce à notre plus grande expérience de M1, nous savons avec un haut degré de certitude quels changements peuvent se produire sans arrêter le site. Pas encore avec M2.
Robert Egginton du
Voté. Cependant, comme @TheBlackBenzKid, j'aimerais voir quelque chose qui ne met pas votre site Web hors ligne, d'autant plus que la compilation DI prend un peu de temps. Je pense que comprendre ce que fait la compilation DI est essentiel - ce serait formidable si cette étape pouvait être effectuée dans le dossier de version candidate. Entre-temps, des progrès depuis que vous avez publié ce @Robert?
Erfan
1
Édition intéressante @RobertEgginton - J'explore actuellement cela et j'ai suivi vos messages et vos discussions. Je partage les réserves concernant l'utilisation de composer au moment du déploiement et l'inaccessibilité potentielle des référentiels tiers, bien que je suppose que cela ne pose pas moins de problème avec les référentiels packagist. La validation de ./vendor semble également loin d'être idéale, mais au moins elle vous donne une version complète qui peut être déployée indépendamment des référentiels tiers. Avez-vous essayé l'extension Capistrano Magento2? Cela utilise l'installation du compositeur mais j'aime le workflow de cap github.com/davidalger/capistrano-magento2
BlueC
3

Jusqu'à présent, nous validons également le dossier du fournisseur, qui bien sûr ajoute beaucoup de fichiers à votre référentiel. (Assurez-vous de supprimer tous les dossiers .git dans les fichiers du compositeur du fournisseur, sinon le contenu des dossiers ne sera pas validé - firegento par exemple). Mais la liaison symbolique du dossier du fournisseur ne fonctionne pas, la modification du chemin dans le fichier vendor_path.php ne fonctionne pas non plus et nous n'avons pas eu le temps de chercher une meilleure solution jusqu'à présent.

Nous n'avons pas de serveur de build et nous n'exécutons pas Composer sur le serveur, nous exécutons et testons toutes les mises à jour localement et les validons. Cela déclenche à son tour notre script de déploiement.

Notre script de déploiement remplace le fichier env.php, effectue quelques opérations personnalisées, puis déclenche également setup:upgradeet setup:static-content:deployavant de basculer le lien actif vers le nouveau dossier.

Le seul dossier que nous lions symboliquement est pub / media.

tecjam
la source
merci pour l'entrée. en plus de changer l'env.php, quels autres changements souhaiteriez-vous apporter?
Claudiu Creanga
Tout cela dépend de votre propre serveur et de la configuration du projet, je suppose. Pour les branches dev & staging, nous supprimons également le .htaccess et copions nos propres fichiers .htaccess & htpassword dans le répertoire, nous nous assurons que bin / magento est exécutable juste à titre de précaution avant d'exécuter des commandes cli dessus, ce que nous nous assurons nous courons en tant que propriétaire du fichier magento (l'utilisateur de déploiement est root) et nous lions le dossier multimédia dans le dossier pub. Bien sûr, vous pouvez également ajouter autre chose que vous préférez faire lors du déploiement plutôt qu'avant.
tecjam
La validation de fichiers dans / fournisseur est généralement déconseillée car elle va à l'encontre de l'objectif d'un gestionnaire de composants. Voir la documentation du compositeur.
user3668514
C'est clair. Alors, comment gérez-vous votre déploiement?
tecjam
1
Attention @ user3668514 - Je pense que vous voulez dire l'installation du compositeur. Il est facile d'exécuter accidentellement une mise à jour et de modifier réellement des composants plutôt que de les installer.
Robert Egginton
2

Enfin, nous avons opté pour un service comme deploybot( http://deploybot.com/ ). Vous pouvez utiliser capistranoce qui est gratuit. Deploybot crée un conteneur Docker pendant que l'installation de Composer est en cours d'exécution et si la commande réussit, il déploie le code, sinon il ne déploiera rien pour que votre environnement de production soit sécurisé.

Je considère que c'est la meilleure approche car:

1) avoir le dossier vendeur dans votre dépôt git n'est pas recommandé par les compositeurs pour de bonnes raisons: 

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Plus d'informations: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) L'exécution composer install in productionsans filets de sécurité est risquée , les packages peuvent être en panne (voir npm), vous pouvez rencontrer des problèmes de mémoire ou toute erreur qui pourrait se produire pendant que le compositeur génère des fichiers et vous devrez faire face à un environnement de production cassé.

Claudiu Creanga
la source
1

J'examine également la question, l'approche que j'ai adoptée jusqu'à présent est la suivante:

Amorçage du serveur:

  1. Configurez le projet avec composer --create-project ... --no-devdans un srcdossier (même si je vois encore beaucoup de dev cruft à travers)
  2. Application de configuration, compilation de fichiers statiques, mise à niveau de base de données, etc.
  3. Définissez toutes les autorisations correctes

Ce qui me donnera un stock, un magasin en cours d'exécution à partir de mon répertoire src (mais mon webroot ne pointe pas là)

Ensuite, mon processus de déploiement:

  1. Créer un nouveau dossier de version
  2. rsync les fichiers src dans ma version (à l'exclusion du cruft)
  3. déployer et décompresser mes personnalisations par-dessus (une poignée de fichiers de thème et de modules)
  4. installer tous les modules magento tiers via magento connect
  5. pointer mes hôtes webroot vers ma nouvelle version (avec un lien symbolique)
  6. recharger gracieusement mon serveur web

Cela me permet de maintenir le code de base de Magento séparé du mien, d'utiliser le compositeur pour le mettre à jour .. et je n'ai pas besoin d'en expédier 39 102 !!! fichiers avec chaque déploiement ou exécutez les commandes de composition au moment du déploiement.

... Je suis impatient d'entendre parler d'autres approches ou des meilleures pratiques à ce sujet, et j'aime aussi savoir quels fichiers sont réellement requis pour la production et lesquels sont dev .. afin que je puisse garder mon webroot propre.

Une fois que j'aurai fini, je n'aurai pas un playbook ansible et quelques commandes Fabric pour orchestrer la configuration et le déploiement, que je suis heureux de partager.

J'espère que cela pourra aider

farridav
la source
J'adorerais voir les playbooks et les scripts.
JM Becker