Forum Programmation.php branches GIT

Posté par . Licence CC by-sa.
Tags :
0
15
fév.
2020

Bonjour à tous,

je continue mon apprentissage de GIT et sollicite vos conseils sur l'organisation d'un dépôt

je développe/maintiens une appli pbp assez importante pour un client, celui-ci me met à disposition 2 environnements LAMP, l'un de TEST et l'autre de PROD

je pensais donc avoir 1 dépôt GIT avec 2 branches correspondant aux 2 environnements TEST et PROD

tous les 6 mois environ, j'ai une commande pour faire évoluer l'application, évolution décomposée en 10 à 20 modifications/ajouts de fonctionnalité,

mais parfois, certaines modifications/ajouts ne sont pas mises en prod (ou plus tard)

alors je suppose que pour rendre chaque modif/ajout indépendant des autres, je dois faire autant de branches ?

et si oui, est-ce que vous me conseillez d'abandonner la branche TEST (ne conserver que la branche PROD et autant de branches que de mini-évolution) ???

merci d'avance pour vos avis

  • # Git Flow

    Posté par (page perso) . Évalué à 4 (+3/-0).

    Bonjour,

    Tu peux jeter un œil à Git Flow

    Tu peux sans doute utiliser ce workflow pour faire tes releases, conserver chaque fonctionnalité dans une branche jusqu'à son intégration, …

    Jérôme.

    • [^] # Re: Git Flow

      Posté par . Évalué à 3 (+2/-0).

      Salut,

      Oui, git flow ça facilite bien les choses.

      Dernièrement, j'avais un environnement un peu comme ça :

      • prod
      • préprod
      • dev
        • branche A
        • branche B
        • branche C

      Donc pour chaque « feature », on partait de la dernière dev, et pushait dessus pour tester (en gros tout dev pouvait pusher sur l'infra - en prévenant bien sûr). Une fois le cycle de développement en dev fait, là ça passait en préprod (avec un dev d'astreinte). Si ça pétait pas, alors ticket pour déploiement en prod avec instructions claires pour l'équipe SRE.

    • [^] # Re: Git Flow

      Posté par . Évalué à 1 (+0/-0).

      merci, très intéressant

      à propos de git flow : je ne sais pas si ces extensions sont installées sur le dépôt de mon client, mais de par la nature distribuée de git ça ne doit pas être bloquant non ?

      je dois pouvoir l'utiliser sur mon poste pour gérer toutes les branches (pour l'instant, je suis le seul dev/mainteneur de l'appli) ?

      Envoyé depuis mon Archlinux

      • [^] # Re: Git Flow

        Posté par . Évalué à 1 (+0/-0).

        Salut,

        à propos de git flow : je ne sais pas si ces extensions sont installées sur le dépôt de mon client, mais de par la nature distribuée de git ça ne doit pas être bloquant non ?

        Non, c'est un wrapper qui t'aide dans l'usage de git, donc ce n'est pas bloquant du tout.

        A un moment, pour une raison de migration vers un repo interne, je ne pouvais plus l'utiliser (car configuration pas finie), ça m'a juste ralenti un peu en revenant à du git « de base ».

    • [^] # Re: Git Flow

      Posté par . Évalué à 2 (+1/-0).

      Personnellement, j’étais à fond sur cette méthode au début, puis j’ai été face à plusieurs autres méthodes. Dernièrement, après quelques questionnements, j’ai vérifié ce que faisait le créateur de cette méthode: il ne l’utilise sur aucun de ses repo github récents ! Et il faut les chercher les peu de repo où il a utilisé sa propre méthode.
      La seule défense que je pourrais avoir, c’est qu’il ne l’utilise que sur des repo privées professionnel d’envergure. Mais même là, j’ai un doute.
      Le plus gros problème que je vois, c’est l’utilité de la branche master. Elle ne sert qu’à lister les différentes release. Sauf que je trouve que ça ne sert à rien et c’est même pas cohérent quand on a 2 versions majeures d’une même app.

      Imaginons l’exemple d’une app en 2 versions: v2 et v3. v2 était en Node.js, et la v3 a été réécrite en Go.
      Quelle est l’idée d’avoir sur master un tag v2.1.1 suivi d’un tag v3.0.0 puis ensuite un v2.2.0 ?
      Pas du tout la même stack technique, on passe d’une branche a une stack node, vers du Go puis du node à nouveau ?
      Pour cet exemple, je vois plus chaque version majeure sur sa branche de release. Excepté, la branche en cours de développement est sur master.
      Seuls les tags garantissent une publication correcte. Le reste, c’est de l’état intermédiaire en plus ou moins bon état.

      git-graph

      • [^] # Re: Git Flow

        Posté par . Évalué à 2 (+1/-0).

        La règle, c’est d’utiliser 1 branche de release par version majeure. Ou, d’1 branche release par version déployé, si c’est un logiciel déployé chez plusieurs client avec à chaque fois des devs spécifiques non mergeable sur la master/release dédiée.

  • # Master first

    Posté par . Évalué à 2 (+1/-0).

    Le gitflow c'est très compliqué si tu es tout seul ça ne sert à rien, je préfère l'approche "Master first" où on ne créer des branches de version que si c'est nécessaire.

    En gros, tu développes dans la master tout le temps. Quand vient le moment de faire une release : tu créer un tag sur ta master et tu mets ta release en test si c'est ok tu la passes en prod.

    Puis tu continue à faire tes dev sur la master, pour la vie de ton tag c'est à toi de voir, soit tu créer la release suivante directement sur la master, si tu juges qu'elle est assez mûre pour aller en prod, sinon tu crée une branche à partir du tag et tu cherry-pick le commit de la master, souvent c'est pour corriger des petites choses urgente pendant que la master se fige.

    • [^] # Re: Master first

      Posté par . Évalué à 1 (+0/-0). Dernière modification le 15/02/20 à 14:12.

      Salut,

      Le gitflow c'est très compliqué

      Heu, je veux bien un exemple, parce que moi qui ne suis pas un cador de git, j'ai trouvé que ça me simplifiait globalement la vie, et qu'en cas de problème je pouvais quand même retourner à du git « de base ».

      Certes, je n'ai pas fait le worflow, mais sur des usages simples, je n'ai pas eu l'impression que ça représente des masses de boulot.

      En gros, tu développes dans la master tout le temps.

      Hmm, mauvaise pratique du watterfall ?

      • [^] # Re: Master first

        Posté par . Évalué à 2 (+1/-0). Dernière modification le 15/02/20 à 19:55.

        Ca s'appelle upstream first en fait, je pense que j'avais lu ça ici :

        https://docs.gitlab.com/ee/topics/gitlab_flow.html#release-branches-with-gitlab-flow

        Bonne lecture

        • [^] # Re: Master first

          Posté par . Évalué à 1 (+0/-0).

          effectivement, je suis seul (pour l'instant), donc peut-être pas intérêt à compliquer inutilement les choses

          j'aime bien ces branches release qui permettent de rapidement sélectionner une version antérieure

          mais dans ce cas, où appliquer un hotfix en urgence ?

          pas sur le master, sinon on risque de publier des choses qui ne sont pas testées/souhaitées

          si hotfix sur branche dernière release stable, comment envoyer le hotfix sur le master pour ne pas faire une régression à la prochaine release ?

          avec les tags ?
          je ne connais pas, n'est ce pas un peu dangereux (ou pénible) ???

          Envoyé depuis mon Archlinux

          • [^] # Re: Master first

            Posté par . Évalué à 1 (+0/-0).

            mais dans ce cas, où appliquer un hotfix en urgence ?

            Il faut corriger le soucis sur la master dans un commit bien identifié, puis "checkouter" le tag et créer une branche.

            Une fois sur la branche tu fais un cherry-pick du commit contenant le hotfix.

            • [^] # Re: Master first

              Posté par . Évalué à 1 (+0/-0).

              il faut donc aussi avoir une bonne gestion des TAGs

              est-ce qu'il est recommandé d'avoir des TAGs synchronisés avec le N° de version de l'application ?

              peut-on inclure des lettres dans les tags (pour distinguer les releases avec hotfix des releases normales) ou bien cela va gêner les opérations logiques dans les recherches/filtres sur les TAGS (si cela existe) ?

              Envoyé depuis mon Archlinux

              • [^] # Re: Master first

                Posté par . Évalué à 1 (+0/-0). Dernière modification le 17/02/20 à 15:22.

                Tu fais comme tu veux en fait c'est ça qui est bien avec GIT :) et ce que tu dis c'est ce que je fais, je me prend pas la tête (on fait une release toute les semaines :-))

                J'ai un numéro de build et je l'incrémente à chaque nouvelle version. Pour les hot fix, je mets une lettre à coté. La première release est appelée 851a, les hot fix suivant sont dans les versions 851b, 851c… le tout tourne sur la branche 851.

                Il faut mieux décoreller le numéro de build (utilisation technique) du numéro de version (utilisation commerciale).

                • [^] # Re: Master first

                  Posté par . Évalué à 1 (+0/-0).

                  Perso je préfixe mes version publié par vX.Y.Z en mode versionnage semantique.
                  Et sinon, tout ce que je pushe est buildé par la CI, et ces version intermédiaires sont versionnées avec le hash du commit git.

                  • [^] # Re: Master first

                    Posté par . Évalué à 1 (+0/-0).

                    Moi je ne build que sur tag parce chaque release fait 1GB ;-)

                    • [^] # Re: Master first

                      Posté par . Évalué à 1 (+0/-0).

                      Salut,

                      Moi je ne build que sur tag parce chaque release fait 1GB ;-)

                      Mouaif, avec un disque d'1To t'as de la marge…

                      • [^] # Re: Master first

                        Posté par . Évalué à 1 (+0/-0).

                        J'aime faire autre chose que l'ops, du coup, le gitlab il est hébergé dans le cloud, le GB y est plus cher :)

    • [^] # Re: Master first

      Posté par . Évalué à 2 (+1/-0).

      carrément, c’est vraiment ce que je reproche.
      Sur le papier, ça a l’air assez simple, mais une fois à gérer au jour le jour avec des merges à droite à gauche, ça devient vite le merdier.

      • [^] # Re: Master first

        Posté par . Évalué à 1 (+0/-0).

        On fait ça depuis 6 mois dans l'équipe (5 personnes) et ça se passe bien. Rien n'empêche de faire des branches avec rebase régulier si on fait des gros changements :)

        • [^] # Re: Master first

          Posté par . Évalué à 1 (+0/-0).

          Je n’ai pas été assez explicite, je disais que je reprochais à gitflow la même chose que toi.
          Et je suis aussi a vraiment plutôt faire du master first, avec une branche de feature/fix plutôt temporaire pour éviter les rebase/merge violent lorsqu’on se resynchro.

  • # git flow + releases

    Posté par . Évalué à 1 (+0/-0).

    Salut?

    Je suis également seul dev dans ma structure, j'utilise git flow. Il me permet de jongler avec les différentes features / bugfix…

    Pour le déploiement, j'utilise des tags sur la branche master pour la PROD, et la branche "develop" brute pour la pré-prod (STAGING). La préprop peut casser, mes utilisateurs sont au courant :)

    Le processus de déploiement est "à la demande": j'ai un rôle ansible qui fait le taff quand j'en ai besoin, avec un script maison deploy.sh qui n'est qu'un lanceur pour le rôle ansible.

    Du coup, j'utilise pour mettre en prod :

    • git flow release start <version>
    • Bump version numbers vers > (y compris les vars ansible pour la prod !)
    • git commit (dans la branche release/)
    • git flow release finish
    • ./deploy.sh << Vers la pré-prod
    • ./deploy.sh -m PROD << Vers la prod

    L'avantage de cette approche, c'est que je peux à tous moments pousser vers la staging (branche develop), mais que je ne peux pas pousser "par accident" dans la PROD.

    Le process est à la fois contraignant mais pas trop, et avec le rôle ansible, je n'oublie rien.

    Je déploie environ 20 projets différents avec cette méthode, et j'en suis très satisfait.

    Ah, et j'ai un script python pour faire les montées de version:

    https://pypi.org/project/bump-release/

    Ce script ne fait que mettre à jour les numéros de version dans différents points du projet (main, docs, ansible vars pour récupérer le bon tag quand je déploie), il ne fait rien avec GIT.

    Pour info, je fais quasi exclusivement du Django / python…

    • [^] # Re: git flow + releases

      Posté par . Évalué à 1 (+0/-0).

      salut
      et ton script deploy.sh envoie en pré-prod (par défaut) uniquement les fichiers modifiés ou bien il envoie toute la branche release ?
      (par ftp ?)

      Envoyé depuis mon Archlinux

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.