Retour d'expérience : notre utilisation de Git sur un gros projet

Git, l'incontournable outil de versioning : nous l'utilisons sur chacun de nos projets. Manier Git au sein d'une équipe complète demande rigueur et discipline. Dans cet article, nous allons détailler comment nous nous organisons sur un gros projet à fortes contraintes techniques.

Attention, cet article date de plus de 2 ans maintenant... Il est possible que les infos publiées ne soient plus correctes aujourd'hui...

L'obligation de structurer son workflow avec Git

Quand nous travaillons seuls, nous sommes souvent tentés de se laisser aller : ne travailler que sur la branche Master, faire 3 commits par semaine et pusher tous les 4 matins.

En équipe, cette mauvaise habitude vous fera vous arracher les cheveux (ou ceux de vos coéquipiers) sous le poids des conflits permanents qui vont tomberont sur le bec. Vous pouvez me croire : je suis bientôt chauve.

Les conflits sont le désagrément le plus criant, mais pas le plus problématique : le manque de traçabilité du à une mauvaise organisation d'un workflow Git sera douloureux à un moment donné.

L'intérêt principal de Git, c'est le versioning : pouvoir remonter le temps, étape par étape, commit par commit, pour revenir à des versions antérieures, et surtout stables.

Comment imaginez-vous pouvoir assurer des rollbacks sécurisés sans rigueur dans votre organisation ? Regardons ensemble ce que nous avons instauré sur nos projets.

Cas concret de workflow Git : l'équipe Kozikaza.com

Cet exemple relate notre expérience et notre fonctionnement, mais il est certain qu'il existe de nombreuses autres excellentes façon d'organiser un workflow Git. Chaque équipe, chaque projet, chaque environnement définit son propre corpus d'éléments amenant à de nombreuses autres judicieuses organisations.

Chez Wanadev, un groupe technique composé de 4 à 6 personnes (en fonction de la charge ou de la nature des travaux) se concentre sur les développements et évolutions de la plateforme dédiée à la maison. Une seconde équipe de taille similaire basée à Lille s'occupe de la gestion de la communauté, et l'organisation générale de la plateforme.

Au fil des années et des nouveautés, nous avons, entre autres grâce à la méthode KaiZen, en permanence remis en question nos fonctionnements pour toujours améliorer nos méthodes de travail... dont notre workflow Git.

Pour cette plateforme à fort trafic, il est impératif que toutes les personnes qui œuvrent à son bon fonctionnement travaillent de façon organisée.

Notre organisation Git

Workflow git

Branche Master : c'est notre branche la plus basse, la plus stable. C'est aussi celle qui est câblée en production. Personne ne peut pusher dessus, elle est protégée, seule une procédure de mise en production permet une mise à jour de la branche.

Branche Develop : c'est la branche la plus stable après Master. Elle est mise à jour lorsque les développements sont terminés, c'est notre branche de tests finaux, celle qui est notre témoin, notre répétition générale. Cette branche est câblée sur notre preproduction.

Branche v5rX/develop : V5, pour la 5e version de la plateforme, X étant le numero de la release sur laquelle nous travaillons. En ce moment, nous en sommes à la v5r20/develop. Cette branche est celle correspondant aux travaux en cours. Notre serveur de dev est câblé sur cette branche pour valider les sprints et développements en cours.

Enfin, la branche v5rX/Y correspond à une feature développée en ce moment. Par exemple : v5r20/preview_notif. Cette branche est accessible en local, elle est très rarement mise à disposition d'un serveur de preproduction.

Les hotfix

Parfois, malgré tous nos efforts, des petites coquilles restent et il faut patcher la prod. Evidemment, ce cas doit se présenter le moins souvent possible, mais quand il faut... il faut !

Une fois le fix développé, testé et retesté (sur la branche develop), la procédure de hot fix peut être lancée. Nous mergons ainsi la branche Develop sur la branche Master (puisque Develop est saine).

Un workflow n'est jamais parfait et il est toujours améliorable

C'est aujourd'hui ce workflow qui convient à nos sprints de développements. Il sera sans doute modifié dans la continuité du projet, pour qu'il soit toujours en adéquation avec les demandes et équipes en place.

Vous êtes invités à réagir à cette organisation en nous interpellant en commentaire ou bien sur Twitter : vos réactions nous intéressent et elles feront sans aucun doute évoluer nos façons de travailler ;-) !

Sources et compléments

Tags de
l'article

git

Catégories de l'article

Méthodologie

Commentaires

Tartare2240

Il y a 2 ans Répondre

Bonjour,

Sujet vraiment très intéressant, surtout pour quelqu'un qui, comme moi, utilise GIT sur un projet développé seul pour ne pas "perdre ses sources" en cas de gros problème et pour faire un petit peu de versionning. Ensuite, est-ce que ce n'est pas peut-être un peu trop profond pour les petits projets, ou alors c'est juste une habitude à prendre ?

François

Il y a 2 ans

Bonjour Tartare, merci pour ton commentaire !

En effet, c'est une habitude à prendre ! En milieu professionnel, tu verras que cette discipline (qui au final est beaucoup plus simple à mettre en place que ce que l'on pense) sera vraiment apprécié de tes confrères (clients, collègues, successeurs...).

En vrai, c'est vraiment rapide... Créer des branches, les fusionner, les supprimer. Comme ça, ça a l'air d'être un process très actif, mais au final, c'est loin d'être contraignant :-) !

Si le projet sur lequel vous travaillez n'est pas encore en ligne, vous pouvez éventuellement vous éviter une hauteur de branche. Cependant, quand le projet entrera en phase d'évolution avec une version stable en ligne, il sera alors vraiment important de conserver cette stabilité en multipliant les sécurités : et le processus indiqué dans l'article fait l'affaire, pour l'instant !

Articles liés