Release Branch dans Git — définition, objectif et flux de travail

Qu'est-ce qu'une Release Branch dans Git

Release Branch (branche de release) est une branche temporaire dans Git Flow, créée à partir de develop lorsque l'équipe décide que l'ensemble actuel de fonctionnalités est prêt pour la publication. Elle existe exactement le temps que dure la préparation finale de la release, de quelques heures à quelques jours.

L'objectif principal d'une branche release est de figer un ensemble spécifique de fonctionnalités pour la release sans arrêter le développement des versions suivantes. Pendant que la branche release est préparée pour le déploiement, d'autres développeurs peuvent continuer à fusionner des branches feature dans develop pour la prochaine release.

Aucune nouvelle fonctionnalité n'est créée dans la branche release, seulement des corrections de bogues, une mise à jour de la version de l'application, la localisation et la documentation. Une fois tout le travail terminé, la branche release est fusionnée dans main (marquée comme release) et de nouveau dans develop (pour que les corrections parviennent aux versions futures).

Selon Atlassian, 2024, les branches release sont d'une importance cruciale pour les projets avec des cycles de release réguliers, car elles garantissent la prévisibilité et la stabilité du processus de publication.

Cycle de vie d'une branche release

Le cycle de vie de la branche release, de sa création à sa suppression, comprend plusieurs étapes. Comprendre chaque étape aide l'équipe à synchroniser ses actions et à éviter les erreurs.

1. Création — à partir du dernier commit de develop, une branche nommée release/2.5.0 est créée. develop continue d'accepter les branches feature pour la version suivante.
2. Préparation — dans la branche release, la version de l'application est mise à jour dans build.gradle, Info.plist et d'autres fichiers de configuration.
3. Correction de bogues — les erreurs critiques trouvées lors des tests finaux sont corrigées. Uniquement des bogues, pas de nouvelles fonctionnalités.
4. Tests finaux — l'équipe QA effectue des tests de régression sur la branche release. Les nouveaux bogues sont envoyés pour correction dans la même branche.
5. Fusion dans main — la branche release est fusionnée dans main avec le flag --no-ff. Le tag de release est créé : v2.5.0.
6. Fusion dans develop — la branche release est fusionnée de nouveau dans develop pour que les corrections de la release parviennent au développement en cours.
7. Suppression — la branche release est supprimée localement et à distance, sa tâche étant accomplie.

L'étape 6 (la fusion inverse dans develop) est souvent oubliée, mais elle est d'une importance cruciale. Sans elle, les corrections effectuées dans la branche release ne parviendront pas à develop, et les mêmes erreurs pourraient réapparaître dans la prochaine release.

Durées typiques des étapes d'une branche release

La durée de vie d'une branche release dépend de la complexité de la release et de la qualité du code dans develop. En moyenne, la préparation prend de 2 à 5 jours ouvrés pour une application mobile de taille moyenne.

Ce qui se fait dans une branche release

Dans la branche release, un ensemble strictement limité de tâches est exécuté. Tout écart par rapport à cette liste viole le modèle Git Flow et crée des risques pour la stabilité de la release.

La règle de l'interdiction des nouvelles fonctionnalités est la plus importante dans une branche release. Si une fonctionnalité n'est pas prête pour la release, elle attend le cycle suivant. Tenter d'introduire une fonctionnalité incomplète dans la branche release est la principale cause de dépassement des délais et de bogues en production.

Mise à jour de version dans un projet mobile

Dans la branche release, le numéro de version de l'application est obligatoirement mis à jour. Pour Android, ce sont les champs versionCode et versionName dans build.gradle ; pour iOS — CFBundleShortVersionString dans Info.plist.

// build.gradle (niveau application) — mise à jour de version dans la branche release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Pour iOS — mise à jour d'Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Différences entre release et hotfix

Les développeurs débutants confondent souvent les branches release et hotfix, bien que leurs objectifs soient fondamentalement différents. Choisir le mauvais type de branche peut retarder une correction critique ou perturber le processus de release.

