In sync houden TAP-straat

En de idealistische toekomst

Auteur: Joeri Bekker | Status: In voorbereiding

TODO:

• Utrecht zit op de handmatigere lijn

• Den Haag zit op de automatische CI/CD lijn

• Wiebe vind dat het om een tijdspad is: van wat werkt nu, wat we willen in de toekomst.

Disclaimer

Op deze pagina wordt ingegaan op specifieke problemen uit de praktijk. Dit zegt niet perse iets over de organisaties, personen, producten, patronen, achterliggende concepten of Common Ground, maar wel wat er beter kan en waar aan gewerkt moet worden.

Inleiding

Voor problemen in de praktijk moeten er vaak snel oplossingen gerealiseerd worden om de dienstverlening niet in gevaar te brengen. Dit kan in sommige gevallen leiden tot suboptimale oplossingen. Het is niet erg dat suboptimale oplossingen worden toegepast maar het moet wel inzichtelijk worden wat de ideale oplossing is, en hoe we daar naar toe werken.

Ultieme doel

Een functioneel beheerder behoeft enkel op de testomgeving wijzigingen te maken. Als dat klaar is, is het aan het CI/CD team om dit op acceptatie en productie te krijgen.

De volgende aspecten moeten van omgeving A naar B :

• Installatie / Softwarecomponenten -> Platform beheer

• Technische configuratie (koppelingen) -> Platform beheer

• Inrichting / Artefacts / Functionele inrichting -> (Functionele) ontwikkelteams

Pijnpunten

Pijnpunten techniek (veelal herhalend)

• Gebruik van URLs in de data(exports) en andere URLs per omgeving

• UUIDs verschillen per omgeving, moet dat gelijk getrokken worden?

• Zaaktypen veranderen nu van UUID als je een versie update doet (rechten?)

  • Probleem in de standaard

  • Er zijn geen rechten te regelen per catalogus

• Er moeten configuraties van component X en Y in één keer, tegelijk, van omgeving A naar B

• Er zit wat frictie tussen installatie van versies, en dat configuratie compilatie (en dus nieuwe versie) nodig heeft.

Pijnpunten architectuur (veelal eenmalig)

• Voor autorisaties moet veel geregeld worden bij verschillende componenten

• Fragiel: Formulier -> Verzoek (Object) -> ESB vertaalslag -> Zaaksysteem -> Commutr

• Onderlinge afhankelijkheden zijn niet inzichtelijk nu, op zowel component als configuratie niveau.

Pijnpunten proces (veelal herhalend)

• (Utrecht) Productomgeving Open Zaak (geen kanalen) was niet goed ingericht door gemeente zelf, was wel gevalideerd door gemeente zelf...

• (Utrecht) Productie Open Formulieren had verkeerde Objecttype UUIDs geconfigureerd.

• (Utrecht) Leverancier A past configuratie aan van component van Leverancier B

• (Utrecht)Alles moest heel ad-hoc, als in 1 dag voor de deadline bleek iets niet te werken

• (Den Haag) Niet final-versies mogen niet worden uitgerold op acceptatie

• Wie rolt nu wat uit en wanneer? (sommige gemeenten doen maar wat, terwijl contractueel iets anders is afgesproken)

• (Utrecht) Waarom communicatie via escalatie pad

• Documentatie van wat er allemaal met elkaar verbonden is, zodat je weet hoe en wat bekeken moet worden bij updates?

Scope

Datgeen dat nodig is om een zaakproces met al haar afhankelijkheden van een testomgeving naar een volgende omgeving te brengen.

Buiten scope

Koppelingen die eenmalig gelegd moeten worden, zijn buiten scope. Koppelingen die wijzigen door toevoegingen of wijzigingen aan processen.

• Archiefbeheercomponent, behoeft (straks, zie kaartje) geen aanvullende configuratie bij een nieuw zaaktype

• Open Klant, behoeft geen aanvullende configuratie bij een nieuw zaaktype

• Authenticatie, behoeft geen aanvullende configuratie per zaaktype

• Kiss, behoeft geen aanvullende configuratie per zaaktype

• FSC, NLX

• NotifyNL

Conceptbesluiten

• Ieder artifact moet een unieke identifieer, liefst human readable en een versionering hebben.

Woordenboek

A: Artefact: gegevensset die altijd meeverhuist naar een nieuwe omgeving

P: Probleem: gegevensset die nader bekeken moet worden

C: Configuratie: gegevensset die niet meeverhuist naar een nieuwe omgeving

HRI: Human readable identifier

Vraagstukken

• Versionering van componenten

• Iets rondom uniformiteit van uuid’s

• Onderscheid tussen handmatige configuratie vs geautomatiseerde configuratie

Inventarisatie per component

Open Formulieren

• Formulierdefinitie A

• Vormgeving AP

• Formuliercategorieen AP

• Herbruikbare formulierstappen AP

• Objecttypen mapping AP

• Technische koppeling CP

