Archi en VNGR modellen: verschil tussen versies

 
(11 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
{{Cocreatie
+
{{Publicatie
|Cocreatiepublicatie=Cocreatie
+
|Paginastatus=publiceren
 
|Redactiestatus=Actueel
 
|Redactiestatus=Actueel
|GEMMAOnlinebeheerder=Beheerder Architectuurtools
+
|Wikibeheerder=Beheerder Architectuurtools
 
}}
 
}}
[[Werken met VNGR architectuurmodellen|Overzichtpagina werken met VNGR architectuurmodellen]]
+
[[Category:ArchiMate modelleren]]
 +
{{DISPLAYTITLE: Werken in Archi met de GEMMA}}
 +
VNGR heeft gekozen om haar Archimate-modellen te ontwikkelen en beheren met Archi en git. Op deze pagina staat beschreven wat je nodig hebt om met Archi te kunnen werken en hoe je toegang krijgt tot de Archimate-modellen opgeslagen in de git-repositories.
  
VNGR heeft gekozen om haar architectuurmodellen te ontwikkelen en beheren met Archi en git. Op deze pagina staat beschreven wat je nodig hebt om met Archi te kunnen werken en hoe je toegang krijgt tot de architectuurmodellen opgeslagen in de git-repositories.
+
Zie de pagina [[Archi installeren]] voor instructies en links van plug-ins en configuratiebestanden
 
 
== Archi versie ==
 
 
 
Gebruik de nieuwste versie van Archi. De ervaring leert dat de Archi releases zeer stabiel zijn.
 
 
 
Voor het GEMMA architectuurmodel en de van de GEMMA afgeleide projectmodellen geldt de eis dat versie 4.7 of hoger moet worden gebruikt. Dit vanwege:
 
* ondersteuning voor ArchiMate 3.1 (vanaf Archi 4.6)
 
* het samenvoegen van projectmodellen en het GEMMA architectuurmodel (interne en geëxporteerde id's gelijk aan elkaar vanaf versie 4.7)
 
 
 
Zie de pagina [[Archi en plug-ins installeren]] voor instructies en links van plug-ins en configuratiebestanden
 
  
 
== Archi documentatie ==
 
== Archi documentatie ==
Regel 32: Regel 24:
 
** [https://github.com/archimatetool/archi/wiki Archi wiki] informatie voor ontwikkelaars en over ontwerpbeslissingen in Archi
 
** [https://github.com/archimatetool/archi/wiki Archi wiki] informatie voor ontwikkelaars en over ontwerpbeslissingen in Archi
  
== Werken met architectuurmodellen ==
+
== Werken met Archimate-modellen ==
  
Je kunt in Archi een architectuurmodel opslaan in een bestand (met .archimate extensie) of publiceren in een git-repository. Beide hebben hun bestaansrecht, kies voor
+
Je kunt in Archi een Archimate-model opslaan in een bestand (met .archimate extensie) of publiceren in een git-repository. Beide hebben hun bestaansrecht, kies voor
  
 
* opslaan in bestand  
 
* opslaan in bestand  
Regel 44: Regel 36:
 
** versiebeheer en samenwerken met een zelf te bepalen groep mensen
 
** versiebeheer en samenwerken met een zelf te bepalen groep mensen
  
De rest van deze paragraaf gaat ervan uit dat een architectuurmodel wordt gepubliceerd in een git-repository.
+
De rest van deze paragraaf gaat ervan uit dat een Archimate-model wordt gepubliceerd in een git-repository.
  
 
=== Hoe open je een in git gepubliceerd model ===
 
=== Hoe open je een in git gepubliceerd model ===
  
Om met Archi een bestaand architectuurmodel te openen, heb je alleen de URI van de git repository nodig.  
+
Om met Archi een bestaand Archimate-model te openen, heb je alleen de URI van de git repository nodig.  
  
Voorbeeld hoe je eenvoudig de publieke GEMMA repository kunt openen in Archi
+
Voorbeeld hoe je eenvoudig de publieke GEMMA ArchiMate-repository kunt openen in Archi
  
 
* met de browser
 
* met de browser
Regel 62: Regel 54:
 
** En je kunt het model in Archi bekijken
 
** En je kunt het model in Archi bekijken
  
Dit werkt voor architectuurmodellen die via git gepubliceerd zijn. Kijk bijvoorbeeld eens naar:
+
Dit werkt voor Archimate-modellen die via git gepubliceerd zijn. Kijk bijvoorbeeld eens naar:
  
 
* [https://github.com/canada-ca/architecture Open Government of Canada Architecture Git Repository]
 
* [https://github.com/canada-ca/architecture Open Government of Canada Architecture Git Repository]
 
* [https://github.com/smileham/archimate-metamodel-patterns ArchiMate Metamodel and Patterns]
 
* [https://github.com/smileham/archimate-metamodel-patterns ArchiMate Metamodel and Patterns]
  
Je kunt met Archi deze publieke architectuurmodellen bekijken en ook wijzigen. Je kunt de wijzigingen echter niet publiceren, hiervoor heb je schrijfrechten in de repository nodig. Maar je kunt de wijzigingen wel opslaan in een lokaal bestaan en eventueel vervolgens in je eigen git repository.  
+
Je kunt met Archi deze publieke Archimate-modellen bekijken en ook wijzigen. Je kunt de wijzigingen echter niet publiceren, hiervoor heb je schrijfrechten in de repository nodig. Maar je kunt de wijzigingen wel opslaan in een lokaal bestaan en eventueel vervolgens in je eigen git repository.  
  
Als je in een architectuurmodel wilt samenwerken en dus ook je wijzigingen in het model wilt kunnen publiceren, zul je bij de beheerder of eigenaar van de repository schrijfrechten moeten aanvragen.  
+
Als je in een Archimate-model wilt samenwerken en dus ook je wijzigingen in het model wilt kunnen publiceren, zul je bij de beheerder of eigenaar van de repository schrijfrechten moeten aanvragen.  
  
=== Versiebeheer voor een architectuurmodel ===
+
=== Versiebeheer voor een Archimate-model ===
  
Door een architectuurmodel niet in een bestand bewaren, maar in git te publiceren, beschik je over versiebeheer. Met git versiebeheer kun je wijzigingen als één bij elkaar horende set bewaren, in een commit. Archi toont in de Change history alle commits. Je kunt nu 'tijdreizen' door oude commits te openen, waarna je kunt bekijken hoe het model in een vorige versie in elkaar zat.
+
Door een Archimate-model niet in een bestand bewaren, maar in git te publiceren, beschik je over versiebeheer. Met git versiebeheer kun je wijzigingen als één bij elkaar horende set bewaren, in een commit. Archi toont in de Change history alle commits. Je kunt nu 'tijdreizen' door oude commits te openen, waarna je kunt bekijken hoe het model in een vorige versie in elkaar zat.
  
 
Als je het model niet met anderen hoeft te delen, dan kun je een persoonlijke git repository aanmaken. Dit kan bij alle git-providers, hieronder is gekozen voor GitLab.
 
Als je het model niet met anderen hoeft te delen, dan kun je een persoonlijke git repository aanmaken. Dit kan bij alle git-providers, hieronder is gekozen voor GitLab.
Regel 93: Regel 85:
 
Zie verder de wiki [https://github.com/archimatetool/archi-modelrepository-plugin/wiki coArchi – Model Collaboration for Archi] hoe je met Archi en versies werkt.
 
Zie verder de wiki [https://github.com/archimatetool/archi-modelrepository-plugin/wiki coArchi – Model Collaboration for Archi] hoe je met Archi en versies werkt.
  
== Samenwerken aan VNGR architectuurmodellen ==
+
=== Bekijken wijzigingen met git===
 +
 
 +
In Archi zie je in de ''change-history'' de lijst van commits, de commit message, door wie en wanneer deze is doorgevoerd. Maar je ziet niet in detail wat is gewijzigd. Onder water zijn alle wijzigingen met git te bekijken. Je kijkt dan in de XML-bestanden in de GEMMA-repository.
 +
 
 +
In Archi kun je de locatie van de lokale git-repository vinden:
 +
* open de tab ''Collaboration workspace''
 +
* selecteer de repository
 +
* ga naar de tab ''Properties'' > Information.
 +
* achter location staat de directory van lokale git-repository
  
Wil je met meerdere mensen aan één architectuurmodel samenwerken, dan zul je het model in een gedeelde git-repository moeten publiceren. Samenwerken vereist ook dat al deze mensen toegang tot de repository hebben en wijzigingen moeten kunnen publiceren.
+
Je kunt vanaf de command line met git commando's de wijzigingen opvragen. Of gebruik een grafische git-client en open de gevonden map in deze client.  
  
De VNGR architectuurmodellen worden gedeeld op GitLab onder de organisatie [https://gitlab.com/vng-realisatie VNG Realisatie]. Op GitLab kunnen de toegangsrechten als rollen aan gebruikers worden uitgedeeld.
+
=== GEMMA git-flow ===
  
We maken gebruik van vier rollen. Zie de pagina [https://docs.gitlab.com/ee/user/permissions.html Permissions] voor een overzicht van de mogelijke rechten per rol.
+
Voor het doorvoeren van wijzigingen in het GEMMA ArchiMate-model maken we gebruik van de git-flow [https://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model]. De GEMMA kent dan de volgende branches:
  
* Guest - voor het kunnen lezen van een private repository en het kunnen melden van issues
+
* '''master''', bevat de gepubliceerde stabiele releases
* Reporter - om ook issues te kunnen beantwoorden en oplossen
+
** dit is de hoofdbranch, die iedere repository heeft
* Developer - om ook te kunnen wijzigen in een repository
+
** releases worden vanuit de master-branch uitgevoerd nadat alle relevante wijzigingen uit de develop branch zijn gemerged
* Maintainer - om ook beheeracties in de repository te kunnen uitvoeren
+
* '''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
 +
** kleine wijzigingen en toevoegingen kunnen direct in de develop-branch worden doorgevoerd
 +
* '''feature''' branches; voor grote 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"
  
=== Waar vind je gedeelde VNGR architectuurmodellen ===
+
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.
  
De publieke groepen en projecten van VNGR zie als je niet bent ingelogd (of nog geen toegangsrechten hebt) en gaat naar https://gitlab.com/vng-realisatie. Je ziet daar de groep Architectuur met daarin de groep GEMMA en daarin weer het project GEMMA. Het GEMMA project is het GEMMA architectuurmodel dat je in Archi kan openen.
+
We maken geen gebruik van release-branches en hotfix-branches. Deze zijn niet relevant voor architectuurmodellen. We onderhouden tenslotte geen oude releases en kennen ook geen hotfixes.
  
Als je inlogt en je account heeft toegangsrechten op de VNGR Architectuur groep, dan zie je op je [https://gitlab.com/ GitLab homepagina] de repositories met daarachter de toegangsrechten. Zie je hier niet de repositories die je nodig hebt, vraag dan toegang tot deze repository aan.
+
==== Wanneer een feature-branch aanmaken ====
 +
Wat is een kleine wijziging die je direct in develop doorvoert en wanneer kies je nu voor een feature-branch?
  
[[Bestand:GitLab Your Projects.png|800px]]
+
'''Kleine wijziging'''
  
Als je kijkt onder [https://gitlab.com/dashboard/groups Groups > Your groups] zie hoe de repositories zijn verdeeld in groepen. Met de groepen worden de toegangsrechten ingesteld.
+
Een kleine wijziging is een wijziging die niet leidt tot conflicten met andere wijzigingen.
 +
* heeft een korte doorlooptijd van maximaal enkele dagen.
 +
* bestaat uit toevoegingen (een nieuwe standaardversie, een nieuwe view, ...)
 +
** een nieuwe standaardversie moet ook worden toegevoegd aan de (grote) publicatie-view. Check even met collega's of niet iemand anders deze ook wijzigt.  
 +
* de wijziging kan in de eerstvolgende release mee.
  
[[Bestand:GitLab Your Groups.png|800px]]
+
'''Grote wijziging'''
  
== Toegang aanvragen ==
+
Een grote wijziging is een fundamentele wijziging in de GEMMA
 +
* structuurwijziging in GEMMA modellering
 +
* verwerken projectresultaten in de GEMMA
 +
* veel wijzigingen die als één geheel mee kunnen in een release
 +
* doorlooptijd van meerdere werken
  
Om toegang te hebben tot de VNGR architectuurmodellen heb je een account op GitLab nodig. Dit account maak je zelf aan.  
+
maar let op dat de doorlooptijd niet veel langer wordt. Het mergen van een feature-branch nadat veel andere wijzigingen zijn doorgevoerd kan tot problemen leiden.
  
Voor VNGR architecten
+
==== Git troubleshooting ====
  
* Geef de naam van je GitLab account door aan Mark of Ivo en vraag of deze toegang kan krijgen tot de Architectuur groep
+
'''Merge Branch error: File is not directory or folder.xml not exist'''
* 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
+
De fout [https://forum.archimatetool.com/index.php?topic=988.0 File is not directory or folder.xml not exist] is eigenlijk niet op te lossen indien deze optreed bij het mergen van een feature-branch die lang heeft open gestaan. Een deel van de wijzigingen zullen opnieuw moeten worden uitgevoerd.
  
Alle gemeenten kunnen toegang aanvragen tot de VNGR modellen. Je GitLab account krijgt dan leesrechten en kunt je kunt vrij rondkijken.
+
Fout is ook opgetreden bij het mergen van development met master. Oplossing hier was om master te vervangen door development
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.
+
* zie [https://stackoverflow.com/questions/2862590/how-to-replace-master-branch-in-git-entirely-from-another-branch How to replace master branch in Git, entirely, from another branch?]
  
* Stuur een mail met de naam van je GitLab account aan mark.backer@vng.nl met het verzoek om toegang.
+
<pre>
 +
git checkout master
 +
git pull
 +
git checkout development
 +
git merge -s ours master
 +
git checkout master
 +
git merge development
 +
</pre>

Huidige versie van 6 mrt 2024 om 03:00


VNGR heeft gekozen om haar Archimate-modellen te ontwikkelen en beheren met Archi en git. Op deze pagina staat beschreven wat je nodig hebt om met Archi te kunnen werken en hoe je toegang krijgt tot de Archimate-modellen opgeslagen in de git-repositories.

Zie de pagina Archi installeren voor instructies en links van plug-ins en configuratiebestanden

Archi documentatie[bewerken]

Hier een aantal links voor meer Archi documentatie en tips:

Werken met Archimate-modellen[bewerken]

Je kunt in Archi een Archimate-model opslaan in een bestand (met .archimate extensie) of publiceren in een git-repository. Beide hebben hun bestaansrecht, kies voor

  • opslaan in bestand
    • snel, geen voorbereiding nodig en kan altijd later alsnog in git worden beheerd
    • voor wat 'plaatjes' zonder versiebeheer en samenwerking via de mail
  • publiceren in git-repository
    • bewerkelijker, maar gaat snel als je het vaker doet.
    • versiebeheer voor persoonlijk gebruik
    • versiebeheer en samenwerken met een zelf te bepalen groep mensen

De rest van deze paragraaf gaat ervan uit dat een Archimate-model wordt gepubliceerd in een git-repository.

Hoe open je een in git gepubliceerd model[bewerken]

Om met Archi een bestaand Archimate-model te openen, heb je alleen de URI van de git repository nodig.

Voorbeeld hoe je eenvoudig de publieke GEMMA ArchiMate-repository kunt openen in Archi

  • met de browser
  • met Archi
    • Collaboration > import remote model to workspace
    • plak de git URL in de pop-up
    • En je kunt het model in Archi bekijken

Dit werkt voor Archimate-modellen die via git gepubliceerd zijn. Kijk bijvoorbeeld eens naar:

Je kunt met Archi deze publieke Archimate-modellen bekijken en ook wijzigen. Je kunt de wijzigingen echter niet publiceren, hiervoor heb je schrijfrechten in de repository nodig. Maar je kunt de wijzigingen wel opslaan in een lokaal bestaan en eventueel vervolgens in je eigen git repository.

Als je in een Archimate-model wilt samenwerken en dus ook je wijzigingen in het model wilt kunnen publiceren, zul je bij de beheerder of eigenaar van de repository schrijfrechten moeten aanvragen.

Versiebeheer voor een Archimate-model[bewerken]

Door een Archimate-model niet in een bestand bewaren, maar in git te publiceren, beschik je over versiebeheer. Met git versiebeheer kun je wijzigingen als één bij elkaar horende set bewaren, in een commit. Archi toont in de Change history alle commits. Je kunt nu 'tijdreizen' door oude commits te openen, waarna je kunt bekijken hoe het model in een vorige versie in elkaar zat.

Als je het model niet met anderen hoeft te delen, dan kun je een persoonlijke git repository aanmaken. Dit kan bij alle git-providers, hieronder is gekozen voor GitLab.

  • met de browser
    • Ga naar Project > Your projects
    • Maak een nieuw project met daarin een repository (groene button rechts boven [new project])
      • Geef een naam en kies voor private (standalone) of public (publiceren of samenwerken)
    • Copy de URL, kies voor SSH of HTTPS
  • Open Archi
    • Maak een nieuw model aan of open een bestaand model in een bestand. Het model mag helemaal leeg zijn.
    • Collaboration > Add local model to workspace and publish
      • plak de git URL in de pop-up
    • Het model is nu gelinkt aan de GitLab-repository.
      • opslaan bewaart het model in een lokaal bestand
      • commit maakt een nieuwe versie aan in de lokale git-repository
      • publish publiceert de laatste versie bij GitLab

Zie verder de wiki coArchi – Model Collaboration for Archi hoe je met Archi en versies werkt.

Bekijken wijzigingen met git[bewerken]

In Archi zie je in de change-history de lijst van commits, de commit message, door wie en wanneer deze is doorgevoerd. Maar je ziet niet in detail wat is gewijzigd. Onder water zijn alle wijzigingen met git te bekijken. Je kijkt dan in de XML-bestanden in de GEMMA-repository.

In Archi kun je de locatie van de lokale git-repository vinden:

  • open de tab Collaboration workspace
  • selecteer de repository
  • ga naar de tab Properties > Information.
  • achter location staat de directory van lokale git-repository

Je kunt vanaf de command line met git commando's de wijzigingen opvragen. Of gebruik een grafische git-client en open de gevonden map in deze client.

GEMMA git-flow[bewerken]

Voor het doorvoeren van wijzigingen in het GEMMA ArchiMate-model maken we gebruik van 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
    • kleine wijzigingen en toevoegingen kunnen direct in de develop-branch worden doorgevoerd
  • feature branches; voor grote 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"

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. Deze zijn niet relevant voor architectuurmodellen. We onderhouden tenslotte geen oude releases en kennen ook geen hotfixes.

Wanneer een feature-branch aanmaken[bewerken]

Wat is een kleine wijziging die je direct in develop doorvoert en wanneer kies je nu voor een feature-branch?

Kleine wijziging

Een kleine wijziging is een wijziging die niet leidt tot conflicten met andere wijzigingen.

  • heeft een korte doorlooptijd van maximaal enkele dagen.
  • bestaat uit toevoegingen (een nieuwe standaardversie, een nieuwe view, ...)
    • een nieuwe standaardversie moet ook worden toegevoegd aan de (grote) publicatie-view. Check even met collega's of niet iemand anders deze ook wijzigt.
  • de wijziging kan in de eerstvolgende release mee.

Grote wijziging

Een grote wijziging is een fundamentele wijziging in de GEMMA

  • structuurwijziging in GEMMA modellering
  • verwerken projectresultaten in de GEMMA
  • veel wijzigingen die als één geheel mee kunnen in een release
  • doorlooptijd van meerdere werken

maar let op dat de doorlooptijd niet veel langer wordt. Het mergen van een feature-branch nadat veel andere wijzigingen zijn doorgevoerd kan tot problemen leiden.

Git troubleshooting[bewerken]

Merge Branch error: File is not directory or folder.xml not exist

De fout File is not directory or folder.xml not exist is eigenlijk niet op te lossen indien deze optreed bij het mergen van een feature-branch die lang heeft open gestaan. Een deel van de wijzigingen zullen opnieuw moeten worden uitgevoerd.

Fout is ook opgetreden bij het mergen van development met master. Oplossing hier was om master te vervangen door development

git checkout master
git pull
git checkout development
git merge -s ours master
git checkout master
git merge development
Deze pagina is het laatst bewerkt op 6 mrt 2024 om 03:00.