Deployen van deelfunctionaliteit

[PeterVanBragt]

Doel

Het uitrollen van een gedefinieerde set aan functionaliteiten op een omgeving (TEST, ACC of PROD) in tegenstelling tot het doorzetten van alle functionaliteiten van de ene omgeving naar de volgende.

Context / achtergrond

In een breed gebruikte applicatie moet het mogelijk zijn om slechts de goedgekeurde deelfunctionaliteit door te zetten naar de volgende fase. Met fasen worden hier de systemen test, acceptatie en productie bedoeld.

Op dit moment is het alleen mogelijk om de volledige functionaliteit van het acceptatiesysteem naar het productie systeem over te zetten. Concreet betekende dit onlangs dat bij het in productienemen van de doorontwikkeling van een bestaand proces, een proces in ontwikkeling ook op productie is geïntroduceerd. Vervolgens is na de uitrol met behulp van de rechten op dit — nieuwe en in ontwikkeling zijnde — proces het zicht en gebruik voor medewerkers verborgen.

Bij nieuwe processen is dit een onwenselijke maar werkbare procedure.

Het wordt onwerkbaar op het moment dat er aan twee processen die in productie zijn wijzigingen worden aangebracht. Als alleen een volledig systeem kan worden overgezet moeten de wijzigingen op alle processen zijn goedgekeurd voordat de overgang naar productie kan plaatsvinden. Dit kan leiden tot afhankelijkheden op basis van:

• Doorlooptijden in de ontwikkeling
• Planningen voor de business processen
• Planningen tussen afdelingen

Wat moet er gebeuren - wat is er nog niet en hebben we wel nodig?

Om deelfunctionaliteit te kunnen uitrollen is ten eerste een lijst van onderdelen nodig die samen de deelfunctionaliteit bepalen. Onderdelen die wij al geidentificeerd hebben:

• Configuratie per process. o.a.:
  • BPMN file, Proceskoppelingen, DMN tabellen, Formulierdefinities & Formulierkoppelingen, etc.
• Configuratie generiek / gedeeld
  • Generieke processen en bijhoren
• Code per proces
  • Kotlin code
• Code generiek / gedeeld
  • Kotlin code
• Omgevingsspecifieke configuratie / variabelen
  • Objectdefinities
  • UUIDs van zaaktypen etc.
• Valtimo/GZAC core (Hier missen wellicht nog een aantal artifacts)

Deze kunnen per item (of eventueel gecombineerd) apart opgeslagen en geversioneerd worden.

• Om de situatie werkbaar te houden lijkt het handig om zo veel mogelijk artifacts die bij elkaar horen samen te houden om het aantal artifacts & versies overzichtelijk te houden.

Verder is er een wens om ook gerelateerde functionaliteiten die buiten de directe scope van GZAC vallen ook op deze manier the managen. Denk hierbij aan:

• Migratiescripts voor het aanpassen van dataobjecten die betrokken zijn bij deze uitrol
  • Procesvariabelen
  • Zaaktypen
  • Zaakstatussen
  • Gegevens in OpenObjecten objecten

Ten tweede moet er een administratie/registratie komen om alle samenhangende versies in kaart te kunnen brengen en te loggen.

• Dit kan apart getrokken worden of misschien afgeleid van gedeployde versies...

Ten derde is het voorstel om alle configuratie zoals hierboven genoemd wordt lost te trekken van de bestaande code repository en in een of meerdere repositories te zetten. Gesupport door logica om per process versies te kunnen deployen.

Technische toevoegingen / gedachten

• Code zal wellicht moeilijk uit elkaar te trekken zijn. Er valt in ieder geval al gigantische winst te behalen als we de configuratie per process uit elkaar kunnen trekken
  • Code zou wel evt. via libraries ingeladen kunnen worden?
• Er zal gezord moeten worden dat alle configuratie die in de UI gedaan kan worden ook extern kan worden opgeslagen, zoals in GIT zodat alle artifacts voor een process bij elkaar kunnen staan
• Er zijn voor een deelfunctionaliteit 2 soorten configuratie. Configuratie die het zelfde is over alle omgevingen (Bijv. een bpmn file) en die verschillend zijn per omgeving (Bijv. een UUID ZaakType). Hier moet rekening mee gehouden worden tijdens het design van de oplossing
• Er zijn verschillende manieren voor opzet van de repositories & automatisering. Jan (Brekelmans) kan hier over mee brainstormen aangezien hij in het verleden een vergelijkbare opzet voor voor blueriq developers gemaakt heeft.

Wat is het eindresultaat?

De mogelijkheid om deelfunctionaliteiten uit te rollen op een omgeving. In eerste instantie beperkt tot het uitrollen van een proces inclusief alle betrokken onderdelen. Hierbij wordt gestreefd naar een op korte termijn haalbaar niveau van automatisering om de hoeveelheid handwerk en kans op fouten tijdens de uitrol te beperken.

Kortom; Het resultaat zou moeten zijn dat alleen generieke artifacts afhankelijkheden zijn tussen processen.

Wat valt er buiten scope?

Configuratie van externe systemen zoals open zaak & open formulieren. Dat gezegd, de koppeling tussen GZAC en externe system die vastgelegd worden in GZAC vallen natuurlijk wel binnen scope. Bijv. UUID van zaaktype voor een omgeving.

Impact - hoeveel inspanning kost dit?

Inschatting door PO: S/M/L/XL Inschatting door SA: S/M/L/XL

Besluiten roadmap overleg

[rutger-h]

Zou "Het uitrollen van een gedefinieerde set aan functionaliteiten" een 'dossier-type' moeten zijn? Lees: je kan proces X doorrollen zonder proces Y?

[JanBrek]

@rutger-h Je 2e deel klopt, dat is het doel inderdaad. Verder heeft dit item wel een iets grotere scope. Alles wat bij een process hoort zoals BPMN, specifieke code, etc, en dus niet alleen het dossier(type)

[rutger-h]

Eens even gekeken wat de wereld om ons heen doet. Ik zie dat dit meer wordt gedaan, met 'deployment packages'.

• Salesforce: https://help.salesforce.com/s/articleView?id=sf.se_task_create_deployment_package.htm&type=5
• Google: https://cloud.google.com/marketplace/docs/partners/vm/create-deployment-package
• Mendix: https://www.mendix.com/evaluation-guide/enterprise-capabilities/platform-architecture/

[rutger-h]

Orkestratietool: https://octopus.com/docs/github