Objectregister

• Objecttype definitie A

• Autorisaties AP

  • Bevat api-key

Open Notificaties

• Abonnementen AP

• Kanalen A

• Credentials?

GZAC

Casedefinitie (zip-baar)

• BPMN A

• DMN tabellen A

• Dossierdefinitie A

• Plugin actions A HRI

• Formulierdefinities A

• Form flow A

• PBAC A ..

• Dossier werklijstindeling A

• Proceskoppelingen A

• Technische koppelingen (zaaktypen, etc)

Knelpunt bouwblokken / gedeelde artifacts P

• Widgets A

• Kotlin-code A

Noot: verzoek om álle plug-in actions

Bedrijfsregels

• DMN A

• Autorisaties?

Documentcreatie

• Template A

• Autorisatie P

Open Zaak

• Catalogus A

• Zaaktypedefinitie A

• Besluittype A

• Documenttype A

• Autorisaties AP

• Verbinding met Open Notificaties

Mail

• Templates A

• Afzenders A

• Adressen C

Klantportaal

• Vertalingen A

• Thema’s P

Archiefbeheercomponent

• Zaaktypespecifieke archieveringsparameters P

  • Liefst verwerken in ZTC

Referentielijsten API

• De lijst AP

IAM

• eHerkenning Machtiging P

• Rollen P

Best practices en werkpakketten die daaruit volgen

Deployments moeten artefacten inlezen vanaf een volume

Volume bevat ALLE artefacten (of niet, boeit niet), laad alle gewijzigde artefacten in. Bepaal of iets gewijzigd is op basis van een hash.

PROBLEEM: Versies pas bij export ophogen? Wat als je versie 18 van een objecttype hebt op O, en acceptatie draait nu versie 3. Welke versie nummer krijgt dit objecttype op acceptatie? 4 of 18? Indien 18, dan zijn de oude versies ook nodig? Hebben we een platform versie en een meta-versie?

Proces: Iedereen levert de export aan van het UI werk op de O-omgeving. Als de overkoepelend projectmanager alle exports aangeleverd heeft, dan wordt het geheel uitgerold, waarna keten testen kunnen plaatsvinden. Op de T-omgeving mag je natuurlijk ook tussendoor uitrollen.

Voorbeeld mapjes op het volume voor de T-omgeving

Proces Stadspas aanvragen (dit totaal heet een bundel)

• Open Zaak

  • Zaaktype Stadspas aanvragen versie 1

  • Documenttype: Bijlage versie 1

• GZAC

  • BPMN Stadspas aanvragen versie 1

  • BPMN Stadspas aanvragen versie 2

  • BPMN Stadspas aanvragen versie 3 (afhankelijkheid van DMN Postcodegebied versie 1)

  • DMN Postcodegebied versie 1 (verwijzing/symlink naar Generiek)

• Objecttype

  • Objecttype Stadspas verzoek versie 1

  • Objecttype Stadspas verzoek versie 2

• Open Formulieren

  • Formulier Stadspas aanvragen versie 1

Generiek

• GZAC

  • DMN Postcodegebied versie 1

Het mapje van de T-omgeving wordt na keten-testen gesynced met de A en P-omgeving

Artefacten moeten idempotent zijn (unieke sleutel + versie)

• Open Formulieren: Herbruikbaar formulierdefinities

• GZAC: Artefacten moeten nagelopen worden

Configuratie opslag van UUIDs en URLs voorkomen door unieke sleutel op te slaan

• Open Formulieren

• GZAC (Plugin-actions: zaaktypen, besluittypen, documenttypen)

Artefacten export van data zonder UUIDs en URLs maar met unieke sleutels

• Open Formulieren: Formulieren, Categorien, Themas

• Open Zaak: Catalogi API (zaaktypen, besluittypen, documenttypen)

• Open Klant

• Objecttypen API: Zorg voor een unieke sleutel die niet de UUID is

• Referentielijsten API: Moet export mogelijkheid komen

Artefacten exporteren met verwijzingen naar koppelingen, zonder de daadwerkelijke koppelingsgegevens (bijv. Formuliern gebruikt Zaken API #1)

• Open Formulieren: Koppelingen met unieke sleutel aanduiden (die gelijk met zijn over omgevingen), en in exports opnemen

Notificatieabonnementen bij elke deploy aanmaken/verifiëren

• GZAC: Deploy/Init aanpassen

• Objecttypen API: deploy/init aanpassen

• Open Zaak: deploy/init aanpassen (al gedaan met setupconfig?)

Gedeelde configuratie/bouwblokken in een artefact overschrijven

• Open Formulieren

Overige

Bij het zaaktype opnemen van hoe je omgaat met archivering (4 ogen principe, of in bulk of niet)

Casedefinition is een zip met alles BPMN, DMN, formulieren, etc.). Hoe om te gaan met gedeelde bouwblokken (=artefacten) en dit is hetzelfde met Open Formulieren en gedeelde formulier definities.