Laravel 5

Questions générales sur git, composer, etc.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    Bonjour,

    Depuis peu de temps, j'utilise git pour déployer depuis le local sur un dépôt distant.

    Je n'utilise donc pas du tout composer sur le serveur distant. Par exemple quand j'installe un package avec composer require xxx, je le fais en local, puis je commets 'Installation du package xxx', puis je pousse vers le dépôt distant.

    Devrais-je plutôt installer le même package via composer sur le serveur distant, puis commettre seulement mes modifications qui sont hors du dossier vendor ?

    Vous, comment faites-vous ?

  • Avatar de Farris27
    Membre depuis :
    31/10/2017
    Messages :
    66

    Moi, je fais toujours l'installation avec composer sur mon serveur et je commets mes modifications dans mon projet.

    ps: ne jamais modifier dans le vendor ;) Il faut toujours modifié dans les endroits adéquats.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    Je sais, je ne modifie jamais les fichiers dans vendor. En revanche j'ai inclus vendor dans les fichiers suivis par git, donc quand je publie, tout le dossier vendor est copié. Je ne sais pas si c'est une bonne idée, mais je trouvais ça plus pratique que d'aller faire des composer update ou dump autoload, que je ne maîtrise pas, à chaque fois que j'installe quelque chose...

  • Avatar de Farris27
    Membre depuis :
    31/10/2017
    Messages :
    66

    Le problème de ta méthode c'est qu'il peut avoir un bug ou des fichiers qui se perdent ou s'éffacent. Je te conseille plutôt de commence à te familiarisé avec composer. ça change une vie :)

    Car imagine le temps que tu perd en envoyant le vendor à chaque fois ... Je ne pourrais pas faire ça où je travaille , trop de temps perdu

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    En fait je fais un push vers un remote repository, seuls les fichiers modifiés sont envoyés (je crois), donc c'est très rapide.
    Mais merci du conseil, je vais essayer de me documenter un peu plus... J'avoue que ça me fait un peu peur vu que je lance des instructions sans trop les comprendre...
    Surtout sur une chose : par exemple quand tu installes un package et que ça fait planter tout le site, et qu'il faut modifier telle ou telle chose pour que ça fonctionne, en local ou en dev pas de problème, mais en production, c'est différent... Comment éviter ça alors ? (Ce qui est quand-même assez fréquent)

    EDIT : Et autre chose, quand tu travailles sur git avec une branche dev et une branche master, par exemple, à la fin de tes modifications tu fais un merge puis tu déploies. Mais alors tu es obligé de te souvenir de tout ce que tu as fait via composer et de le refaire sur le serveur de prod ? De plus il faudrait que je le fasse 3 fois, en local, sur le serveur de dev, et sur le serveur de prod ? J'ai l'impression que ça augmente le risque d'erreurs...

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    @Farris un git pull est plus rapide qu'un composer update, ce n'est pas le problème

    @Charlie C'est considéré comme une mauvaise pratique de "commiter" tes dépendances. D'ailleurs par défaut ton dossier vendor est dans le .gitignore d'une install Laravel fraîche (pourquoi l'avoir retiré ?).

    Voilà à mon avis quelques bonnes raisons pour ne pas "commiter" tes dépendances :

    • augmentation inutile de la taille de ton dépôt
    • pollution de ton historique. Personnellement je préfère voir :

    • Intégration du moyen de paiement en ligne Stripe via le SDK

    plutôt que :

    *Installation du SDK Stripe + mise à jour des dépendances

    • Intégration du moyen de paiement en ligne Stripe via le SDK

    Ton dépôt doit se concentrer sur ton projet et ton code avant tout.

    • Pollution de tes différentiels. Quand tu regardes le différentiel d'une version dans laquelle tu as fait un composer update, tu vas te retrouver avec toutes les modifs effectuées dans tes dépendances (d'ailleurs ça risque de faire ramer ton visualiseur). Encore une fois, git doit se concentrer sur le code de ton projet, pas sur celui des autres.

    Donc je te conseille de suivre les pratiques admises : commit de ton composer.json et composer.lock (qui garde l'historique des versions installées, ça peut être très utile en cas d'incompatibilité de version par ex). Et lors du déploiement, composer install/update après git pull.

    Pour info tu devrais plus avoir peur des commandes git que tu ne maîtrises pas plutôt que de composer, qui ne pose aucun problème à partir du moment où tu circonscris tes dépendances dans des versions bien précises dans ton composer.json.

    Et pour répondre à ta dernière question, composer limite justement le risque d'erreur, il ne va pas installer une version d'une dépendance que tu ne souhaites pas, il respecte scrupuleusement le composer.json. Juste composer update, point.

    Et quand tu veux tester une version supérieure d'une dépendance, tu commences par le faire en local :

    • modif du composer.json
    • composer update
    • lancement des tests unitaires etc...
  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    Merci @F.M. pour toutes ces infos. J'avais effectivement retiré le dossier vendor du gitgnore après avoir lu cette discussion sur le sujet et j'avais été convaincu par le dernier commentaire :

    "The vendor directory is a few megs compressed, it doesn't add any serious commit time or disk space. There are other reasons to not include the vendor directory, but I don't think those two are applicable in this day and age. Personally, I include the vendor directory, as it makes deploys and consistency easier, and that is a much higher priority to me than small commit size or an extra second of upload/download on a project. Rollbacks/version checkouts are more consistent as well."

    J'ai vu "easier" et "more consistent", donc je me suis lancé. De plus j'avais eu des soucis à l'époque, où j'avais eu du mal à installer des choses via composer sur le serveur distant (messages d'erreur, mauvais chemin pour vendor, etc.).

    Mais je crois que j'avais mal compris un truc : En distant, on n'a pas besoin de faire composer require xxx mais seulement composer update, si je comprends bien ce que tu écris... Et ça, ça change tout :)

    Autre chose :

    J'ai suivi plusieurs tutos sur le deploiement avec git et j'en suis arrivé à une config telle que :

    • J'ai une branche dev pour le dev et la branche master pour la prod.

    • Au niveau du serveur j'ai un dossier home/git/ à la racine, qui est le dépôt distant.

    • Puis dans le dossier home/user/www/ j'ai deux sous-dossiers /dev/ et /prod/.

    • Quand je fais git push origin master ou git push origin dev il y a un hook "post-update" qui fait automatiquement un git pull origin master dans le dossier /prod/ et git pull origin dev dans le dossier /dev/.

    Comme ça tout est automatique.
    Que pensez-vous de cette technique ? Au niveau sécurité, ça vous semble correct ?
    Pourrais-je/devrais-je ajouter un composer update dans ce hook ?

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    Salut Charlie,

    Jamais de "composer require" en prod, ta "source of truth" c'est le composer.json de ton dépôt distant, que t'as récupéré via le git pull. Interdit de le modifier sur le serveur de prod.

    J'ai pas compris ton déploiement. Normalement t'as 3 entités :

    1/ Ton pc de dev avec ton dépôt local, qui push vers 2/
    2/ Ton dépôt distant, "source of truth"
    3/ Ton serveur de prod, avec un dépôt local qui pull 2/

    Tu peux reprendre ton déploiement en détaillant chacune des entités ?

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    Salut @F.M.

    J'ai donc :

    Mon pc de dev avec dépôt local. Ce dépôt comporte deux branches principales :

    • master
    • dev

    Un dépôt distant (sur un ovh mutualisé pro avec accès ssh) dans le dossier /home/git/.

    Je fais donc (depuis le dépôt local) : git push origin --all pour faire un push de toutes les branches.

    Dans le même serveur, il y a deux dossiers :

    • /home/user/www/dev/
    • /home/user/www/prod/

    Au niveau de la config de l'hébérgement, j'ai :

    • dev.monsite.fr qui pointe vers /home/user/www/dev/public/, protégé par un .htpasswd et qui me sert en quelque sorte d'environnement de "staging" mais avec debug activé.
    • monsite.fr qui pointe vers /home/user/www/prod/public/ qui est le site public.

    Puis au niveau de git :

    Dans le dossier (distant) /home/git/monprojet.git/hooks/ il y a un fichier post-update qui exécute (à chaque fois qu'il détecte un push) ce qui suit :

    cd /home/user/www/prod/
    git pull origin master
    cd /home/user/www/dev/
    git pull origin dev

    J'éspère que c'est plus clair.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    @F.M., qu'en penses-tu ?

  • Avatar de F.M.
    Membre depuis :
    10/07/2017
    Messages :
    97

    Salut,

    Moi je te conseillerais d'utiliser un dépôt github ou bitbucket par exemple pour stocker ton dépôt distant, et de ne pas le stocker sur ton serveur de prod.

    En fait le but n'est pas de rendre les choses automatiques à l'extrême.

    Quand tu push une modif sur ton dépôt distant, tes collègues doivent être en mesure de discuter les modifs avant de les intégrer dans la branche principale et de les déployer en prod.

  • Avatar de Charlie_Web_Nancy
    Membre depuis :
    10/08/2016
    Messages :
    77

    Merci F.M.,

    En fait pour moi le but est justement d'automatiser le plus possible pour être plus efficace. Je me sers de git en majeure partie comme d'un outil de déploiement (et aussi pour la gestion des branches). Et je suis une équipe de 1 personne (moi), donc ce côté là pas de souci. :)

    Ma question était plus de savoir si cette méthode n'impliquait pas de failles de sécurité...

    Concernant BitBucket, j'ai un compte sur lequel je mets deux ou trois choses, mais j'ai lu que ce n'était malheureusement pas possible de communiquer entre BitBucket et un serveur mutu OVH, alors j'ai abandonné au profit de cette solution. :'(

    (A propos j'ai suivi tes conseils et j'ai retiré /vendor/ du suivi, c'est beaucoup mieux et les fonctions composer fonctionnent très bien. J'ai juste pas encore compris quand je devais faire composer dump-autoload ou composer update... J'ai remarqué que composer update mettait à jour les dépendances vers de nouvelles versions "automatiquement", pour l'instant aucun souci, mais j'ai peur du bug à l'avenir...)

Vous ne pouvez pas répondre à ce sujet.