Samenwerken en git


Overzichtpagina werken met VNGR architectuurmodellen


Toegang aanvragen[bewerken]

Om toegang te hebben tot de VNGR architectuurmodellen heb je een account op GitLab nodig. Dit account maak je zelf aan.

Voor VNGR architecten

  • Geef de naam van je GitLab account door aan Mark of Ivo en vraag of deze toegang kan krijgen tot de Architectuur groep
  • Als je ook in een VNGR repository wilt kunnen wijzigen, kijk dan in GitLab wie de maintainer is van de bovenliggende groep of van de repository. Vraag bij de maintainer toegang aan.

Voor gemeenten

Alle gemeenten kunnen toegang aanvragen tot de VNGR modellen. Je GitLab account krijgt dan leesrechten en kunt je kunt vrij rondkijken. Er is ook een map aangemaakt voor gemeenten waarin gemeenten onderling kunnen samenwerken aan architectuurmodellen. Je kunt hier ook de architectuurmodellen van je eigen gemeente beheren en delen met anderen. Als je hier interesse in hebt en hier over wilt meedenken, laat het weten.

  • Stuur een mail met de naam van je GitLab account aan mark.backer@vng.nl met het verzoek om toegang.

GEMMA git-flow[bewerken]

Aanzet voor hoe we in de GEMMA repository omgaan met branches.

Voorstel voor is om te kiezen voor de git-flow A successful Git branching model. De GEMMA kent dan de volgende branches:

  • master, bevat de gepubliceerde stabiele releases
    • dit is de hoofdbranch, die iedere repository heeft
    • releases worden vanuit de master-branch uitgevoerd nadat alle relevante wijzigingen uit de develop branch zijn gemerged
  • develop, bevat de meest actuele opgeleverde nieuwe onderdelen.
    • hiervandaan worden feature branches aangemaakt.
    • als een feature is afgerond, wordt deze weer in de develop-branch gemerged
  • feature branches; voor iedere uitbreiding/wijziging op de GEMMA wordt een feature branche gemaakt
    • de naam van een feature branches refereert aan wat gemaakt wordt. Bijvoorbeeld de feature "Impactanalyse BRK" of "WOO"
    • Nog te bepalen. Moeten featurebranches altijd weer gemerged worden met de develop branche? of kunnen feature voor tussenresultaten gewoon op zich zelf blijven bestaan? Bijvoorbeeld een plaat die niet in de GEMMA thuishoort, maar die je wel wilt bewaren als feature?

Voordelen van deze werkwijze is dat releases gecontroleerd samengesteld kunnen worden door de 'maintainers' van de master branche. Ondertussen kunnen architecten onafhankelijk van de release-cycle werken aan features. Zodra een feature af is wordt deze gemerged met de develop branche om te worden opgenomen in een volgende release.

We maken geen gebruik van release-branches en hotfix-branches. Voor nu lijkt dat relevanter voor softwareontwikkeling dan voor architectuurmodellen.

Deze pagina is het laatst bewerkt op 24 aug 2020 om 16:44.