GitFlow: Een Branching Strategie voor Agile Software Development Teams

GitFlow is een populaire branching strategie die development teams helpt hun codebase op een georganiseerde en efficiënte manier te beheren. Het is vooral nuttig voor Agile softwareontwikkeling, omdat teams gelijktijdig aan meerdere functies en bugfixes moeten kunnen werken, én ook een stabiele productieomgeving behouden. In deze blog zullen we dieper ingaan op GitFlow en hoe het kan worden geïmplementeerd in een CI/CD-pipeline, met behulp van een voorbeeldpipeline als referentie.

Wat is GitFlow
GitFlow is een branchemodel dat in 2010 werd ontwikkeld door Vincent Driessen. Het is gebaseerd op het idee om 2 main branches te hanteren: de main branch, die de stabiele, productierijpe code bevat. En de development branch, die de laatste veranderingen bevat die worden ontwikkeld voor de volgende release. Naast deze main branches introduceert GitFlow ook verschillende ondersteunende branches, waaronder:

• Feature branches: deze worden gebruikt om nieuwe features of functionaliteiten te ontwikkelen, die vervolgens worden samengevoegd in de feature branches wanneer ze klaar zijn.
  
• Release branches: deze worden gebruikt om een nieuwe release voor te bereiden door de code te stabiliseren en eventuele last-minute bugs op te lossen. Zodra de release klaar is, worden de wijzigingen samengevoegd in zowel de master als de ontwikkeltak.
  
• Hotfix branches: deze worden gebruikt om snel kritieke bugs in de productieomgeving op te lossen. De wijzigingen worden gemaakt op een aparte branch die op de main branch is gebaseerd. Dit wordt vervolgens samengevoegd in zowel de main als de development branch.
  
  

GitFlow biedt een duidelijke structuur voor hoe wijzigingen worden aangebracht in de codebase. Ook helpt het conflicten en andere problemen te voorkomen die kunnen ontstaan wanneer meerdere ontwikkelaars gelijktijdig aan dezelfde codebase werken.

GitFlow in een CI/CD-pipeline

Een CI/CD-pipeline is een geautomatiseerd proces dat ontwikkelingsteams helpt hun code wijzigingen snel en betrouwbaar te bouwen, testen en implementeren. Bij het implementeren van GitFlow in een CI/CD-pipeline, moet de pipeline de branching strategie weerspiegelen door fases te hebben voor het bouwen, testen en implementeren van wijzigingen naar verschillende omgevingen.

Laten we eens kijken naar een voorbeeldpipeline die GitFlow gebruikt:

stages:
  - build
  - test
  - deploy_dev
  - deploy_test
  - deploy_acc
  - deploy_prod
  - merge_main_to_develop

build:
  stage: build
  script:
    - echo "Building app"

test:
  stage: test
  script:
    - echo "Running tests"

deploy_dev:
  stage: deploy_dev
  script:
    - echo "Deploying to dev environment"
  rules:
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "develop"'
      when: manual

deploy_test:
  stage: deploy_test
  script:
    - echo "Deploying to test environment"
  rules:
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "release/*"'
      when: manual

deploy_acc:
  stage: deploy_acc
  script:
    - echo "Deploying to acc environment"
  rules:
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "release/*"'
      when: manual

deploy_prod:
  stage: deploy_prod
  script:
    - echo "Deploying to prod environment"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual

merge_main_to_develop:
  stage: deploy_prod
  script:
    - git checkout develop
    - git merge --no-ff --no-edit main \
      || {
      echo "Merge conflicts occurred"
      git merge --abort
      git push
      exit 1
      }
    - git push
    - |
      if git diff main

Dit is een voorbeeld van een CI/CD pipeline die gebruikmaakt van GitFlow als branching strategie. Het heeft meerdere stadia: build, test, en verschillende deployment stadia voor de ontwikkel-, test-, acceptatie-, en productie-omgevingen.

Het eerste stadium (build) bouwt de applicatie en het tweede stadium (test) voert tests uit. De volgende vier deployment stadia (deploy_dev, deploy_test, deploy_acc, en deploy_prod) implementeren de code op de respectievelijke omgevingen. Er zijn regels ingesteld om ervoor te zorgen dat elke stap enkel handmatig wordt uitgevoerd wanneer aan bepaalde voorwaarden wordt voldaan.

Tot slot is er een stadium dat ervoor zorgt dat wijzigingen die in de main branch zijn gemaakt ook worden gemerged in de develop branch. Dit zorgt ervoor dat de develop branch altijd up-to-date is met de laatste wijzigingen.

Nu we weten hoe een GitFlow pipeline eruitzien, laten we ook kijken naar de voor- en nadelen van GitFlow.

Voordelen van GitFlow

1. Eenvoudige samenwerking:
   Hoewel deze pipeline zeer effectief kan zijn, kan het ook voor extra overhead zorgen. Ontwikkelaars moeten wellicht extra tijd besteden aan het testen van hun code-wijzigingen in verschillende omgevingen. Dit kan voor vertraging zorgen. Ook kan het beheren van meerdere branches complex en tijdrovend worden.
   
   
2. Complexiteit:
   Deze pipeline kan behoorlijk complex zijn, vooral voor ontwikkelaars die nieuw zijn in GitFlow. Dit kan leiden tot errors en problemen op de lange termijn. De pipeline is afhankelijk van verschillende tools en processen, die moeilijk te leren en te beheren kunnen zijn.
   
   

Wat wij denken?
Over het algemeen kan deze pipeline een effectieve manier zijn om de ontwikkeling en release van complexe toepassingen te beheren. Door gebruik te maken van GitFlow kunnen ontwikkelaars effectiever samenwerken en de risico's verminderen die gepaard gaan met het implementeren van code-wijzigingen in productie. Het is ook goed om rekening te houden met eventuele nadelen, inclusief de extra overhead en complexiteit. Ontwikkelaars moeten hun behoeften en vereisten zorgvuldig overwegen voordat ze deze pipeline implementeren in hun eigen development workflows.