Release Branch in Git — wat het is, doel en werkproces

Wat is Release Branch in Git

Release Branch (release-tak) — is een tijdelijke tak in Git Flow, aangemaakt vanuit develop wanneer het team besluit dat de huidige set functies klaar is voor release. Het bestaat precies zolang als de uiteindelijke release-voorbereiding duurt — van een paar uur tot een paar dagen.

Het belangrijkste doel van de release-tak is om een specifieke set functies voor de release te bevriezen, zonder de ontwikkeling van volgende versies te stoppen. Terwijl de release-tak wordt voorbereid, kunnen andere ontwikkelaars doorgaan met het mergen van feature-takken in develop voor de volgende release.

In de release-tak worden geen nieuwe functies gemaakt — alleen bugfixes, update van de applicatieversie, lokalisatie en documentatie. Na voltooiing van alle werkzaamheden wordt de release-tak samengevoegd in main (gemarkeerd als release) en terug in develop (zodat bugfixes in toekomstige versies terechtkomen).

Volgens Atlassian, 2024, zijn release-takken van cruciaal belang voor projecten met regelmatige releasecycli — ze zorgen voor voorspelbaarheid en stabiliteit van het releaseproces.

Levenscyclus van een release-tak

Levenscyclus van de release-tak, van aanmaak tot verwijdering, omvat verschillende fasen. Inzicht in elke fase helpt het team om acties te synchroniseren en fouten te voorkomen.

1. Aanmaak — vanaf de laatste commit van develop wordt een tak aangemaakt met de naam release/2.5.0. develop blijft feature-takken accepteren voor de volgende versie.
2. Voorbereiding — in de release-tak wordt de applicatieversie bijgewerkt in build.gradle, Info.plist en andere configuratiebestanden.
3. Bugfixing — kritieke bugs gevonden tijdens het eindtesten worden opgelost. Alleen bugs — geen nieuwe functies.
4. Eindtesten — het QA-team voert regressietesten uit op de release-tak. Nieuwe bugs worden ter correctie naar dezelfde tak gestuurd.
5. Merge in main — de release-tak wordt samengevoegd in main met de --no-ff vlag. Er wordt een release-tag aangemaakt: v2.5.0.
6. Merge in develop — de release-tak wordt terug samengevoegd in develop, zodat bugfixes uit de release in de huidige ontwikkeling terechtkomen.
7. Verwijdering — de release-tak wordt lokaal en op afstand verwijderd, omdat de taak is voltooid.

Punt 6 — terugmerge in develop — wordt vaak vergeten, maar is van cruciaal belang. Zonder dit komen bugfixes die in de release zijn gemaakt niet in develop terecht, en in de volgende release kunnen dezelfde fouten opnieuw optreden.

Typische duur van de fasen van een release-tak

De levensduur van een release-tak hangt af van de complexiteit van de release en de kwaliteit van de code in develop. Gemiddeld duurt de voorbereiding 2 tot 5 werkdagen voor een middelgrote mobiele applicatie.

Wat gebeurt er in de release-tak

In de release-tak wordt een strikt beperkte set taken uitgevoerd. Elke afwijking van deze lijst schendt het Git Flow-model en creëert risico's voor de stabiliteit van de release.

De regel van verbod op nieuwe functies — de belangrijkste in de release-tak. Als een functie de release niet heeft gehaald, wacht ze op de volgende cyclus. Poging om een onvoltooide functie in de release-tak te krijgen — de belangrijkste oorzaak van deadline-overschrijdingen en bugs in productie.

Versie-update in een mobiel project

In de release-tak wordt verplicht het versienummer van de applicatie bijgewerkt. Voor Android zijn dit de velden versionCode en versionName in build.gradle, voor iOS — CFBundleShortVersionString in Info.plist.

// build.gradle (app-level) — versie-update in de release-tak
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Voor iOS — Info.plist bijwerken
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Verschillen tussen release en hotfix

Beginnende ontwikkelaars verwarren vaak release en hotfix-takken, hoewel hun doel fundamenteel verschillend is. Een fout bij het kiezen van het taktype kan leiden tot vertraging van een kritieke correctie of verstoring van het releaseproces.

