Comment déployer correctement lors de l'utilisation du Compositeur développer la production / de l'interrupteur?

Compositeur a la possibilité de charger plusieurs dépendances seulement dans le développement, de sorte que les outils ne seront pas installés dans la production (sur le serveur). C'est (en théorie) est très pratique pour les scripts qui n'ont de sens que dans le développement, comme les tests, les faux-données-outils, débogueur, etc.

Le chemin à faire est d'ajouter un supplément de require-dev bloc avec les outils dont vous avez besoin en dev:

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

et puis (théoriquement) charge de ces dépendances via

composer install --dev

Problème & Question:

Compositeur a changé le comportement de install et update de façon spectaculaire en 2013, require-dev-les dépendances sont maintenant installés par défaut (!), n'hésitez pas à créer un compositeur.json avec un require-dev block et d'effectuer un composer install à reproduire.

Comme la plus acceptée de façon à déployer, c'est pousser le compositeur.verrouillage (qui détient votre compositeur de l'installation) et ensuite faire un composer install sur le serveur de production, cela installera aussi le développement des trucs.

Quelle est la bonne façon de déployer cette sans l'installation de l'-dev dépendances ?

Note: je suis en train de créer une situation canonique de Q/r ici de préciser l'étrange Compositeur de déploiement. N'hésitez pas à modifier cette question.

  • Ne sais pas où la générosité est 🙁 je vais commencer une autre approche.
  • Si vous n'avez pas activement les prix, et pas de réponse accepté ou obtient assez de upvotes, personne ne peut le bounty.
  • Désolé, n'a pas regardé mon compte pendant un certain temps. Il y a juste un très court laps de temps pour que. Je vais demander une option sur meta.stackflow.com pour cette question! Désolé...
  • Pas de soucis!
  • Personnellement, je n'aime pas cette approche. Le composer.lock ne doivent jamais être ajoutés à la repo Git, JAMAIS. La bonne approche consiste à utiliser compositeur de mise à jour sur la mise en scène, puis synchroniser le fichier dans la production (si tout fonctionne, bien sûr). Mise en scène doit être la copie exacte d'un environnement de production. composer.lock devrait être une partie de .gitignore.
  • le compositeur.serrure electrique pour être inclus dans un fichier CSV!!! Sinon, comment vous assurez-vous que tout le monde utilise la même version?? Donc, ne JAMAIS exclure compositeur.verrouillage de votre CSV!!!
  • Je pense que tu veux dire VCS (logiciel de contrôle de version), mais sinon, vous avez raison et en ligne avec le projet de recommandations officielles.
  • Xiong Chiamiov: vous avez absolument raison! Il doit être VCS de caurse... 🙂

