Symfony2, AWS Beanstalk : comment pousser le fournisseur en tant que fichiers et non des git-submodules vers un dépôt

Question

Nous utilisons Symfony2 sur une application AWS Beanstalk. Pour le déploiement, nous avons ajusté le script de déploiement pour effectuer un composer install après que l'application ait été téléchargée.

Même si cela fonctionne théoriquement, cela présente quelques inconvénients - principalement l'augmentation constante du temps de déploiement (ce qui entraîne parfois des délais d'attente du serveur) et l'accroissement des dépendances à l'égard de la disponibilité d'autres serveurs.

J'ai lu que certaines personnes copient les fichiers vendor/* dans un répertoire temporaire et les déplacent de nouveau après le déploiement pour accélérer le déploiement.

Cela est certainement utile, mais nous mettons régulièrement à jour notre fichier composer.jsoncomposer install dans notre processus de déploiement. Nous pensons que la meilleure approche est d'inclure toutes les dépendances (`vendor/*`) en tant que fichiers dans le dépôt et de sauter l'étape _composer install_ lors du déploiement.

`

Malheureusement, la plupart des bibliothèques sont incluses en tant que submodules git et AWS ne prend pas en charge les submodules (tous les fichiers doivent être dans le dépôt).

Voici donc ma question:

Quelle est la meilleure manière de supprimer tous les submodules git et de commettre les fichiers réels à la place?

J'ai essayé de combiner:

git submodules --recursive foreach

avec Comment supprimer un submodule? mais sans succès.

`

Answer 1

Vous pouvez essayer ce flux de travail :

• créer un nouveau dossier de version
• extraire la dernière version de votre code dans le nouveau dossier
• copier "fournisseur" du dossier de version actuellement actif dans le nouveau dossier de version
• exécuter "composer.phar install"

Ainsi, composer ne mettra à jour que les bibliothèques qui ont changé entre les versions.

Je l'utilise avec succès avec capistrano (il existe également une version spécifique à Symfony appelée capifony) qui peut vous aider. Surtout parce qu'il peut garder un clone de votre dépôt git, ce qui rend le déploiement de nouvelles versions beaucoup plus rapide, et les déploiements et les retours en arrière ne sont qu'à un commandement de distance.