-
Notifications
You must be signed in to change notification settings - Fork 0
Versiebeheer regels
Bij elke merge naar master wordt er via Github een nieuwe tag & versie gemaakt om zo een versiegeschiedenis bij te houden. Zo kunnen we altijd de oude code van een vorige versie terughalen bij noodgevallen of om terug te draaien bij een grote bug. We gebruiken hiervoor semantic versioning. Informatie over semantic versioning
Wij werken met drie verschillende soorten branches. De feature, fix en hotfix branch. Elke branch heeft zijn eigen regels wanneer je deze moet gebruiken.
- Een feature branch is bedoeld voor nieuwe features zoals een nieuw scherm en/of een front-end update.
- Als je een branch aanmaakt begin deze dan met:
feature/[tekst]dus bijvoorbeeld:feature/generate-reports
- Een fix branch is bedoeld voor kleine bugfixes of kleine veranderingen
- Als je een branch aanmaakt begin deze dan met:
fix/[tekst]dus bijvoorbeeld:fix/formatting-text
- Een hotfix branch is bedoeld voor fixes die alleen worden gebruikt als iets op de master direct gefixed moet worden. Dit gebeurd bijna nooit en is alleen bedoeld voor de master branch
- Als je een branch aanmaakt begin deze dan met:
hot-fix/[tekst]dus bijvoorbeeld:hot-fix/compiler-error
- Ga terug naar de
developmentbranch d.m.v het command:git checkout developement - Kies het type branch dat je wilt aanmaken, feature, fix of hotfix en run de command:
git checkout -b [naam branch]
Er zijn een aantal regels voordat je een pull request mag aanmaken en voor degene die een pull request reviewen.
Check voordat je een pull request het volgende:
- Check alle Unit Tests
- Heb je bestaande tests bijgewerkt waar nodig en deze gerunt
- Heb je nieuwe tests toegevoegd waar nodig met behulp van het Testplan
- Voldoet mijn code aan de code standaarden beschreven in de Coding Guidelines?
- Build mijn code zonder errors?
- Heb je je database model aangepast? Zo ja, laat weten wat er precies aangepast is en voeg zo nodig een bestand bij.
Reviewen van pull requests doe je als de code die bewerkt is door jou is aangemaakt of als je door de GIT Manager (Martijn Melchers) aangewezen wordt voor review. Als je code reviewed moet je het volgende checken:
- Voldoet de code aan de code standaarden in de Coding Guidelines?
- Zijn alle taken beschreven in de pull request correct geïmplementeerd?
- Controleer dit door lokaal te testen en de gekoppelde project kaart langs te lopen
We maken gebruik van CD & CI om het handmatige werk voor ons te verminderen. Als er een Pull Request aangemaakt wordt zullen er automatisch tests en controles worden uitgevoerd. Deze checken onder anderen of alle tests nog werken. Als er een pull request naar de master wordt gemerged dan zal deze automatisch naar Azure worden gezet.
De master en development branch kan alleen naar worden geschreven door een pull request aan te maken, voor de master branch geldt dat er minimaal 4 mensen de pull request moeten goedkeuren en voor de development branch geldt dat er minimaal 2 goedkeurende reviews moeten zijn