Workflow Integration-Manager avec Git

Vous avez probablement pu voir dans la littérature, si vous êtes un Git-fanboy intéressé par Git, différents workflows décrivant une utilisation possible de Git en équipe, mais peu de concret expliquant comment les mettre en place.

Dans le projet sur lequel je travaille, nous sommes passés à Git en début d’année. Nous avons commencé par un workflow centralisé, avec un bête dépôt central, avec la configuration suivante :

  • un dépôt distant hébergé sur un serveur interne
  • un compte SSH unique pour accéder à ce dépôt

Par la suite, des stagiaires nous ont rejoints, et nous avons dû changer de méthodologie. Afin de garantir la qualité du code déployé et de faire monter en compétences nos nouvelles recrues, nous avons trouvé que le workflow Integration-Manager de Git convenait mieux :

Workflow Integration-Manager , ProGit

Workflow Integration-Manager , ProGit

En ce qui concerne l’implémentation, ProGit suggère d’avoir un dépôt privé (aka sur le poste développeur) et un dépôt public (aka distant) par développeur. Ce mode de fonctionnement ne nous convenait pas, car il n’était pas pratique d’avoir autant de dépôts sur le serveur, compte tenu du fort turnover que nous avons sur l’équipe.

De plus cette approche implique que l’intégrateur sache pour chacun des développeurs quelle branche intégrer (parfois le master, parfois une branche de maintenance, parfois une branche dédiée à l’évolution,…) , ce qui devient vite pénible à gérer.

La flexibilité de Git en ce qui concerne le stockage des commits nommés (branches locales, distantes et tags) nous a permis de résoudre ce problème élégamment.

En effet, Git stocke dans le dossier refs un certain nombre de fichiers représentant la position de chacune des branches et des tags; ces fichiers sont nommés suivant le nom de la branche/tag, et ne contiennent que le hash du commit correspondant.

Un bon exemple valant mieux que le meilleur des discours :

 

1
2
3
4
5
6
$ git log --format=oneline --graph --decorate
* 997732e7b4e054ab65da092937d2a4b7ab58302e (HEAD, origin/master, origin/HEAD, master) suppression des seuils de des controles checkstyle.
* cf4627c9cb1ae04cf9a4f5e530ada5d2c951410a Correction bug des suppressions aleatoires lorsqu'un groupe à le meme nom qu'un autre

$ cat .git/refs/heads/master
997732e7b4e054ab65da092937d2a4b7ab58302e

 

Partant de ce fait, il est possible de créer des namespaces au sein du dossier refs pour isoler certaines informations, comme par exemple les branches privées d’un développeur, ou un espace de validation.

Voici un diagramme représentant l’organisation de notre dépôt distant suite à la mise en place du nouveau workflow :

Workflow Integration-Manager customisé
Workflow Integration-Manager customisé

Coût de la mise en place de ce workflow : quelques lignes dans le fichier .gitconfig de chacun, et c’est tout!!

