Project Workflow Guide

Dit document beschrijft de GitLab workflow en het Scrum proces voor de ontwikkeling van dit project.

---

1. Iteraties & Sprints

• Sprintduur: Variabel (minimum 2 weken), langer bij vakanties.
• Taaktracking: GitLab Iteraties, Issue Boards, en Labels.
• Epics & Issues: Optionele Epics voor grotere features; issues representeren user stories of taken.
• Dagelijks werk: Verplaats issues door de boardkolommen: Backlog → To Do → In Progress → Testing → Review → Done.

---

2. Issues

• Labels:
  • Type: type::feature, type::bug, type::task
  • Prioriteit: priority::critical, priority::high, priority::medium, priority::low
  • Project: project::frontend, project::backend, project::infra, project::documentation
• Titels: Gebruik korte duidelijke zinnen ("Toevoegen van authenticatie met Keycloak”).
• Story points: Gebruik de Fibonacci-reeks voor inschattingen (1 (<2u), 2 (halve dag), 3 (hele dag), 5 (halve werkweek), 8 (werkweek (5d)), 13 (2 werkweken SPLITS OP)).
• Status:
  • Backlog: Alle open issues.
  • To Do: Issues voor de huidige sprint.
  • Blocked: Issues waar momenteel niet verder kan aan gewerkt worden.
  • In Progress: Issues waar momenteel aan gewerkt wordt.
  • Testing: Issues klaar voor merge request
  • Done: Issues die gemerged zijn.
  • Won't do: Issues die niet kunnen gemerged worden.

---

3. Definition Of Done

Infra

• Geen hardcoded secrets of gevoelige data
• Consistente bestandsstructuur
• Correct gebruik van YAML/TOML/JSON-formattering
• Pipelines (CI/CD) lopen succesvol door
• Config gereviewed
• Config gemerged naar main/stable branch
• Uitleg in README over hoe te deployen of op te zetten
• Validatie van configuratie (server, database, etc)

Frontend & Backend

• Code Buildt Succesvol
• Code Volgt Stijlstandaarden van de taal/het project
• Code is gedocumenteert: commentaar, hoe gebruiken in readme (wanneer van toepassing)
• Code heeft testen (wanneer van toepassing)
• Code is gereviewed
• Code is gemerged

---

4. Branch Strategie

• Branch hiërarchie:

production (live)
└── staging (demo)
    └── development
        ├── feature/*
        └── bugfix/*

Branch / Pattern	Purpose / Description
production	Live production branch. Only fully tested code is merged here.
staging	Pre-production testing environment. QA verifies features/bugfixes here.
development	Integrates multiple feature and bugfix branches. Main development branch.
feature/*	Short-lived branches for new features. Merges into development.
bugfix/*	Short-lived branches for bug fixes. Merges into development (or staging for hotfixes).

• Branch rules:

  • production, staging en development zijn protected.
  • Feature-, bugfix- en task-branches worden vanaf development aangemaakt.
  • Hotfixes lopen liefst via een aparte branch.

• Naamgeving: <type>/<issue-nummer>-<korte-omschrijving> (bijv. feature/123-user-login).

5. Commit Message rules

• Gebruik Engels en de imperatief: “Add login form” ipv. “Added login form”.
• Houdt de eerste regel Kort (≤50 karakters) en vat de aanpassing samen.
• Voeg een meer gedetailleerde beschrijving toe in de body indien nodig (wrap op 72 karakters).
• Gebruik deze prefixes voor je commits
  • feat: — new feature
  • fix: — bug fix
  • chore: — maintenance tasks (dependencies, CI, configs)
  • docs: — documentation changes
  • refactor: — code restructuring without changing functionality
  • test: — toevoegen of updaten van tests

6. Merge Requests (MRs)

• Reviews: Vereist 2 goedkeuringen op production en staging voor merge en 1 goedkeuring op development.
• Merge strategie: Fast-forward (squash alleen op development branch).
• Vereisten:
  • Gelinkt aan een issue (Closes #123)
  • CI/CD slaagt: tests, build, linting, security scans
  • Geen merge conflicten
• Commit berichten: Gebruik prefixes (feat:, fix:, refactor:) voor duidelijkheid.

Branch	Squash	Approvals	Security Approvals
production	❌ Disabled	2 (Maintainer)	No
staging	❌ Disabled	2 (Maintainer)	No
development	✅ Required	1 (Developer / Maintainer)	No

7. CI/CD & Deployments

• Automatische deployments:
  • staging → demo omgeving
  • production → live omgeving
  • development → optioneel/dev server in de toekomst
• Pipelines: Build, tests, linting en security scans moeten slagen voor alle merges.

8. Workflow Samenvatting

1. Kies een issue uit To Do.
2. Maak branch aan vanaf development: git checkout -b feature/123-issue-naam.
3. Ontwikkel en commit (met juiste prefix).
4. Push de branch en maak een MR naar development.
5. MR ondergaat 2 goedkeuringen + CI/CD checks.
6. Merge naar development → uiteindelijk staging → production.
7. Verplaats het issue naar Done zodra het gemerged en gedeployed is.

9. Best Practices

• Houd branches klein en gefocust.
• Schrijf duidelijke, geprefixeerde commit-berichten.
• Link commits en merges aan issues.
• Houd MRs reviewbaar (<400 regels).
• Update issues en boards regelmatig.