P22 - Qualité de développement

3 - Git collaboratif

Adrien Krähenbühl IUT Robert Schuman

Résumé du 1er épisode…

… et du second

git branch, git switch, git pull, git push, …

Les strategies de branchement

Qu’est-ce qu’une stratégie de branchement ?

Une stratégie de branchement est une convention d’organisation et d’utilisation d’un dépôt Git par une équipe de développeur.


Autrement dit, détermine qui committe et quand.

Objectifs :

  • Faciliter l’intégration de nouvelles fonctionnalités
  • Minimiser les conflits de code
  • Automatiser et simplifier les tests te le déploiement

Trunk-based development - TBD

+ Conflits plus faciles à résoudre
+ Code toujours prêt à être déployé
- À réserver aux dév. expérimentés
- Pas de review du code

  • La branche principale est appellée trunk
  • Tous les développeurs mergent directement sur trunk
  • Les branches doivent être régulièrement mises à jour par rapport au trunk

Github flow

+ Adapté aux petites équipes
+ Déploiement rapide et continu
- Risques de bugs sur la branche principale

  • Les features-xxx sont vérifiées (pull-request) avant d’être fusionnées sur la branche principale
  • La branche principale est mise à jour plus régulièrement.

Git flow

  • Branche main : versions fonctionnelles du projet (production)
  • Branche develop : version en cours de développement
  • Branches feature-xxx : branches éphémères dédiée à une nouvelle fonctionnalité
  • Branche release : préparation des releases

Comparatif

TBD Github flow Git flow
Ramification légère légère importante
Branche de déploiement main feature-xxx release
Timing du deploiment merge dans main pull-request approuvé cycle de release
Branche stable main main main
Rythme des livraisons continue continue chaque release
Effort de fusion faible faible important

Quelques liens

Comparatifs


GitHub Flow

Bonus : GitLab Flow

Merge-requests

Qu’est-ce que c’est ?

Une “merge-request” (aussi appellée “pull-request”) est un mécanisme de demande de fusion de branches.

C’est géré via une interfaces web pour assurer la revue du code avec :

  • une decription de la requête
  • une vue des modifications du code
  • des commentaires que peuvent laisser les développeurs

Pipeline de fusion avec une merge-request

  1. Une branche feature-xxx est créée en se basant sur la principale.
  2. Des commit sont ajouté à la branche feature-xxx, localement.
  3. Les commit sont “pushés” sur le remote
  4. Une “merge-request” est créée pour démarrer la discussion et recevoir des feedbacks sur les modifications apportées.
  5. Les relectures sont essentielles.
  6. Une fois que les relectures sont terminées, la “merge-request” doit être approuvée par quelqu’un.
  7. La branche feature-xxx est fusionnée avec la branche main

Démonstration






Intégration continue automatisée

L’intégration continue permet de vérifier que des modification du code n’entrainent ni bug ni regression de code.

C’est un ensemble de tâches automatisées qui peut comprendre des compilations, des tests (par exemple avec JUnit), des déploiement, etc.

Ces tâches sont souvent exécutées à la création d’une “merge-request” dans des environnements préparés en amont par les développeurs.

Exemple






Mise en œuvre
dans le projet

Utiliser pour automatiser

L’un des objectif du projet, non évalué, consiste à utiliser Git comme il pourrait l’être en entreprise.

Nous vous demanderons de mettre en œuvre le Github flow :

  • une nouvelle branche par fonctionnalité
  • relecture par son binôme avant la fusion
  • mise à jour des features avec la branche principale dès qu’il y a fusion.

Perte de temps en début de projet mais gain sur le long terme certain.

(Aspect non évalué mais essentiel pour votre future vie professionnelle.)

À vous de jouer

… mais pas comme ça !