[remote “origin”]
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/devel/<login>/*:refs/remotes/origin/<login>/*
fetch = +refs/merge-requests/*:refs/remotes/origin/merge-requests/*
push = +refs/heads/*:refs/devel/<login>/*

 

En rouge est affiché ci-dessus la config à changer par développeur, et en vert la ligne à rajouter pour l’intégrateur. Simple, non?

A l’utilisation, on fait toujours des git pull, git fetch, git push sans arguments particulier, Git effectuera automatiquement les mises à jour des branches locales par rapport aux branches validées, et le push enverra automatiquement les branches dans l’espace propre au développeur.

En ce qui concerne l’intégrateur, il récupère automatiquement les demandes de merge, les intègre dans sa branche locale et si c’est OK, les envoie sur le dépôt distant avec la commande suivante : git push origin master:refs/heads/master (master étant bien évidemment à remplacer par la branche adéquate); et l’intégrateur malin se fera un petit alias pour éviter d’avoir à retaper tout ça à chaque fois :p

En fonction des projets, on peut aussi imaginer avoir un serveur d’intégration qui traite les demandes de merge et qui se charge entièrement de l’intégration…

On en reparle maintenant dans quelques semaines, pour voir si la mayonnaise prend ou pas :)

 

VN:R_U [1.9.22_1171]
Rating: +1 (from 1 vote)
Share
Ce contenu a été publié dans Outils, avec comme mot(s)-clef(s) . Vous pouvez le mettre en favoris avec ce permalien.

7 réponses à Workflow Integration-Manager avec Git

  1. Intéressant ! Par contre je m’interroge : avez-vous mis en place des droits d’accès différents suivant les profils ? Du genre, un développeur peut-il pousser sur une branche qui ne lui appartient pas si l’envie lui en prend ? Est-ce basé sur la bonne volonté, ou sur un modèle de sécurité bien défini ?

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. mgrenonville@excilys.com dit :

    Excellent !

    En travaillant avec un build incassable sur serveur d’intégration continue, nous n’utilisons pas de sécurité particulière (ie. tout le monde peut pusher sur master si ça le chante). Bien entendu, une sévère punition s’impose lorsqu’un malheureux pousse ses modifications directement sur master (et non sur sa branche )

    Après, il doit être possible de rendre plus sécurisé le tout en utilisant des hooks git sur le serveur.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. Joan Zapata dit :

    En ce qui me concerne, je n’ai jamais utilisé Git avant d’arriver dans le projet, et je trouve que ce workflow est très pratique à l’utilisation. Ça nous permet très facilement de récupérer le travail de quelqu’un d’autre qui n’a pas encore été pushé sur le master, et ce sans avoir à connaître leur IP / le chemin vers leur repo / etc…

    C’est d’ailleurs un des plus gros avantage je trouve, le partage. Si je pars en vacances pour deux semaines, le push étant devenu un acte assez “anodin” je le fais le soir avant de partir et n’importe qui peut le récupérer facilement le lendemain s’il le souhaite. Pas besoin de créer une branche “vacances-joan” ou “evol-pas-finie” sur le repository distant !

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. agoulamhoussen@excilys.com dit :

    @Piwaï :
    J’ai volontairement occulté ici l’aspect “sécurité”, car cela me semblait alourdir l’article :p .
    Je pense qu’il est possible de sécuriser ce système à coup de compte utilisateurs SSH restreints en écritures sur certains dossiers (par ex seul le validateur aurait le droit d’écrire dans le dossier refs/heads du dépôt distant) mais ayant accès en lecture à tout le dépôt.

    Pour moi, la sécurité ne rentre pas en compte pour la mise en place d’une telle solution dans le cadre d’un projet d’entreprise (open-source par contre, complètement); à mon sens, ca serait plus pour éviter les boulettes qu’autre chose…

    Et juste pour rappel, à partir du moment où un développeur à accès à un dépôt SVN, CVS ou autre, il est en mesure de modifier n’importe quelle branche également (et même faire développer dans un tag, brrr , quelle horreur)…

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. @Alnour J’ai déjà vu des dépots SVN avec gestion de droit par dossier… c’était dailleurs particulièrement moche : un méga dépot svn pour tout le monde, et chaque projet a un dossier dédié et les droits d’accès sur ce dossier… Horrible.

    Sinon, j’ai une question qui me vient à l’esprit (/me = git noob) : vous faites systématiquement des “git pull”, ou bien des “git fetch / git merge” ? C’est bien pratique, mais d’un autre côté jme rend compte que merger systématiquement est loin d’être une solution. Je pense notamment au cas où deux personnes travaillent sur la même branche => en général, on préfère un rebase à un merge, en terme de graphe ça a plus de sens…

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • agoulamhoussen@excilys.com dit :

      git pull étant l’équivalent d’un git fetch suivi d’un git merge, je dirais ni l’un ni l’autre ^^ . J’utilise git pull –rebase ( qui est l’équivalent de git fetch suivi de git rebase) quasiment tout le temps pour me mettre à jour.

      Les seules occasions en 4 mois d’utilisation où j’ai utilisé le merge c’était pour réintégrer la branche de maintenance sur le master (et la moitié du temps j’ai préféré utiliser le cherry-pick plutôt que le merge…)

      VN:R_U [1.9.22_1171]
      Rating: 0 (from 0 votes)
  6. Ok !

    Mais du coup, cela signifie-t’il que tu sais d’avance si tu devrais plutôt faire “git pull”, ou “git pull –rebase” ? Par exemple en regardant les changes via une interface web avant de puller ? Ou bien tu considères que tu as essentiellement besoin de rebase, et si jamais tu te rends compte qu’il aurait fallut merger tu reviens en arrière ?

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire