Agile Brown Bag : Source code management and branching strategies for continuous delivery

AgilePartner

Agile Brown Bag : Source code management and branching strategies for continuous delivery

ABB

Pour cet Agile Brown Bag du 18 septembre, la salle a fait comble : pas moins de 26 collaborateurs! Il faut dire que le sujet avait de quoi drainer des foules étant donné que c’est une problématique que nous rencontrons dans la quasi-totalité des projets chez nos différents clients et ce, peu importe la technologie ou la plateforme utilisée. Il s’agit de : « Source code management and branching strategies for continuous delivery ».

Le but de cette rencontre était de discuter des différentes pratiques autour de la gestion du code source, de l’intégration continue et des stratégies de branching. Le tout, en prenant en compte les différents contextes clients, les expériences des uns et des autres et enfin des recommandations que l’on trouve dans les « white papers » (patterns, bonnes pratiques,…)

 

D’entrée de jeu, Sylvain a posé plusieurs questions :

  • Quelle stratégie de branching utiliser ?
  • Quelles règles de gestion de code source utiliser ?
  • Quand déployer ? Comment déployer ?
  • Expérience des uns et des autres?

Cédric nous a rapidement présenté le guide de branching et versionning de Microsoft.

« Feature branches » VS « Release branches »

L’idée derrière la notion de « feature branches » est celle de créer une nouvelle branche à chaque fois qu’une nouvelle fonctionnalité est créée. Ensuite, celle-ci est réintégrée dans la branche principale une fois la fonctionnalité terminée. Un des avantages est que les développeurs sont complètement isolés du reste des développements en cours. Tandis que l’inconvénient est le nombre important de « merges » à faire lors de l’intégration des nouvelles fonctionnalités.

Pour les « release branches » par contre, l’équipe crée une branche avant une release planifiée afin de stabiliser le code qui va être déployé. Une fois la release effectuée, le code est réintégré dans la branche principale.

Nous avons parlé de patterns connus comme le « Trunked based development » solution efficace de gestion de code source dans le cas où tous les développeurs travaillent sur une branche partagée (qui est communément appelée le « trunk »).

Les outils

Nous avons eu la présentation de différents outils:

  • une belle présentation de Jérémy sur GitFlow (les cheatsheets ) qui est utilisé chez le client atHome
  • une présentation de Git par Florent utilisé pour Goblinshark
  • des remarques à propos d’outils d’intégration continue comme CruiseControl, TFS, Jenkins…

Nous avons eu aussi la mention comme quoi certains outils de versionning permettaient de mettre en place un « Pull request » avant d’accepter le « merge », après un contrôle « humain ». Il est aussi possible d’ajouter des tests automatisés avant d’accepter le « merge » (constitue une sorte de « code review »)

Les participants ont ensuite abordés le sujet sur le coût d’un « merge ». Un « merge » a toujours un coût dû au fait qu’il peut ralentir les développements en cours, qu’il peut nécessiter beaucoup de temps et rendre le système instable. L’équipe doit définir la meilleure politique de « merging » en prenant en compte le contexte organisationnel, la taille du projet, le type de projet, le type d’équipe, l’organisation de l’équipe(off-shore ou sur site ?), la structure du projet…. On peut par exemple dire qu’une fonctionnalité ne peut être mergée que si elle est à « DONE »

Cédric a fait une présentation de la stratégie de branching utilisée chez POST (Courrier, Technologies) et chez Dennemeyer (avec l’approbation des consultants qui s’y trouvent). Yannic Langlois nous a parlé du cas du Crédit Suisse. Adrien nous a parlé d’un cas spécial qu’il a rencontré (prise en compte d’un projet de type ‘Common’). Nous avons défini le cas le plus simple de versionning (branche unique). Maxence nous a parlé de la réactivité lors de l’intégration continue. Cédric a enfin parlé d’intégration continue et de tests.

Sylvain a posé la problématique de la gestion des bases de données. Comment assurer le versionning d’une DB ? Tous les participants ont parlé de scripts qui étaient mis à jour et versionnés dans le même outil de versionning que le code.

Après presque 1 heure 30 de discussions constructives et intéressantes, la séance s’est achevée même si le débat n’est pas encore terminé. La réflexion sur la gestion du code source n’est pas prête de s’arrêter, car les outils et les pratiques évoluent toujours.

 

Damien Visca

Marketing / Communication

No Comments

Post a Comment

Comment
Name
Email
Website