Workflow de gestion de versions orienté User Story avec Git

Ce billet  présente un workflow de contrôle de versions mis en oeuvre avec succès au sein d’une équipe de développement Agile/Scrum de 5 Développeurs en charge des évolutions, de la maintenance et des nouvelles fonctionnalités d’un système d’information.

L’intérêt de la démarche qui a conduit à la mise en place de ce workflow était d’atteindre les trois objectifs suivants:

  • La rigueur: compte tenu de la nature critique du système d’information pour le modèle économique de l’entité dans laquelle nous évoluions;
  • Souplesse et réactivité: compte tenu d’un contexte métier qui évolue constamment et rapidement;
  • Agilité: compte tenu de la méthodologie Scrum adoptée par l’ensemble des équipes de la direction technique.

Ce workflow est dit “story centric”  car il repose sur une gestion des branches qui, pour chaque user story  traitée, crée une branche Git. A cette fin nous avions défini trois types de user stories  et donc autant de types de branches Git :

  • Les user stories de fonctionnalité (Features);
  • Les user stories de déploiement en production (Releases);
  • Les user stories de corrections à chaud (Hotfixes).

1. Une histoire de branches et de cimes

Les branches principales

  • Master: le code qui est livré en production;
  • Integration: livraison des derniers développements.

La branche origin/master est celle dont la cime (head) est toujours en état d’être déployée sur la production. Le contenu de la branche master est toujours le même que celui qui est exécuté en production. La  seule exception à cette règle apparaît lors de la fusion des branches au début du processus de mise en production.

La branche origin/integration est celle dont la cime est le résultat des livraisons et fusions des derniers développements effectués pour la prochaine livraison en production.

Ces deux branches sont parallèles l’une à l’autre. Ce n’est que quand la cime de la branche intégration est considérée comme stable et prête à être déployée en production que l’ensemble des changements qui ont été livrés sont fusionnés dans la branche master.

Les branches de user stories

  • les branches de fonctionnalité: développement d’une nouvelle fonctionnalité;
  • les branches de correction: correction d’une anomalie critique en production;
  • les branches de déploiement: préparation du déploiement de hotfixes ou de features.

Chacun de ces types de branches ne vivra que le temps d’atteindre l’objectif qui lui est fixé : le suivi du développement d’une fonctionnalité  le suivi du développement d’une correction répondantà une anomalie critique constatée en production et enfin contribuer au déploiement maîtrisé de nouvelles fonctionnalités et/ou de corrections en production.

2. Branches de fonctionnalités

Les branches de fonctionnalités sont utilisées pour le développement de nouvelles fonctionnalités qui seront incluses dans la prochaine release si elles remplissent les conditions d’acceptation définies dans les user stories correspondantes. La branche ainsi créée ne vivra que le temps nécessaire au développement de la fonctionnalité. Une fois le développement terminé celle-ci est fusionnée dans la branche  d’intégration ou si la fonctionnalité n’a plus sa pertinence, la branche est tout simplement close.