• Source — release est créée à partir de develop, hotfix à partir de main. C'est la principale différence qui détermine tout le reste.
• Urgence — release est planifiée : l'équipe décide quand commencer la préparation. Hotfix est urgent : un problème en production nécessite une correction immédiate.
• Contenu — release peut inclure plusieurs corrections et une mise à jour de version. Hotfix contient une seule correction critique.
• Fusion — release est fusionnée dans main et develop. Hotfix est également fusionnée dans main et develop, mais en priorité.
• Durée de vie — release vit de 1 à 7 jours. Hotfix vit de 30 minutes à 1 jour.

Si un bogue est trouvé pendant la préparation de la release (dans la branche release), c'est une correction normale. Si un bogue est trouvé en production (sur main), c'est un hotfix, et il est créé à partir de main, même si la branche release existe déjà.

Règles de nommage des branches release

Une norme unifiée de nommage des branches release simplifie la navigation dans le référentiel et permet aux systèmes CI/CD de détecter automatiquement qu'une branche appartient au processus de release.

• release/X.Y.Z — format standard Git Flow, où X.Y.Z est la version de la release. Exemple : release/2.5.0.
• release/nom — format alternatif avec un nom de code de release. Exemple : release/merlin.
• release/date — format avec la date de release. Rarement utilisé car la version est plus importante que la date. Exemple : release/2024-12-01.

Le format release/X.Y.Z est préféré car il lie explicitement la branche au numéro de version qui sera attribué à la release. Cela simplifie la recherche et le traitement automatique par les scripts CI/CD.

Stratégie de fusion inverse dans develop

La fusion inverse (merge back) de la branche release dans develop est l'une des opérations les plus importantes et en même temps l'une des plus souvent négligées. Sans elle, toutes les corrections effectuées dans la branche release restent uniquement dans la version de release et ne parviennent pas au prochain cycle de release.

Le processus de fusion inverse est effectué après que la branche release a déjà été fusionnée dans main. D'abord, release est fusionnée dans develop, puis supprimée. Cela garantit que develop contient toutes les corrections effectuées pendant la préparation de la release.

Après la fusion inverse, des conflits peuvent survenir, surtout si de nouvelles branches feature qui modifiaient les mêmes fichiers sont déjà apparues dans develop. Le développeur responsable de la release résout ces conflits et pousse develop sur le serveur.

Certaines équipes utilisent rebase au lieu de merge pour la fusion inverse afin de garder un historique linéaire. Cependant, merge est plus sûr pour develop car il ne réécrit pas l'historique des commits qui pourrait déjà être utilisé par d'autres développeurs.

Exemples de commandes pour travailler avec release

Examinons le cycle complet de travail avec une branche release : de la création à la suppression après une release réussie d'une application mobile version 2.5.0.

# 1. Créer la branche release depuis develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Mettre à jour la version et les corrections
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Corriger les bogues (uniquement les bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Envoyer la branche release sur le serveur
git push origin release/2.5.0

# 5. Fusionner release dans main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Fusion inverse dans develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Supprimer la branche release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Les commandes 5 et 6 (la double fusion) sont d'une importance cruciale. D'abord, main reçoit le code de release et le tag, puis develop se synchronise avec les corrections de release. Si l'étape 6 est ignorée, les corrections de la release ne parviendront pas au prochain cycle de développement.

Automatisation du processus de release

Pour les projets mobiles avec des releases régulières, le processus de création d'une branche release et de mise à jour de la version peut être automatisé via des scripts CI/CD. GitHub Actions permet de créer un workflow qui, en cliquant sur un bouton, crée une branche release avec une mise à jour automatique de la version.

Pour les projets mobiles avec des releases régulières, le processus de création d'une branche release et de mise à jour de la version peut être automatisé via des scripts CI/CD. GitHub Actions permet de créer un workflow qui, en cliquant sur un bouton, crée une branche release avec une mise à jour automatique de la version.

# GitHub Actions — automatisation de la création de branche release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}