VNG-Realisatie · SonnyBA · Apr 26, 2022 · Apr 26, 2022 · Apr 26, 2022 · May 6, 2022
diff --git a/docs/_content/ontwikkelaars/handleidingen-en-tutorials/git-branch-model.md b/docs/_content/ontwikkelaars/handleidingen-en-tutorials/git-branch-model.md
@@ -0,0 +1,45 @@
+---
+title: "OneFlow branching model"
+date: '22-04-2022'
+weight: 20
+---
+
+Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching
+model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan
+met dit type branch model.
-Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching
-model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan
-met dit type branch model.
+Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching
+model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model.
-Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching
-model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan
-met dit type branch model.
+Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching
+model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model.
-Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching
-model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan
-met dit type branch model.
+Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching
+model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model.
-Het ontwikkelen van de ZGW componenten gebeurd aan de hand van het git branching
-model "[OneFlow]". In deze tutorial wordt beschreven hoe een je om dient te gaan
-met dit type branch model.
+Het ontwikkelen van de ZGW componenten gebeurt aan de hand van het `git`-branching
+model "[OneFlow]". Dit document beschrijft hoe je om dient te gaan met dit type branch model.
+
+## Standaard branch
+Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
+`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
-## Standaard branch
-Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
-`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+## Standaardbranch
+
+Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
+`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+
+Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`.
-## Standaard branch
-Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
-`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+## Standaardbranch
+
+Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
+`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+
+Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`.
-## Standaard branch
-Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
-`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+## Standaardbranch
+
+Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
+`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+
+Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`.
-## Standaard branch
-Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
-`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+## Standaardbranch
+
+Voor het aanmaken van nieuwe features of bugfixes dien je gebruik te maken van de 
+`master` branch tenzij je een feature of bugfix wilt toevoegen voor een specifieke versie.
+
+Bijvoorbeeld `git checkout -b feature/some-feature master` of `git checkout -b issue/some-bugfix stable/1.2.x`.
+
+## Testomgevingen
+Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
+te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
+van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren:
-Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
-te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
-van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren:
+Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
+te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
+van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren:
-Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
-te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
-van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren:
+Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
+te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
+van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren:
-Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
-te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
-van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren:
+Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
+te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
+van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren:
-Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
-te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
-van een specifieke commit. Bij het gebruik van een git tag dien je het volgende format te hanteren:
+Voor testomgevingen wordt gebruikt gemaakt van de `master` branch. Om een nieuwe versie 
+te deployen kan je als ontwikkelaar een [git tag] gebruiken of gebruik maken van de sha-256 checksum
+van een specifieke container image. Bij het gebruik van een git tag dien je het volgende format te hanteren:
+```
+1.3.0-alpha1
+```
+
+## Productieomgevingen
+Productieomgevingen worden alleen gebruikt in combinatie met daadwerkelijke release versies. 
+Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`.
-Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`.
+Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`.
-Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`.
+Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`.
-Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`.
+Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`.
-Voor deze versies is altijd een branch aangemaakt met het volgende format: `<major>.<minor>.x`.
+Voor deze versies is altijd een branch aangemaakt met het volgende format: `stable/<major>.<minor>.x`.
+Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
+aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
+daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`).
-Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
-aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
-daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`).
+Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
+aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
+daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`).
-Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
-aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
-daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`).
+Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
+aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
+daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`).
-Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
-aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
-daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`).
+Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
+aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
+daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`).
-Een voorbeeld hiervan zou kunnen zijn: `1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
-aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
-daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `1.3.x`).
+Een voorbeeld hiervan zou kunnen zijn: `stable/1.2.x`. Alleen bugfixes kunnen nog toegevoegd worden
+aan deze branches. Een nieuwe minor of major versie betekent een nieuwe release en 
+daarbij een nieuwe branch (bijvoorbeeld in het geval van een nieuwe minor release `stable/1.3.x`).
+
+## Bugfixes en features
+Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch tenzij
+het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast
+gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten
+naar specifiek releases. Wanneer het gaat om zogenaamde "breaking changes" dien je
+altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`).
-Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch tenzij
-het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast
-gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten
-naar specifiek releases. Wanneer het gaat om zogenaamde "breaking changes" dien je
-altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`).
+Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch, tenzij
+het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast
+gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten
+naar specifieke releases. Wanneer het gaat om zogeheten "breaking changes" dien je
+altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`).
-Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch tenzij
-het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast
-gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten
-naar specifiek releases. Wanneer het gaat om zogenaamde "breaking changes" dien je
-altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`).
+Ook bugfixes en nieuw features zijn idealiter gericht naar de `master` branch, tenzij
+het gaat om een bugfix of feature voor een specifieke release. Er kan daarnaast
+gekozen worden om de bugfix niet alleen naar `master` toe te richten maar ook te backporten
+naar specifieke releases. Wanneer het gaat om zogeheten "breaking changes" dien je
+altijd een nieuwe release te doen en hiermee ook de major versie op te hogen (e.g van `1.1.1` naar `2.0.0`).
+
+## Aandachtspunten
+Om een versie van een ZGW component op te hogen dienen je rekening te houden met
+een aantal punten:
+1. Het ophogen van het versienummer gaat normaliter via de `API_VERSION` setting in je Django settings
+2. Om de API specificaties up-to-date te brengen dien je het `generate_schema` management commando te draaien welke onder andere de openapi specificatie update
+3. Indien je een release of release-candidate uitbrengt dien je ook het `CHANGELOG.rst` bestand uit te breiden met de wijzingingen die zijn gedaan
+
+[OneFlow]: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow
+[git tag]: https://git-scm.com/book/en/v2/Git-Basics-Tagging#_lightweight_tags
diff --git a/docs/_content/ontwikkelaars/index.md b/docs/_content/ontwikkelaars/index.md
@@ -17,11 +17,12 @@ De handleidingen vormen een algemene introductie voor ontwikkelaars die met de Z
 5. [Large files upload (Engels)](./handleidingen-en-tutorials/large-files)
 
 ### Tutorials
-Tutorials zijn introducties gericht op specifieke functionaliteiten binnen de ZGW API's. Deze tutorials Ze zijn ontwikkeld voor gebruik tijdens API lab-bijeenkomsten, maar kunnen ook individueel doorlopen worden.
+Tutorials zijn introducties gericht op specifieke functionaliteiten binnen de ZGW API's. Deze tutorials zijn ontwikkeld voor gebruik tijdens API lab-bijeenkomsten, maar kunnen ook individueel doorlopen worden.
 1. [Eenmalige setup van de referentie-implementaties](./handleidingen-en-tutorials/eenmalige-setup)
 2. [Aan de slag met notificeren](./handleidingen-en-tutorials/notificeren)
 3. [Aan de slag met archiveren](./handleidingen-en-tutorials/archiveren) 
 4. [Crashcourse zaakgericht werken voor ontwikkelaars PDF](./handleidingen-en-tutorials/20201208%20-%20Crash%20course%20zaakgericht%20werken%20voor%20CG-ontwikkelteams_v1_0.pdf)
+4. [Git branch model binnen ZGW](./handleidingen-en-tutorials/git-branch-model)
 
 ## Testomgevingen
 
@@ -50,7 +51,7 @@ Deze omgevingen zijn:
 **Volgende release**
 
 Deze omgevingen zijn de nieuwe versies die in ontwikkeling zijn. Ze worden
-continue bijgewerkt op basis van de `develop` branch van de
+continue bijgewerkt op basis van de `master` branch van de
 referentieimplementaties. Deze omgevingen dienen om nieuwe features uit te
 testen en bugs op te sporen.