Gérer Magento / Composer / Déploiement

Donc, j'aime utiliser l'installateur hackathon Magento Composer, mais j'ai du mal à comprendre comment les autres l'utilisent par rapport à un service de déploiement. Actuellement, j'utilise DeployHQ, et oui, je peux le configurer pour déployer et exécuter composer quand il y a une mise à jour du dépôt, mais cela n'a plus de sens pour moi maintenant.

Mon dépôt principal de compositeur, contenant uniquement le fichier json de tous les packages que je veux inclure dans ma build, n'est mis à jour que lorsque j'ajoute un nouveau package à la liste.

Lorsque je mets à jour mon thème ou mon extension personnalisée (qui est référencée dans le fichier json), il n'y a pas de «hook» pour mettre à jour mon service de déploiement. Je dois donc me connecter à mon serveur et exécuter manuellement composer (ce qui supprime le site jusqu'à ce qu'il soit terminé).

Alors, comment les autres gèrent-ils cela? Dois-je uniquement exécuter Composer localement et inclure le dossier du fournisseur dans mon référentiel?

Toutes les réponses seraient grandement appréciées.

J'ai mis en place une structure dans notre agence qui nous permet d'utiliser Composer pour déployer tous nos sites Magento. Cela pourrait être un peu exagéré pour la question que vous avez posée, mais voici tout de même un aperçu de base de la structure:

Structure du référentiel

Vous trouverez ci-dessous la structure des dossiers du référentiel «parent». Il contient le compositeur JSON et les fichiers de verrouillage et toute autre configuration requise pour le déploiement.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• Toutes les personnalisations spécifiques au client sont stockées dans un module "personnalisations" distinct qui est installé à l'aide de Composer
• Le noyau Magento est inclus en tant que sous-module Git ( code/magento)
• Un index.phpdossier personnalisé et d'autres dossiers comme les médias et les erreurs se trouvent dans un dossier public en dehors de la racine Magento
• Les fichiers spécifiques à l'environnement (local.xml, robots.txt, etc.) sont liés symboliquement à la racine Magento pendant le processus de déploiement
• Le dossier du fournisseur est exclu de Git, mais le fichier composer.lock est inclus.

Déploiement

• Nous déployons en utilisant Capsitrano qui permet de multiples serveurs et environnements d'application (staging / production)
• Capistrano crée l'intégralité de la base de code sur le serveur dans un nouveau dossier, puis échange le lien symbolique webroot à la toute fin, ce qui signifie qu'il n'y a pas de temps d'arrêt pour votre site Web.
• Capistrano s'exécute composer installpendant la génération et déploie tous les modules dans le sous-module Magento.

Ce n'est toujours pas une configuration d'intégration continue, mais je trouve que cela fonctionne bien pour les sites Magento. N'hésitez pas à m'envoyer un message si vous souhaitez plus de conseils spécifiques à votre configuration.

Une autre méthode consiste à utiliser la stratégie de déploiement de copie de hackathons magento, qui ressemble un peu à ceci dans votre fichier composer.json:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

L'utilisation de la méthode ci-dessus copie les fichiers installés du fournisseur vers l'installation réelle, ce qui permet de les valider dans Git et de les déployer normalement, sans avoir à effectuer d'installation de composeur.

Je ne suis pas un grand fan de retirer des référentiels tiers lorsque vous êtes sur le point de faire un déploiement en direct, et dépendre de référentiels tiers est un peu risqué, sauf si vous avez une sorte de cache proxy pour votre réseau .

Lisez cet article et il vous donnera une perspective différente: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Fondamentalement, le NPM est tombé en panne (en quelque sorte ..) et les systèmes de build de tout le monde ont cessé de fonctionner (pour les déploiements critiques!) Car ils dépendaient directement du NPM. (NPM est un peu comme Packagist pour Javascript, sauf que NPM héberge en fait le fichier et Packagist pointe simplement vers le dépôt de modules Github - corrigez-moi si je me trompe)

edit: juste la réponse de fschmengler rouge. Ceci est une élaboration de sa 1ère approche

Il est important de comprendre que Composer n'est pas un outil de déploiement, mais un outil de développement.

Il existe différentes approches pour préparer un déploiement avec toutes les dépendances:

• valider le répertoire du fournisseur (ou partout où composer installe les sources) dans le référentiel du projet
• utiliser un serveur de build qui s'exécute composer installet crée une archive avec le résultat, que vous pouvez déployer reproductible sur différents systèmes cibles
  • en cours composer installd' exécution sur le serveur, puis basculez les liens symboliques comme suggéré par @ jharrison.au est une variante de celui-ci

Cela mis à part, je ne recommande pas d'utiliser Composer pour chaque module et de ne conserver composer.jsonet composer.lock dans le référentiel du projet. Cela en fait trop et rend le développement inutilement compliqué. Cela est parfaitement logique pour le code qui est réutilisé sur plusieurs projets, mais pourquoi placeriez-vous du code spécifique à un projet dans des référentiels distincts?

Ma structure de projet actuelle ressemble à ceci (en utilisant les programmes d' installation de compositeurs alternatifs d'AOE ):

• srccontient tous les modules spécifiques au projet. Composer installe également tous les autres modules Magento ici
• .modmanliens vers srcafin que modman puisse gérer facilement le lien symbolique
• wwwest le webroot. Composer installe le noyau Magento ici

De cette façon, j'inclus des modules externes dans le référentiel. Si vous préférez ne pas le faire, ajustez-le comme ceci:

• srccontient tous les modules spécifiques au projet. Pour les inclure .modmanafin que modman crée des liens symboliques, utilisezmodman link
• .modmanest dedans .gitignore. Composer installe les modules Magento ici
• wwwest le webroot. Composer installe le noyau Magento ici