L'agence
WanadevStudio
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.
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
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
-
Tests automatiques fonctionnels d’applications 2D/3DIl y a 11 mois
Comme nous le disions dans cet article, l’automatisation des tests dans le développement logiciel est indispensable : dès lors qu’une application commence à avoir un minimum d’importance, les tests automatiques permettront de gagner énormément de temps en évitant de reproduire ad vitam æternam les mêmes tests manuels, et éviteront beaucoup de régressions. Dans cet article, nous allons présenter différents types de tests automatiques dans le cadre plus spécifique d’applications 2D/3D, puisque c’est ce que nous faisons ! Cela va du test basique qui clique sur 3 boutons aux tests de plusieurs minutes reproduisant les actions comme un véritable utilisateur. Accrochez-vous, c’est parti !
-
Configurateur web à l'abonnement : forces et faiblessesIl y a 12 mois
Aujourd’hui, si vous cherchez à mettre en place un configurateur sur votre site, deux grandes possibilités s'offrent à vous : les solutions par abonnement (du type SaaS) ou le développement sur mesure. Au premier abord, les solutions semblent proches, mais les enjeux sur le long terme eux, sont bien différents.
-
Les frameworks front, tous les mêmes !MéthodologieIl y a 1 an
C'est une phrase que j'ai osé sortir un jour dans la salle de pause de Wanadev. Je ne sais plus exactement avec quel collègue je discutais, j’essayais de le rassurer, il possédait déjà une certaine expérience avec React et allait devoir, en arrivant sur le projet sur lequel je travaille, se mettre à Vue.
Il a malheureusement fallu qu'un autre collègue de passage nous entende pour ne pas trouver la conversation inintéressante et suggérer que j'en fasse un petit talk pour nos réu du lundi. Et, de fil en aiguille, me voilà en train d'en faire un article de blog. Comme quoi, note pour moi-même, il faut toujours se méfier des discussions dans les salles de pause. -
[NOVEMBRE 2021] C'est la gazette de Wanadev !MéthodologieIl y a 1 an
Retrouvez ici les informations et actus du mois de novembre de l'Agence! Au programme de cette édition : découvrez le configurateur de fenêtre développé pour Caseo, recontrez François Deleglise, notre directeur communication et un nouvel espace de jeu pour les professionnels du loisir en VR. Bonne lecture !
-
Un peu d'ingérence dans votre infogérance ?MéthodologieIl y a 2 ans
Même si les impacts sont difficiles à mesurer, on peut dire qu’il a eu un avant et un après incident OVH. Sans épiloguer sur l'incendie du 5 mars 2021 dernier, un petit vent de panique a soufflé sur les milliers de clients découvrant les problématiques de sécurisation des données. Les réactions à chaud d'une partie des utilisateurs (touchés ou non) montrent la méconnaissance et l'incompréhension qui existent dans les offres d'hébergement. Qui est responsable ? Qui fait quoi ? Comment vérifier mon offre ? Voici quelques clés de compréhension.
-
Améliorer la qualité avec les tests et la reviewIl y a 2 ans
L’importance des tests et de la revue de code dans le cadre du développement logiciel est parfois négligée ou passée au second plan. Cet article a pour but de montrer que les tests logiciels constituent une étape cruciale qu’il faut considérer avec beaucoup de rigueur.
Commentaires
Tartare2240
Il y a 7 ans
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 Deleglise
Il y a 7 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 !