Skip to main content

Theorie

Het topic git in deze cursus wordt aangeboden via een algemene workshop die publiekelijk beschikbaar is. De meeste studenten volgden in de eerste fase collectief deze workshop. Voor de theoretische achtergrond verwijzen we naar het inleidende slide-deck.

In deze cursus Infrastructure as Code verwachten we een doorgedreven en professioneel gebruik van git. Op deze pagina vind je de aanvullende theorie die je nodig hebt om de juiste workflows en processen toe te passen.

Branching strategie: GitLab Flow​

Een branching strategie legt vast hoe een team samenwerkt in één gedeelde repository. In deze cursus gebruiken we de GitLab Flow, een pragmatische aanpak die goed aansluit bij continue integratie en deployment.

De drie lagen​

BranchOmgevingDoel
mainproductieAltijd stabiel. Enkel via merge request vanuit develop.
developstagingWerkende integratie van alle features. Vertrekpunt voor nieuwe branches.
feature branches / forkslokaalGeïsoleerd werken aan één feature of artikel.
gitGraph commit id:"initiële setup" commit id:"project structuur" branch develop checkout develop commit id:"basis configuratie" branch FEAT-feature1 checkout FEAT-feature1 commit id:"nieuwe code (dev1)" commit id:"code afgewerkt (dev1)" checkout develop branch FEAT-feature2 checkout FEAT-feature2 commit id:"nieuwe code (dev2)" commit id:"code afgewerkt (dev2)" checkout develop merge FEAT-feature1 id:"MR#1 gemerged" merge FEAT-feature2 id:"MR#2 gemerged" branch upgrade-component checkout upgrade-component commit id:"security fix" commit id:"component upgrade" checkout develop merge upgrade-component id:"security update" checkout main merge develop id:"sprint release" tag:"v1.0"

Regels​

  • Nooit rechtstreeks committen op main of develop. Alle wijzigingen verlopen via een merge request.
  • develop is de staging-omgeving. Na elke merge moet de branch in een werkende staat zijn.
  • main is productie. Bezoekers zien deze branch. Fouten hier zijn onmiddellijk zichtbaar.
  • Feature branches zijn kort en gefocust: één feature, één work item.

Merge Requests​

Een merge request (MR) is het mechanisme om wijzigingen voor te stellen aan een beschermde branch. Het combineert drie zaken:

  1. Codereview — teamleden beoordelen de wijzigingen vóór ze gemerged worden.
  2. Discussie — feedback wordt gegeven op specifieke regels code of het geheel.
  3. Automatische validatie — de CI/CD-pipeline voert tests uit op de branch van de MR.

Levenscyclus van een MR​

Work item aanmaken → branch → commits in branch → MR indienen → review → feedback verwerken → mergen
  • Een MR wordt pas gemerged als de pipeline slaagt én de reviewer akkoord gaat.
  • Conflicten worden opgelost vóór het mergen, typisch door de reviewer.
  • Na het mergen wordt de feature branch verwijderd.

Protected Branches​

GitLab laat toe om branches te beveiligen (protected branches). Dit voorkomt dat iemand rechtstreeks pusht naar main of develop.

Wat stel je in op een protected branch:

InstellingWaarde
Allowed to pushNo one (iedereen gebruikt MRs)
Allowed to mergeMaintainers / specifieke rollen
Require merge request approvalsJa — minstens 1 goedkeuring, voor main minstens 2

De projectleiders beheren deze instellingen en stellen ook de goedkeurders in voor de volgende sprint.

CI/CD-pipeline en git flow​

De CI/CD-pipeline is niet losgekoppeld van de branching strategie — ze versterken elkaar. Elke push naar een branch triggert automatisch de pipeline, maar wat de pipeline doet verschilt per branch.

Pipeline als kwaliteitspoort​

Een MR mag pas gemerged worden als de pipeline groen is. Dit dwingt een minimale kwaliteitscontrole af zonder dat dit van de reviewer afhankelijk is. Typische checks:

  • Linting (vb. pylint, markdownlint)
  • Unit tests (vb. pytest)
  • Build-validatie

Variabelen en credentials​

Gevoelige informatie (wachtwoorden, tokens, SSH-sleutels) wordt nooit opgeslagen in de repository. GitLab biedt hiervoor CI/CD-variabelen aan (Settings → CI/CD → Variables). Deze zijn:

  • versleuteld opgeslagen
  • optioneel beperkt tot protected branches
  • maskeerbaar in de pipeline-logs

work items en projectbeheer​

Een professionele git-workflow gaat verder dan alleen branches en commits. GitLab biedt tools om het werk te plannen en op te volgen.

Work item-driven development​

De vuistregel: maak eerst een work item aan, dan een branch. Zo is altijd duidelijk:

  • wie aan wat werkt
  • wat de status is van elke taak
  • welk werk nog in de backlog staat

Branches worden idealiter gekoppeld aan een work item (GitLab doet dit automatisch als je de branch vanuit het work item aanmaakt).

Issue board​

Het issue board is een Kanban-bord dat de status van alle work items toont. Definieer kolommen die overeenkomen met je workflow, bijvoorbeeld:

Backlog → In Progress → In Review → Done

Developers en project managers verplaatsen work items mee doorheen het bord terwijl ze merge requests verwerken.

Labels en milestones​

  • Labels categoriseren work items (vb. auteur, redacteur, bug, feature).
  • Milestones groeperen work items per sprint of release en tonen de voortgang.

Samenvatting: de workflow in één oogopslag​

1. Maak een work item aan voor elk stukje werk.
2. Maak een feature branch vanuit develop, gekoppeld aan het work item.
3. Werk lokaal, commit regelmatig met duidelijke boodschappen.
4. Dien een merge request in naar develop vóór de deadline.
5. De pipeline valideert automatisch de MR.
6. Een reviewer beoordeelt de MR, geeft feedback en merget naar develop.
7. De projectleiders mergen develop naar main na goedkeuring (≥ 2 approvals).
8. De pipeline deployt automatisch naar productie.