Les contraintes sur la création et le merge de cette branche sont les suivantes:

  • elle doit être créée à partir de la branche d’intégration;
  • son nommage doit répondre à une convention propre au projet ou à l’équipe (exemple: NomFeature-Ticket#NumeroTicket);
  • à la fin du développement la branche est fusionnée dans la branche d’intégration.

En pratique

Création de branche

Fusion de la branche

Le flag no off est utilisé afin de créer  un “commit” à chaque fois qu’on fusionne une branche de feature dans la branche intégration ce qui permet de conserver l’historique du développement de la fonctionnalité qui est en train d’être fusionnée. Cela peut s’avérer très utile lors d’un retour en arrière après une revue de sprint par exemple.

3. Branches de corrections à chaud

Les branches corrections à chaud ont ceci de particulier qu’elles ont vocation à préparer un déploiement d’un développement en production non planifié mais rendu urgent par l’apparition en production d’une anomalie de niveau critique.  La création de cette branche se fait donc depuis la branche master qui comme indiqué précédemment, doit être identique au code qui est exécuté en production.

L’utilité de cette branche et de permettre à l’équipe de continuer son travail habituel pendant qu’un de ses membres développe la correction de l’anomalie critique rapportée. Il est important  de noter que contrairement aux branches feature, les branches hotfix sont effacées en fin de cycle de développement.

En pratique

Création de la branche de correction à chaud

Commit de la correction

Fusion de la correction dans les branches master

Fusion de la correction dans les branches  intégration

Effacer la branche de correction à chaud

4. Branches de déploiements

La branche de déploiement a pour objectif d’accompagner le déploiement en production de l’application en permettant les corrections et ajustements de dernières minutes quand cela s’avère nécessaire sans impacter le branche d’intégration et la branche master.

La branche de release est créée à partir de la branche d’intégration quand celle ci est jugée assez stable pour un déploiement en production. Elle permettra de vérifier que chacune des fonctionnalités sont conformes aux attentes définies dans les conditions d’acceptante et d’effectuer les éventuelles corrections nécessaire. Le nommage de la branche de déploiement sera déterminant dans le nommage de la version qui sera déployée en production et devra donc à se titre respecter la convention de nommage des versions du projet.

Pendant le cycle de vie de la branche de release courante, il est possible de lui ajouter des corrections d’anomalies ou de fusionner une branche de correction à chaud. Il est par contre déconseillé d’y fusionner des branches de features en contournement de la branche d’intégration.

Exemple de nommage: production#numerodeversion

En pratique

Créer la branche de déploiement

Fusionner la branche dans la master pour effectuer le déploiement

Fusionner la branche de déploiement dans la branche d’intégration

Effacer la branche de déploiement courante après déploiement

5. Lead Developpeur ou préposé à l’aiguillage de versions ?

Dans la pratique, la mise en oeuvre de ce workflow dans le cadre de la méthodologie agile Scrum adoptée  par l’équipe, a placé au centre du modèle de développement le Lead developpeur à qui incombaient les actions les plus critiques du workflow: les fusions des branches de fonctionnalité, de déploiement ou de correction à chaud  dans la branche d’intégration et/ou la branche master.

Un exemple: suivons le parcours depuis son développement jusqu’à son déploiement, d’une nouvelle fonctionnalité

  1. Un développeur se voit assigner une user story via un ticket Redmine
  2. Le développeur crée une branche de fonctionnalité qu’il nomme feature-ticket#75009
  3. Le développeur développe les fonctionnalités  sur la branche créée
  4. En préparation de la revue de sprint le Lead developpeur rassemble les branches de fonctionnalités concernées et effectue la fusion de ces branches dans la branche d’intégration
  5. Une fois la fusion des branches terminée, le Lead developpeur crée un Tag sur la version d’intégration #srpint-review-nom_du_sprint
  6. L’exploitation prend la main et déploie sur le serveur d’intégration
  7. Si la revue de sprint valide la version pour un déploiement en production,  le Lead developpeur crée un branche release
  8. Les corrections relatives à une validation finale sont effectuées
  9. Le Lead developpeur fusionne la branche de release dans la branche master  et la branche d’intégration qu’il tag avec le nommage approprié dans les deux cas.
  10. L’exploitation reprend la main et effectue le déploiement en production

J’ai opté pour le principe de l’aiguilleur parce qu’il me fallait en qualité de Lead Developpeur très vite acquérir une vue complète d’un système d’information très complexe et de ses évolutions. Adopter un tel positionnement m’a permis d’acquérir et de conserver une vue aérienne très pointue de l’ensemble du système d’information.

6. Synthèse et vue schématique

Le workflow Git décrit dans ce billet a été construit en regroupant les points positifs des retours d’expériences de développement de chaque membre de l’équipe. De plus, le modèle a été  affiné au fur et à mesure de sa mise en œuvre dans le contexte technique et métier qui était le nôtre. Suite à sa mise en oeuvre, voici les améliorations qui ont été constatées:

  • Une plus grand maîtrise des déploiement des corrections à chaud dont le coût en ressources et charge horaire ont été considérablement réduits parce qu’ils ne paralysaient plus l’ensemble de l’équipe;
  • Réduction du time-to-market des nouvelles fonctionnalités dont l’isolation au sein d’une branche Git individuelle permet de mieux en cerner les problèmes et de les corriger lors du cycle développement agile sans paralyser les développements en cours;
  • Associé à une stratégie de tests de unitaires et fonctionnels très rigoureux, il a été possible grâce à un hook sur la fusion d’une branche release ou  hotfix vers la branche master de mettre en oeuvre un système de déploiement continue.

In fine, c’est un cadre de travail sur lequel il est possible de bâtir un modèle de développement approprié au contexte métier,  à la taille et la structure de l’équipe et enfin à la méthodologie projet mise en oeuvre.

Share
Exuper OKOUYA
Exuper OKOUYA

2074

Comments

  1. Excellent, ca fait du bien un bon récap comme ca ! Y a tellement de facons de fonctionner avec git, qu’on s’y perds de temps en temps 😉 A+

  2. Exuper Ok Says: April 10, 2013 at 3:45 pm

    Oui en effet autant d’équipe que de workflow sur Git et si ce workflow n’est pas décidé à l’avance ou si il n’est pas réellement intégré au cycle de développement de l’équipe de développement ça peut très vite tourner à la petite catastrophe… Un workflow Git inexistant ou mal pensé sous git est beaucoup plus impactant que sous svn 😉

  3. Je vous remercie pour cet article et surtout la démarche suivie et j’ai quelques questions:
    – Est ce qu’on peut considérer la branche Integration comme la branche Sprint pour être conforme à la méthode Scrum?
    – Quelles sont parmi les branches que vous avez décrites, vont être crées localement (machine développeur) et celles à créer dans le dépôt central
    – pour chaque branche décrite, Qui va la créer chaque branche et qui va la merger?
    Merci d’avance.

  4. Exuper Okouya Says: May 28, 2016 at 12:24 pm

    “Est ce qu’on peut considérer la branche Integration comme la branche Sprint pour être conforme à la méthode Scrum?” Oui on peut considérer labranche d’intégration comme celle qui doit regrouper l’ensembles des dévelopments du sprint etqui peut etre ainsi déployé sur des environnements de recette, tests, démo etc…

    “Quelles sont parmi les branches que vous avez décrites, vont être crées localement (machine développeur) et celles à créer dans le dépôt central” Git est un system de versioning distribué, il n’y pas de dépot central contrairement à svn.

    “pour chaque branche décrite, Qui va la créer chaque branche et qui va la merger?” Cela dépend du fonctionnement de l’équipe, il peut y avoir un ou deux seniors dont l’équipe qui endossent cette responsabilité, on peut automatiser le merge lors du déploiement, on peut aussi considérer que tous les membres de l’équipe sont habilités à merger une fois que tous les tests passent au vert.

Leave a Reply

Your email address will not be published. Required fields are marked *