• Bron — release wordt aangemaakt vanuit develop, hotfix — vanuit main. Dit is het belangrijkste verschil dat al het andere bepaalt.
• Spoed — release is gepland: het team beslist zelf wanneer het met de voorbereiding begint. Hotfix is urgent: een probleem in productie vereist onmiddellijke correctie.
• Inhoud — release kan meerdere correcties en een versie-update bevatten. Hotfix bevat slechts één kritieke correctie.
• Merge — release wordt samengevoegd in main en develop. Hotfix wordt ook samengevoegd in main en develop, maar met prioriteit.
• Levensduur — release leeft 1 tot 7 dagen. Hotfix leeft 30 minuten tot 1 dag.

Als een bug wordt ontdekt tijdens de release-voorbereiding (in de release-tak) — is dit een gewone bugfix. Als een bug wordt ontdekt in productie (op main) — is dit een hotfix en wordt deze gemaakt vanuit main, zelfs als de release-tak al bestaat.

Naamgevingsregels voor release-takken

Een uniforme standaard voor naamgeving van release-takken vereenvoudigt de navigatie door de repository en stelt CI/CD-systemen in staat automatisch te bepalen dat de tak bij het releaseproces hoort.

• release/X.Y.Z — standaard Git Flow-formaat, waarbij X.Y.Z de releaseversie is. Voorbeeld: release/2.5.0.
• release/naam — alternatief formaat met codenaam van de release. Voorbeeld: release/merlin.
• release/datum — formaat met releasedatum. Zelden gebruikt omdat versie belangrijker is dan datum. Voorbeeld: release/2024-12-01.

Het formaat release/X.Y.Z — heeft de voorkeur omdat het de tak expliciet koppelt aan het versienummer dat aan de release wordt toegekend. Dit vereenvoudigt het zoeken en de automatische verwerking door CI/CD-scripts.

Strategie voor terugkoppeling naar develop

Terugkoppeling (merge back) van de release-tak in develop — een van de belangrijkste en tegelijkertijd vaak overgeslagen operaties. Zonder dit blijven alle bugfixes die in de release zijn gemaakt alleen in de releaseversie en komen ze niet in de volgende releasecyclus.

Het terugkoppelingsproces wordt uitgevoerd nadat de release-tak al in main is gemerged. Eerst wordt release samengevoegd in develop, daarna — verwijderd. Dit garandeert dat develop alle correcties bevat die tijdens de release-voorbereiding zijn gemaakt.

Na terugkoppeling kunnen conflicten ontstaan — vooral als er in develop al nieuwe feature-takken zijn verschenen die dezelfde bestanden hebben gewijzigd. De ontwikkelaar verantwoordelijk voor de release lost deze conflicten op en pusht develop naar de server.

Sommige teams gebruiken rebase in plaats van merge voor terugkoppeling, zodat de geschiedenis lineair blijft. Merge is echter veiliger voor develop omdat het de commit-geschiedenis niet herschrijft die mogelijk al door andere ontwikkelaars is gebruikt.

Voorbeeldcommando's voor werken met release

Laten we de volledige werkcyclus met de release-tak bekijken: van aanmaak tot verwijdering na een succesvolle release van de mobiele applicatie versie 2.5.0.

# 1. Release-tak aanmaken vanuit develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Versie-update en bugfixes
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Bugs oplossen (alleen bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Release-tak naar server pushen
git push origin release/2.5.0

# 5. Release mergen in 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. Terugkoppeling naar develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Release-tak verwijderen
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Commando's 5 en 6 — dubbele merge — zijn van cruciaal belang. Eerst krijgt main de releasecode en tag, daarna synchroniseert develop met de bugfixes uit de release. Als stap 6 wordt overgeslagen, komen de correcties uit de release niet in de volgende ontwikkelcyclus.

Automatisering van het releaseproces

Voor mobiele projecten met regelmatige releases kan het proces van het aanmaken van de release-tak en het bijwerken van de versie worden geautomatiseerd via CI/CD-scripts. GitHub Actions maakt het mogelijk een workflow te creëren die bij een druk op de knop een release-tak aanmaakt met automatische versie-update.

Voor mobiele projecten met regelmatige releases kan het proces van het aanmaken van de release-tak en het bijwerken van de versie worden geautomatiseerd via CI/CD-scripts. GitHub Actions maakt het mogelijk een workflow te creëren die bij een druk op de knop een release-tak aanmaakt met automatische versie-update.

# GitHub Actions — automatisering van het aanmaken van release-takken
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 }}