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

Question

Le 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 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 Et Question:

Le compositeur a changé le comportement de l' 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.de 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 ce 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.}

Answer 1

Pourquoi

Il est à mon humble avis une bonne raison pourquoi les compositeurs utilisent l' --dev indicateur par défaut (installation 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 de 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 de l' composer.phar install --dev.
• Un développeur ajoute dépendances: composer.phar install --dev <package> (et valider).
• D'autres vont de pair: (en caisse) composer.phar install --dev.
• Un développeur veut de nouvelles versions des dépendances: composer.phar update --dev <package> (et valider).
• D'autres vont de pair: (en caisse) composer.phar install --dev.
• Le projet est déployé: composer.phar install --no-dev

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

La Production de déployer

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

Eh bien, l' composer.json et composer.lock le fichier doit être engagé pour la CV. Ne pas omettre 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 l' --no-dev drapeau de Compositeur:

composer.phar install --no-dev

L' composer.lock le fichier peut contenir des informations à propos de dev-paquets. Ce n'est pas grave. L' --no-dev drapeau assurez-vous que ceux dev-paquets ne sont pas installés.

Offtopic

L' --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 de l'application):

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

Ou quand déploiement automatisé est fait:

composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader

Answer 2

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 permettra de travailler 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 d' composer install serait de faire 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.

Answer 3

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 assurez - composer.lock n'ont pas tous les paquets qui est venu de require-dev.

Vous pouvez le faire 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 de l' composer.lock. Vous avez besoin de l' --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: soyez 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, y compris les outils de dev n'est pas une grosse surcharge.

Answer 4

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 le 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 dépendance, 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

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.

Vous pourriez le faire avec l'automatisation http://deployer.in/ c'est un outil simple.