🔁 Change & Delivery

Hoe wijzigingen gecontroleerd van idee naar productie bewegen.

← Terug naar Solution Engineering

🧭 Introductie

Change & Delivery beschrijft hoe wijzigingen (changes) gecontroleerd door de lifecycle bewegen: van eerste idee tot productie en nazorg.

Het doel is om een voorspelbare, herhaalbare en beheersbare delivery flow te realiseren, waarbij iedere wijziging traceerbaar is over de volledige keten: requirement → development → testing → release → productie.

💡 Kernprincipe: Iedere change is herleidbaar, gevalideerd en gecontroleerd uitgerold.

🎯 Doel van Change & Delivery

  • Beheerst doorvoeren van wijzigingen
  • Voorspelbare release cycles
  • Minimale risico’s bij productie deployments
  • Volledige traceability (end-to-end)
  • Duidelijke scheiding tussen build, release en deploy

🔁 Standaard Change Flow

Idea → Requirement → User Story → Development → Testing → Release → Deploy → Operate → Feedback

Deze flow volgt de ALM lifecycle en zorgt voor consistente kwaliteit en governance.

📦 Soorten Changes

Type Beschrijving Gebruik
Minor change Voorspelbaar, laag risico Kleine configuratie
Regular change Reguliere change met validatie Nieuwe functionaliteit
Emergency change Spoedwijziging Incident / productieissue
⚠️ Emergency changes vereisen altijd achteraf validatie en integratie.

🔗 Traceability

Iedere change moet volledig traceerbaar zijn over alle lagen: 

Requirement → Story → Task → Code → Test → Release → Deployment

Dit vormt de basis voor governance, audits en quality control.

⚙️ Governance & Controls

  • Alle changes worden geregistreerd in backlog (DevOps)
  • Geen directe wijzigingen buiten DEV
  • Deployments uitsluitend via pipelines
  • Verplichte testfasen (Unit / Integration / UAT)
  • Go/No-Go moment vóór productie
📌 Geen change zonder traceability — geen deployment zonder validatie.

⚡ Power Platform – Release & Delivery Strategie

Binnen Power Platform gelden aanvullende richtlijnen vanwege het gebruik van Dataverse solutions, pipelines en solution layering.

📦 Release types

Type Beschrijving Wanneer gebruiken
Normale release Bundel van changes Sprint / geplande release
Patch Kleine bugfix (delta) Correcties zonder scope uitbreiding
Hotfix Urgente productie fix Incident / verstoring

🧭 Hoe ga je hiermee om?

  • Normale release: altijd via volledige OTAP flow
  • Patch: alleen delta deployen, geen nieuwe functionaliteit
  • Hotfix: alleen productieprobleem oplossen, daarna terug integreren
⚠️ Hotfixes mogen nooit een “los pad” vormen — altijd terug naar de hoofdontwikkeling.

🔢 Versioning

Major.Minor.Build.Revision
  • Major → grote release
  • Minor → uitbreiding
  • Build → bugfix / patch
  • Revision → hotfix

⚙️ Power Platform Richtlijnen

  • Gebruik managed solutions in hogere omgevingen
  • Scheiding DEV (unmanaged) vs OTAP strikt handhaven
  • Deploy uitsluitend via pipelines
  • Gebruik patches voor geïsoleerde fixes
  • Voorkom handmatige wijzigingen in productie

🚀 Deployment uitvoering

De daadwerkelijke deployment stappen (runbook) zijn apart beschreven:

👉 Zie: Power Platform Deployment Proces
Deze pagina beschrijft exact hoe releases, patches en hotfixes worden uitgerold.

🧪 Fabric

Voor Microsoft Fabric gelden dezelfde Change & Delivery principes, maar de implementatie is anders vanwege:

  • Git-integratie
  • Workspace-based development
  • CI/CD pipelines (Azure DevOps / GitHub)

To be continued

🚀 Best Practices

  • Werk met kleine, beheersbare changes
  • Gebruik vaste release cadance
  • Automatiseer zoveel mogelijk
  • Gebruik feature flags voor controle
  • Houd development en deployment gescheiden