InformationsquelleAutor Sliq | 2014-02-12
  1. 266

    Pourquoi

    Il est à mon humble avis une bonne raison pourquoi les compositeurs utilisent le --dev drapeau par défaut (sur installer et mise à jour) de nos jours. Le compositeur est principalement exécuté dans le scénario où c'est le comportement désiré:

    La base Compositeur de flux de travail est comme suit:

    • Un nouveau projet est lancé: composer.phar install --dev, json et de verrouiller les fichiers sont engagés pour la CV.
    • D'autres développeurs de commencer à travailler sur le projet: la caisse de la cité du vatican et composer.phar install --dev.
    • Un développeur ajoute dépendances: composer.phar require <package>, ajouter --dev si vous voulez le package dans le require-dev section (et valider).
    • Les autres aller le long de: (en caisse) composer.phar install --dev.
    • Un développeur veut de nouvelles versions des dépendances: composer.phar update --dev <package> (et valider).
    • Les autres aller le long de: (en caisse) composer.phar install --dev.
    • Projet est déployé: composer.phar install --no-dev

    Comme vous pouvez le voir le --dev drapeau est utilisé (beaucoup) plus que le --no-dev drapeau, en particulier lorsque le nombre de développeurs qui travaillent sur le projet se développe.

    Production déployer

    Quelle est la bonne façon de déployer ce sans installer le "dev" dépendances?

    Bien, le composer.json et composer.lock fichier doit être engagé pour la CV. N'omettez pas composer.lock car elle contient des informations importantes sur l'emballage-versions qui devraient être utilisées.

    Lors de l'exécution d'une production de déployer, vous pouvez passer à la --no-dev drapeau de Compositeur:

    composer.phar install --no-dev

    La composer.lock fichier peut contenir des informations sur dev-paquets. Ce n'est pas grave. Le --no-dev drapeau assurez-vous que ceux dev-paquets ne sont pas installés.

    Quand je dis "la production de déployer", je veux dire un de déployer qui est destiné à être utilisé dans la production. Je suis pas en train de dire qu'un composer.phar install doit être fait sur un serveur de production, ou sur un serveur de test où les choses peuvent être examinés. Ce n'est pas la portée de cette réponse. Je suis simplement observer comment composer.phar install sans installer "dev" dépendances.

    Futiles

    La --optimize-autoloader drapeau pourrait également être souhaitable sur la production (il génère une classe-une carte qui permettra d'accélérer le chargement automatique dans votre application):

    composer.phar install --no-dev --optimize-autoloader

    Ou lorsque déploiement automatisé est fait:

    composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader
    • Je suis d'accord avec la plupart de ce qui est dit, à une exception près. "compositeur installer --no-dev" ne doit être exécuté que dans un environnement de test et que l'environnement doit être considéré comme immuable. Je ne veux avoir aucune dépendance téléchargés directement à mon serveur de production et sans passer par l'aperçu/mise en scène. C'est juste un d'un peu plus de prudence.
    • Même si je suis d'accord avec vous (et Sven couvre ce bien dans sa réponse), ce n'est pas à la portée de ma réponse, et non pas ce que je voulais dire avec "la production de déployer". J'ai ajouté un paragraphe pour que ce soit clair.
    • En fait, je pense que la valeur par défaut doit être le moins dangereux option. Décision-dev par défaut et par hasard en faisant un compositeur installer de la production pourrait être fatale.
    • Bon point dans la --optimize-autoloader. Pensez également --classmap-authoritative - à Partir de la documentation ici getcomposer.org/doc/03-cli.md vous pouvez le voir: "chargement automatique des classes à partir de la classmap seulement. Active implicitement --optimize-autochargeur" de sorte que vous pouvez utiliser si vous connaissez les classes "sont là", qui devrait probablement se produire dans votre environnement de prod, à moins que vous générer des classes dynamiquement.
    • Super réponse, je vous suggère d'ajouter optimize-autoloader directement dans le composer.json: {"config": { "optimize-autoloader": true } }
    • Pour le déploiement automatisé, je voudrais ajouter l'option --no-plugins pour des raisons de sécurité ici: getcomposer.org/doc/faqs/...
    • Qu'en est --no-suggérer, dans le cas où vous utilisez la sortie et veulent un produit de nettoyage de l'analyse?

    InformationsquelleAutor Jasper N. Brouwer
  2. 65

    En fait, je vous recommande fortement CONTRE l'installation de dépendances sur le serveur de production.

    Ma recommandation est de regarder le code sur une machine de déploiement, installer les dépendances nécessaires (cela ne comprend PAS l'installation de dev dépendances si le code va à la production), puis déplacer tous les fichiers de la machine cible.

    Pourquoi?

    • sur l'hébergement mutualisé, vous pourriez ne pas être en mesure d'obtenir une ligne de commande
    • même si vous n', PHP peut être limité en terme de commandes, de la mémoire ou de l'accès au réseau
    • référentiel des outils CLI (Git, Svn) sont susceptibles de ne pas être installé, ce qui serait un échec si votre fichier de verrouillage a enregistré une dépendance à la caisse d'un certain commettre au lieu de télécharger qui s'engagent en tant que ZIP (que vous avez utilisé --prefer-source, ou le Compositeur n'avait pas d'autre moyen d'obtenir cette version)
    • si votre machine de production est plus comme un petit serveur de test (pensez à micro instance Amazon EC2) n'est probablement pas encore assez de mémoire pour exécuter composer install
    • alors que le compositeur tente pas de casser des choses, comment vous sentez-vous à la fin d'une partie brisé la production de site web en raison du hasard de dépendance n'a pas pu être chargé au cours de Compositeurs installer phase

    Longue histoire courte: Utiliser Composer dans un environnement que vous pouvez contrôler. Votre machine de développement est admissible parce que vous avez déjà toutes les choses qui sont nécessaires à l'exploitation du Compositeur.

    Quelle est la façon correcte de le déployer sans l'installation de l'-dev dépendances?

    La commande à utiliser est

    composer install --no-dev

    Cela fonctionnera dans n'importe quel environnement, que ce soit le serveur de production lui-même, ou à un déploiement de la machine ou de la machine de développement qui est censé faire une dernière vérification pour savoir si tout dev exigence est utilisé de façon incorrecte pour le real logiciel.

    La commande ne sera pas installé, ou activement désinstaller, le dev exigences déclarées dans le compositeur.fichier de verrouillage.

    Si vous n'avez pas l'esprit de déploiement de logiciels de développement de composants sur un serveur de production, l'exécution de composer install ferait le même travail, mais il suffit d'augmenter le nombre d'octets transférés, et également de créer un plus grand autochargeur déclaration.

    • Intéressant de flux de travail, mais il y a un gros con: des Dépôts ne doivent jamais contenir le vendeur dossier/contenu lui-même (déclarations officielles sur la page de Compositeur), de sorte qu'ils ne seront jamais directement poussé à la production dans un git à base de déploiement (qui est un standard commun autant que je sache, corrigez-moi si je me trompe). Donc, fondamentalement, la solution ci-dessus ne fonctionne qu'avec les "old-school" FTP-déploiement !? Veuillez nous allons en discuter plus en profondeur...
    • Je suggère de flux de travail ne comprend pas pousser le code via GIT sur le serveur de production. En fait, je déconseille, car cela va vous forcer à installer Compositeur dépendances sur le serveur de production, ce qui peut amener un certain nombre de questions. Si vous voulez que votre déploiement afin de fonctionner correctement, vous devez assembler tout le code nécessaire à l'exécution de l'application avant de détruire la version actuelle et la remplacer. N'aime pas le FTP? RSync via SSH, puis passer les versions en actionnant un lien symbolique. Mais vous pouvez également pousser, checkout et compositeur installer en prod, si vous le souhaitez.
    • Je viens juste de voir cette partie de votre commentaire et je suis obligé de répondre: "poussé à la production dans un git à base de déploiement (qui est un standard commun autant que je sache, corrigez-moi si je me trompe)" - Non, ce n'est pas ordinaire. C'est juste une façon de le faire.
    • L'équipe, je suis sur a intégré ce dans leur flux de travail avec un grand succès. Nous avons une machine de compilation (Jenkins, bien sûr) qui: 1) vérifie (SC 2) s'exécute compositeur installer/mettre à jour 3) exécute les tests unitaires 4) supprime dev dépendances 5) génère un fichier phar (app-1.34.phar etc). Il y a un mécanisme distinct qui est notifiée et décide de récupérer ces fichiers, où transférer, puis de quoi faire avec elle. Certaines équipes choisissent d'avoir la phar déballé une fois sur le serveur et certaines équipes à exécuter en tant que-est. Il est prêté beaucoup de confiance pour la stabilité et la reproductibilité de nos déploie.
    • Dans la plupart des cas, le "installer" stratégie fonctionne bien, mais avec un plus grand serveur, je suis en train de faire un cycle de production qui génère des "Docker" image " qui est ensuite synchronisé et installé sur des serveurs. Bien évidemment, il est facile de revenir à l'image précédente, également la commutation entre les images qui se passe instantanément, donc pas de temps d'arrêt se produit.
    • Je suis d'accord à 100% avec cette réponse. Le compositeur ne doit pas être installé sur le serveur de déploiement, ni git. Continue de Déploiement/Intégration serveurs sont exactement censé gérer la source et de l'extraction de dépendances : git pull > compositeur install > déployer
    • Je suis d'accord avec Eric. Vous devez utiliser certaines de déploiement de Serveur ou un script (quoi que) pour faire le déployer. obtenir le code -> compositeur installer --no-dev -> déployer. Vous pouvez écrire un script ou une meilleure utilisation des Outils automatisés tels que Jenkins, de déployer.hq, bitbucket-pipelines, et il y a beaucoup plus de...
    • Pensez-vous est ok si au sein de mon équipe, nous avons directement publier l'ensemble vendor répertoire au lieu d'installer les dépendances côté serveur sur la machine de production? Je me demande quelle est la meilleure pratique pour déployer compositeur paquets utilisés par l'application.
    • À partir de dénigrement de ma tête contre les problèmes de mémoire dans VMs j'ai 100% d'accord avec vous. composer luttes. yarn / npm / webpack meurent souvent dans ces scénarios limités.
    • composer install est très léger, si vous avez composer.lock dans votre projet, je doute fortement que vous obtiendrez relatives à la mémoire des problèmes sur tout utilisable serveur.

    InformationsquelleAutor Sven
  3. 2

    Maintenant require-dev est activé par défaut, pour le développement local, vous pouvez le faire composer install et composer update sans --dev option.

    Lorsque vous souhaitez déployer en production, vous devez vous assurer que la composer.lock n'ont pas tous les paquets qui sont venus de require-dev.

    Vous pouvez faire cela avec

    composer update --no-dev

    Une fois que vous avez testé en local avec --no-dev vous pouvez déployer tout à la production et à installer en fonction des composer.lock. Vous avez besoin de la --no-dev option de nouveau ici, sinon compositeur va dire "Le fichier de verrouillage ne contient pas de besoin-dev de l'information".

    composer install --no-dev

    Remarque: Être prudent avec tout ce qui a le potentiel d'introduire des différences entre les dev et de la production! De manière générale, j'essaie d'éviter de besoin-dev dans la mesure du possible, comme notamment les outils de dev n'est pas une grosse surcharge.

    • C'est en fait incorrect dans les détails. Il n'est pas nécessaire de vérifier composer.lock pour dev dépendances. Vous pouvez simplement exécuter composer install --no-dev, et vous obtiendrez seulement les régulièrement les dépendances installées en fait, le Compositeur va également supprimer toutes les dev dépendances dans cette étape.
    • Si mon local composer.lock avait dev dépendances (et potentiellement affectés les versions de non paquets-dev) alors que je veux le mettre à jour pour refléter la façon dont il serait dans la production. Cela vous force à exécuter composer install --no-dev dans la production, comme composer install l'erreur. Techniquement, je pense que vous avez raison; ce n'est pas obligatoire, mais c'est un niveau supplémentaire de sécurité, que j'aime.
    • Ok, démo scénario: Votre application nécessite un dev/tool et prod/lib:~1.0. La dernière prod/lib est 1.3, mais dev/outil nécessite également prod/lib:1.1.*. Résultat: Vous allez installer la version 1.1.9 (de la plus récente de 1.1.x direction) et de l'utiliser au cours de votre développement. Je dirais qu'il n'est PAS sûr de mettre à jour --no-dev, comprennent donc la dernière prod/lib 1.3 et assumer tout fonctionne sans le tester. Et peut-être que le test est alors impossible en raison de l'absence de dev ou de l'outil. Je suppose que parce que dev/outil n'est pas nécessaire dans la production, il ne devrait pas être lancé, mais le logiciel doit utiliser prod/lib 1.1.9 ensuite.
    • Si vous utilisez --no-dev ensuite, vous devez la tester localement, comme je l'ai mentionné dans la réponse. Je voudrais encore vous recommandons de ne pas utiliser --no-dev à tous même si.
    • Donc, fondamentalement, vous suggérer ceci: composer update, puis faire un peu de développement, puis de faire composer update --no-dev, puis faire les essais de libération, puis le pousser à la production et à faire composer install --no-dev. Deux problèmes: 1. Je ne peux pas tester la version sans dev dépendances et 2. Je ne peux pas installer avec, par exemple, Git dans la production.
    • Pour tester correctement, vous devez vous assurer que vous avez les mêmes dépendances que localement comme vous le feriez dans la production. Si vous ne pouvez pas tester la version correctement sans dev dépendances puis de l'OMI, vous devez exiger dev dépendances dans la production. Être sûr à 100% de votre dev dépendances ne sont pas affecter le reste du code est difficile.
    • Je suis assez sûr que PHPUnit est pas la production d'une partie de mon logiciel, de sorte qu'il n'appartient pas à la régulière require liste - et le test sans le dev exigences serait également impossible.

    InformationsquelleAutor dave1010
  4. 2

    Sur les serveurs de production-je renommer vendor à vendor-<datetime>, et pendant le déploiement aura deux de fournisseur dirs.

    Un cookie HTTP causes de mon système pour choisir le nouveau fournisseur autoload.php, et après le test je fais entièrement atomique/instant de basculer entre eux pour désactiver l'ancien fournisseur dir pour toutes les futures demandes, puis-je supprimer le précédent dir quelques jours plus tard.

    Ce qui évite tout problème causé par le système de fichiers caches, je suis à l'aide d'apache/php, et permet aussi de tout actif du code PHP pour continuer à utiliser le précédent vendeur dir.

    Malgré d'autres réponses recommander contre, personnellement, je m'exécuter composer install sur le serveur, car c'est plus rapide que rsync de ma zone de transit (une machine virtuelle sur mon pc portable).

    - Je utiliser --no-dev --no-scripts --optimize-autoloader. Vous devriez lire la documentation pour chacun de vérifier si cela est approprié à votre environnement.

    InformationsquelleAutor Abhi Beckert
  5. 2

    Je pense que c'est mieux automatiser le processus:

    Ajouter le compositeur.verrouillage de fichier dans votre dépôt git, assurez-vous d'utiliser compositeur.phar install --no-dev lorsque vous relâchez le bouton, mais vous dev machine, vous pouvez utiliser n'importe quel compositeur de commande sans soucis, ce n'est aller à la production, la production de la base de ses dépendances dans le fichier de verrouillage.

    Sur le serveur vous commander cette version spécifique ou de l'étiquette, et exécuter tous les tests avant de remplacer l'application, si les tests passent de poursuivre le déploiement.

    Si le test dépendent de dev dépendances, en tant que compositeur de ne pas avoir un test de portée de la dépendance, un pas beaucoup de solution élégante pourrait être exécuter le test avec le dev dépendances (compositeur.phar install), supprimer le fournisseur de la bibliothèque, exécutez compositeur.phar install --no-dev encore une fois, cela permettra d'utiliser la mise en cache des dépendances est donc plus rapide. Mais c'est un hack si vous connaissez le concept de champs d'application dans d'autres outils de construction de

    Automatiser et d'oublier le reste, aller boire une bière 🙂

    PS.: Comme dans le @Sven commentaire ci-dessous, n'est pas une bonne idée de ne pas extraire le compositeur.fichier de verrouillage, car ce sera le compositeur installer de travail en tant que compositeur de mise à jour.

    Que vous pourriez faire de l'automatisation avec http://deployer.org/ c'est un outil simple.

    • +1 pour Deployer! Cool outil, merci!
    • Ne pas s'engager et de vérifier composer.lock fera composer install agir comme composer update. Si les versions de déployer ne sont pas ceux que vous avez développé avec. Cela est susceptible de générer des problèmes (et de plus en plus dans la lumière de la seule récemment résolu un problème de sécurité sur "remplacer" dans Compositeur). Vous ne devriez JAMAIS manquer composer update sans assistance, sans vérifier qu'il n'a pas casser quoi que ce soit.
    • c'est une façon de suggérer dans le même commentaire pour exécuter les tests Unitaires automatiquement avant de les déployer. Mais vous avez raison, c'est mieux de garder le compositeur.fichier de verrouillage de toute façon.
    • Je l'ai mise à jour de la réponse, compte tenu de votre commentaire.
    • Maintenant, la seule chose que vous avez à expliquer: Comment avez-vous exécutez les tests sur le serveur sans le dev dépendances comme PHPUnit?
    • Ce serait très bien, si les dépendances, les tests et le déploiement ont été placés ensemble dans un seul outil, comme Java Gradle ou SBT ou même Maven (maven n'est pas si bon). Un outil PHP qui font de compositeur phpunit de déploiement et de travailler ensemble. Ou même un Gradle ou Scala SBT plugin pour faire ce genre de choses, car ils sont agnostiques outils de construction, le plugin pourrait même travailler avec des actifs comme la minimisation de javascript et de la compilation de sass, de minimiser les css. Quelqu'un sait quelque chose?
    • Si le test dépendent de dev dépendances, en tant que compositeur de ne pas avoir un test de portée de la dépendance, un pas beaucoup de solution élégante pourrait être exécuter le test avec le dev dépendances, supprimer le fournisseur de la bibliothèque, exécutez compositeur.phar --install --no-dev cela utiliser la mise en cache des dépendances. Mais c'est un hack si vous connaissez le concept de champs d'application dans d'autres outils de construction.
    • Bien sûr, cela est fait dans le serveur de test de l'environnement réel, mais pas directement dans le site de serveur virtuel, vous pouvez à cette séparation temporaire dossier et déplacez le résultat pour le vhost lors de réussir
    • url semble être rompu. est l'outil que vous l'avez mentionné la même chose que deployer.org ?
    • C'est grâce.

    InformationsquelleAutor Giovanni Silva