Avez-vous vraiment besoin de Composer en production ?

La recette est la suivante : gitignorez votre répertoire "vendor" (ou n'importe quel dossier dans lequel se trouvent vos dépendances), mais livrez votre fichier composer.lock, puis déployez. Votre job CI va alors "composer installer" toutes les dépendances là où elles doivent l'être, reproduisant comme par magie la disposition de vos fichiers initiaux, exactement comme ils l'étaient en développement.

Il y a généralement quelques étapes supplémentaires entre les deux. Typiquement, vous avez perdu une demi-journée à trouver les bonnes permissions de fichiers pour que le var/cache de votre application puisse être effacé et recréé correctement par l'utilisateur du serveur web, vous vous êtes demandé pendant des jours pourquoi certains builds échouaient aléatoirement avant de réaliser qu'aucun token n'était défini dans ce job donné, ce qui signifie que la limite de taux de l'API de github a parfois été atteinte. Puis encore une ou deux bonnes journées à trouver comment appliquer deux patches pour les mêmes projets lorsqu'ils sont légèrement en conflit. Et votre administrateur système pourrait être légèrement suspicieux au sujet de ces fichiers téléchargés et exécutés directement sur la production en dehors de tout VCS, et surveiller anxieusement les rapports d'exploitation.

Maintenant, vous m'assurez que vous avez résolu tous ces problèmes et que, mis à part un problème de réseau occasionnel empêchant la récupération des paquets, tout se passe bien. C'est parfait.

Mais s'il vous plaît, relisez ce qui précède. Pourquoi faites-vous tout cela ? Pour "reproduire la disposition de vos fichiers initiaux exactement comme ils étaient". Alors pourquoi ne pas simplement livrer les fichiers et les pousser ?

C'est normalement à ce moment de la discussion que l'on est censé utiliser les mots "reproductible" et "meilleures pratiques".

Reproductible

Oui, mais qu'y a-t-il de plus reproductible que de déplacer des fichiers préconstruits ? Vous avez déjà joué la recette une fois sur votre environnement de développement, prendre le risque de l'exécuter à nouveau sur la production ressemble un peu à recompiler des binaires à partir des sources simplement parce que vous le pouvez.

Composer n'est pas magique. Ce qu'il fait, c'est prendre un tas de fichiers PHP, en s'assurant qu'ils sont à la bonne version et qu'ils se retrouvent au bon endroit, afin qu'ils puissent jouer ensemble. Une fois que vous avez déjà le jeu de fichiers résultant, pourquoi voudriez-vous refaire cela encore et encore sur chaque environnement ?

Meilleures pratiques

Regardons de plus près ce qui est dit dans la documentation de Composer et les raisons pour lesquelles le projet recommande de ne pas commiter vos dépendances :

• la taille importante du dépôt VCS et les différences lorsque vous mettez à jour le code ;
• la duplication de l'historique de toutes vos dépendances dans votre propre VCS ;
• l'ajout de dépendances installées via git à un repo git les affichera comme des sous-modules.

Je vais ignorer la taille du dépôt (parce que, franchement ?) et me concentrer sur les parties diff et history.

Tout d'abord, l'argument ici est légèrement trompeur : en lisant la documentation, vous pourriez avoir l'impression que votre dépôt contiendra tout l'historique git de chacune des dépendances de votre projet. Non, ce n'est pas le cas. Ce que vous finirez par avoir, tout au long de la vie de votre projet, c'est l'historique des mises à jour de vos dépendances après votre commit initial.

Ce qui est plutôt le point le plus important ici. C'est une bonne chose ! Pourquoi ne voudriez-vous pas pouvoir regarder - et garder une trace dans votre VCS - ce qu'il y avait dans la mise à jour de Guzzle 3.8.0 à 3.8.1 ou quelle différence il y a entre ctools 8.x-3.0-alpha27 et alpha26 ? Votre projet " live " n'est pas seulement votre code personnalisé.

Que trouveriez-vous le plus utile, la prochaine fois que votre client ouvrira un ticket parce que l'intégration d'images dans l'éditeur WYSIWYG a cessé de fonctionner depuis la dernière version, en regardant le commit "Upgrade contrib module media_entity from 8.x-1.5 to 8.x-1.6" ? Voir un changement de hachage d'une ligne dans composer.lock, ou voir un beau diff des changements réels dans le code, afin que vous puissiez retracer ce qui a mal tourné ?

Le point sur les submodules .git est juste, mais facile à contourner, comme expliqué sur cette même page des meilleures pratiques. Gardez également à l'esprit que cela ne s'applique que si vous utilisez des versions dev ou des dépendances obscures non packagées.

Donc, pour résumer, si vous utilisez Composer pour construire votre code en production, vous obtenez :

• (-) Une augmentation inutile et chronophage de la complexité du déploiement, avec des risques faibles mais réels d'échec sur chaque build pour des raisons externes ;
• (-) Pas d'audit des changements qui ne sont pas votre propre code personnalisé ;
• (+) Une gestion plus facile des "faux" sous-modules .git pour quelques dépendances de développement.

D'un autre côté, si vous livrez le répertoire "vendor", vous obtenez :

• (+) Un déploiement plus simple et direct ;
• (+) Tout le code qui arrive en production est audité/versionné ;
• (-) Un peu de travail pour traiter les éventuels "faux" sous-modules .git.

Alors pourquoi ?

Mais alors, pourquoi cette pratique est-elle si répandue ? Je ne peux que deviner, mais je soupçonne que plusieurs facteurs entrent en jeu :

• La mode, dans une certaine mesure, doit jouer un rôle. Il y a de très bonnes raisons de procéder ainsi pour certains flux de travail, ce qui peut amener les gens à penser que cela peut s'appliquer à n'importe quel flux de travail de déploiement.     
• Le fait qu'elle soit présentée comme une "meilleure pratique" sur la page du projet Composer. De nombreuses personnes l'appliquent sans se demander si elle est applicable à leur cas d'utilisation.

Mon interprétation est que, plus fondamentalement, la cause première est la confusion entre le "déploiement" de code et la "distribution" de code.

Déplacer un "objet vivant" d'un environnement vers un autre environnement n'est pas le même processus que de rendre un composant ou une application disponible pour que d'autres projets puissent le réutiliser et s'en inspirer. Composer est un outil de construction fantastique, il est parfait pour ce dernier cas, et l'utiliser pour assembler votre projet est tout à fait logique. L'utiliser comme outil de déploiement l'est moins.

Si nous examinons à nouveau les arguments ci-dessus du point de vue de la distribution, l'analyse est totalement différente :

• Taille importante du référentiel VCS et différences importantes lors de la mise à jour du code ;  
• Duplication de l'historique de toutes vos dépendances dans votre propre VCS.

En effet, dans ce cas d'utilisation, tout est parfaitement logique : vous n'avez absolument pas besoin de l'historique git complet d'un composant que vous réutilisez pour votre projet. Vous n'avez pas non plus besoin que votre repository - pour la bibliothèque web-crawler à laquelle vous contribuez sur GitHub - contienne la base de code Guzzle dont vous dépendez.

En bref, pensez à l'utilisation. Si vous maintenez, par exemple, une distribution Drupal personnalisée que vous utilisez en interne comme point de départ pour vos projets, par tous les moyens oui, ignorez le répertoire vendor. Construisez-le avec Composer lorsque vous l'utilisez pour démarrer un nouveau projet. Et continuez à utiliser Composer pour gérer les mises à jour des dépendances dans votre environnement de développement. Cependant, une fois qu'il ne s'agit plus d'un composant réutilisable, mais d'un projet vivant qui devra être déployé d'un environnement à l'autre, faites-vous une faveur et examinez attentivement si l'utilisation de Composer pour le déploiement apporte réellement un avantage.

Source : https://drupalsun.com/pascal/2017/03/21/do-you-really-need-composer-production