- Description
- Aiguillage ferroviaire manœuvré à la main, où la voie se sépare en deux, avec sa lanterne de signalisation.
- Source
- PIVISO · page d’origine
- Licence
- CC0 Domaine public
Gestion de version et branches
Ce thème mesure la traçabilité et la fluidité du changement : peut-on retrouver qui a changé quoi, pourquoi et dans quelle version ; combien de temps vit une branche avant d'être intégrée …
En bref
Ce thème mesure la traçabilité et la fluidité du changement : peut-on retrouver qui a changé quoi, pourquoi et dans quelle version ; combien de temps vit une branche avant d'être intégrée ; combien coûte une fusion. Il vaut pour tout système de gestion de source — Git comme TFVC ; les promesses ne dépendent pas de l'outil.
Niveau : 🟢→🔴 · Code thème : GIT (matrice DL)
Pourquoi ce thème#
Le coût d'une fusion croît plus vite que linéairement avec la durée de divergence des branches : plus deux lignes de code évoluent séparément, plus les conflits sont nombreux, subtils (conflits sémantiques que l'outil ne voit pas) et risqués. Les branches longues retardent le retour d'information et regroupent les changements en gros lots, donc en gros risques. Ce thème est le pivot entre les tests et l'intégration continue.
Un point sur les kits d'installation livrés par version (cas des produits livrés « sur site ») : les branches de maintenance par version sont légitimes, mais chaque correctif doit pouvoir être reporté vers les autres versions sans copie manuelle. La stratégie de branches détaillée est dans stratégies de branches.
Ce que mesure le thème#
- Axe : de « les versions sont des copies de dossiers » à « le changement circule en petits lots vers la ligne principale, avec une traçabilité complète ».
- Indicateurs clés : âge médian d'une branche ou d'un jeu de modifications en cours (heures/jours) ; temps de fusion d'un correctif vers toutes les versions supportées ; part des changements reliés à un élément de travail.
- Unité : heures ; jours ; %.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Copies | Vous pouvez retrouver une ancienne version, au prix de recherches manuelles. | Copies de dossiers ; pas d'historique fiable |
| 2 | Historisé | Chaque changement est daté, attribué et décrit, et chaque livraison est identifiable. | Historique complet ; étiquette par version |
| 3 | Relié | Chaque changement est relié à sa demande, et un correctif est reporté sur les versions supportées en moins d'une journée. | ≥ 90 % de liens ; report ≤ 1 jour |
| 4 | Court | Les changements s'intègrent en petits lots : la divergence est mesurée en heures, pas en semaines. | Âge médian de branche < 2 jours ; conflits rares |
| 5 | Fluide | La ligne principale est toujours livrable ; les variantes de version ne coûtent presque rien à maintenir. | Intégration quotidienne ; report automatisé ; ≈ 0 conflit sémantique non détecté |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-GIT-1.1 | Le code source est sous gestion de version centralisée | Aucun fichier source « hors dépôt » |
| DL-GIT-1.2 | Les livraisons sont identifiables (étiquette, jeu de modifications, numéro) | Retrouver la source exacte d'une version livrée en < 1 h |
| DL-GIT-1.3 | Les droits d'accès aux dépôts sont nominatifs | Revue des accès |
| DL-GIT-2.1 | Chaque modification porte un message exploitable (quoi + pourquoi) | Échantillon de 30 messages relus |
| DL-GIT-2.2 | La convention de nommage des branches et des étiquettes est écrite | Document ; respect sur échantillon |
| DL-GIT-2.3 | Une sauvegarde du dépôt est testée en restauration | Restauration réussie < 12 mois |
| DL-GIT-2.4 | Les fichiers binaires volumineux sont traités à part | Règle d'exclusion/stockage dédié |
| DL-GIT-3.1 | ≥ 90 % des changements sont reliés à un élément de travail | Requête sur l'outil de suivi |
| DL-GIT-3.2 | La ligne principale est protégée : pas de poussée directe, politique de revue obligatoire | Tentative de poussée directe refusée |
| DL-GIT-3.3 | Un correctif est reporté sur chaque version supportée en ≤ 1 jour ouvré | Mesure sur les trois derniers correctifs |
| DL-GIT-3.4 | La stratégie de branches (par version, par fonctionnalité, tronc) est choisie, écrite et justifiée | Page décrivant le choix et ses limites |
| DL-GIT-3.5 | Le versionnement des livrables suit une règle (ex. sémantique) cohérente | Règle lisible ; numéros cohérents |
| DL-GIT-4.1 | L'âge médian d'une branche de fonctionnalité est < 2 jours et suivi | Rapport hebdomadaire |
| DL-GIT-4.2 | Le travail non terminé est masqué par bascule de fonctionnalité plutôt que par branche longue | Bascules recensées avec date de retrait |
| DL-GIT-4.3 | Les conflits de fusion sont rares et les fusions testées avant intégration | Taux de conflit mesuré ; CI sur la fusion |
| DL-GIT-4.4 | L'historique est exploitable (petits changements atomiques, pas de « fourre-tout ») | Taille médiane des changements < 200 lignes |
| DL-GIT-5.1 | La ligne principale est livrable à tout moment (intégration quotidienne) | Livraison d'un commit tiré au hasard réussie |
| DL-GIT-5.2 | Le report de correctifs entre versions est outillé (cherry-pick ou fusion assistée) avec contrôle de cohérence | Journal des reports automatisés |
| DL-GIT-5.3 | La traçabilité de bout en bout relie exigence → changement → test → livraison → déploiement | Parcours d'audit en < 15 min |
| DL-GIT-5.4 | La dette de branches (branches mortes, étiquettes sans usage) est purgée périodiquement | Nombre de branches inactives > 60 jours ≈ 0 |
Lecture détaillée par niveau#
🟢 Niveau 1 — Copies#
- Signes :
Projet_v3_final_OK2. On ne sait pas ce qui est en production. Un correctif se refait à la main. - Gain : aucun apprentissage nécessaire.
- Ne garantit pas : l'annulation, l'attribution, la collaboration à plusieurs.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Historisé#
- Signes : tout changement est daté et attribué ; la version livrée est retrouvable.
- Gain : retour arrière possible, audit simple.
- Ne garantit pas : le lien avec le « pourquoi », la rapidité d'intégration.
- Difficulté : 1/5 · Effort : 2/5.
🟡 Niveau 3 — Relié#
- Signes : le lien changement ↔ demande est la norme ; la ligne principale est protégée ; les correctifs voyagent entre versions sans retranscription.
- Gain : audit, notes de version et analyses d'impact deviennent des requêtes, pas des enquêtes.
- Ne garantit pas : que les lots soient petits — on peut tracer parfaitement de très gros changements.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Court#
- Signes : les changements s'intègrent en moins de deux jours ; le travail inachevé reste invisible grâce aux bascules de fonctionnalité plutôt qu'à des branches. Cette pratique est celle du développement sur tronc (trunk-based development), qui exige des tests rapides et fiables.
- Gain : la fusion cesse d'être un événement ; les lots sont petits donc peu risqués.
- Ne garantit pas : l'absence de dette de bascules (une bascule oubliée est un chemin de code mort).
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Fluide#
- Signes : la ligne principale est livrable en permanence ; un correctif atteint toutes les versions supportées via un processus outillé ; la traçabilité complète permet un audit en quelques minutes.
- Gain : maintenance multi-versions à coût quasi constant.
- Ne garantit pas : que le nombre de versions supportées soit soutenable — c'est une décision de gestion du cycle de vie du produit.
- Difficulté : 5/5 · Effort : 4/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-GIT-3.1 : 60 à 89 % de changements reliés.
- 0,5 sur DL-GIT-3.3 : le report sur versions supportées se fait en 2 à 3 jours.
- Un 5 partiel : la ligne principale est livrable la plupart du temps, mais un seul des deux flux de correctifs est outillé.
Branche « temporaire » éternelle. Symptôme : une branche de fonctionnalité de 6 semaines. Cause : le périmètre est trop gros pour être livré en une fois. Remède : découper en incréments livrables derrière une bascule.
Historique illisible. Symptôme : messages « fix », « modif ». Cause : aucun contrôle. Remède : modèle de message imposé par la revue (quoi, pourquoi, lien).
Mesurez l'âge du plus vieux changement non intégré. Un seul changement de 30 jours illustre souvent mieux le problème que la médiane.
Imposer « une branche = un jour max » encourage à fusionner du code inachevé sans bascule. Gardez l'objectif sur le risque de divergence, pas sur la durée seule.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : adopter un outil de gestion de source, interdire les copies de dossiers comme méthode de versionnement.
- 2 → 3 : lier chaque changement à une demande (règle de politique de dépôt), protéger la ligne principale, écrire la stratégie de branches.
- 3 → 4 : bascules de fonctionnalité, fusion testée en CI avant intégration, revues courtes.
- 4 → 5 : outillage de report entre versions, nettoyage périodique, audit de traçabilité de bout en bout.
Un correctif touchant une procédure du datamart doit atteindre trois versions supportées. En niveau 2, quatre heures de copies manuelles et un oubli à la version la plus ancienne. En niveau 3-4, un report assisté depuis la ligne principale vers les trois branches de version, chacune testée par sa CI, en 40 minutes.
Voir aussi#
- Voisins : 03 Tests · 05 CI · 06 Déploiement · 12 Expérience développeur.
- Autres matrices : Projet — livraison et mise en production · BI — versionnement et industrialisation des rapports.
- Pratique : Git en profondeur · TFVC en profondeur · Git contre TFVC · stratégies de branches · CI/CD.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
