📋 Developer Guidelines

Algemene ontwikkelprincipes, structuur en hergebruik.

← Terug naar Develop

📖 Introductie

Deze pagina beschrijft de praktische werkwijze voor het ontwikkelen van solutions binnen het Dataverse / Dynamics 365 platform. De focus ligt op consistente, onderhoudbare en herbruikbare oplossingen binnen een volwassen ALM-aanpak.

👉 Deze richtlijnen ondersteunen:
  • consistente ontwikkeling
  • herbruikbare oplossingen
  • voorspelbaar gedrag bij deployment
  • duidelijke structuur binnen solutions
⚠️ Deze pagina richt zich op de praktische uitvoering van development en moet altijd gebruikt worden in combinatie met:
  • Solution lifecycle & versioning
  • Architecture & Solution Design
  • Cloud flow guidelines
  • JavaScript guidelines
  • Entity guidelines

1. Nieuwe solution aanmaken

Elke ontwikkeling begint met het correct opzetten van een solution. Dit bepaalt de structuur, herbruikbaarheid en deploymentstrategie van de oplossing.

👉 Kies bewust een structuur: focusgebied of componenttype.

1.1 Solution per focusgebied

  • Ga naar make.powerapps.com
  • Selecteer de juiste omgeving (DEV)
  • Navigeer naar Solutions
  • Klik op New Solution

Configuratie

  • Display name → logische naam
  • Name → technische naam (prefix + lowercase)
  • Publisher → juiste publisher
  • Version → bijv. 1.0.0.0

Naamgeving

  • Logisch en beschrijvend
  • Geen afkortingen
  • Geen environment namen

Voorbeelden

  • BRENKE | Marketing
  • BRENKE | Salesbuildr Integration

1.2 Solution per componenttype

Voorbeelden

  • BRENKE | 01 Configuration
  • BRENKE | 02 Programming UI
  • BRENKE | 03 Core
  • BRENKE | 04 Programming Logic
  • BRENKE | 05 Automation
👉 Deze structuur ondersteunt deployment volgorde en solution layering.

2. Componenten toevoegen

Componenten worden altijd binnen een solution opgebouwd. Hierdoor blijven wijzigingen beheersbaar en herleidbaar.

2.1 Entiteit (tabel)

  • Navigeer naar de solution
  • Klik op New → Table
  • Kies Standard table

Configuratie

  • Name
  • Primary column
  • Ownership
👉 Voor inhoudelijke richtlijnen: zie Entity Guidelines.

2.2 Velden, formulieren en views

Velden

  • Ga naar Columns
  • Klik op New column
  • Configureer naam, datatype en required level

Formulieren

  • Voeg velden toe
  • Structureer met tabs en sections

Views

  • Voeg kolommen toe
  • Stel filters in

2.3 Model-Driven App

  • New → App → Model-driven app
  • Configureer naam en sitemap

Voeg toe

  • Entiteiten
  • Views
  • Dashboards
👉 Een duidelijke sitemap bepaalt de gebruikerservaring en navigatie.

2.4 Environment Variables

  • New → More → Environment variable

Configuratie

  • Display name
  • Name (prefix)
  • Data type
⚠️ Gebruik geen hardcoded waarden — gebruik altijd Environment Variables.

3. JavaScript

3.1 Webresource maken

  • New → Web resource
  • Type: JavaScript

Naamgeving

  • <publisher>_scripts/<entity>.js
  • <publisher>_scripts/<entity>/<entity>.js

Voorbeelden

  • brenke_scripts/account.js
  • brenke_scripts/account/account.js

3.2 Koppelen aan formulier

  • Open formulier
  • Form Properties
  • Voeg webresource toe

Events

  • onLoad
  • onSave
👉 onChange events worden in JavaScript zelf geregistreerd.

4. Afbeeldingen

Webresource

  • Type: Image

Structuur

  • <publisher>_images/<entity>/<image>
  • <publisher>_images/<image>

5. Cloud flows

Aanmaken

  • New → Cloud flow

Connection references

👉 Gebruik altijd connection references — nooit directe connections.

Testen

  • Test in DEV
  • Controleer logging
  • Valideer errors

6. Development best practices

✅ Aanbevolen
  • Werk altijd binnen een solution
  • Gebruik consistente naamgeving
  • Werk modulair
  • Gebruik herbruikbare componenten
  • Gebruik connection references
  • Documenteer wijzigingen
❌ Vermijden
  • Werken in Default Solution
  • Hardcoded waarden
  • Directe connections
  • Monolithische solutions
  • Ongecontroleerde wijzigingen

7. Hotfix & Patch werkwijze

Binnen Dataverse wordt onderscheid gemaakt tussen standaard releases, patches en hotfixes. Deze sectie beschrijft de praktische werkwijze voor het gecontroleerd doorvoeren van wijzigingen.

👉 Kies bewust het juiste type wijziging om risico’s te beperken en de solution lifecycle beheersbaar te houden.

7.1 Wanneer gebruik je wat?

  • Standaard release → nieuwe functionaliteit of grotere wijziging
  • Patch → geplande, gecontroleerde correctie binnen solution lifecycle
  • Hotfix → urgente correctie met afwijkend (versneld) releaseproces
⚠️ Gebruik geen hotfixes voor functionele uitbreidingen — alleen voor kritieke fixes.

7.2 Werkwijze: Patch maken (gecontroleerde release)

Een patch wordt gebruikt voor gecontroleerde, kleine wijzigingen binnen een bestaande solution. Dit is de standaard werkwijze voor bugfixes die niet urgent zijn.

  1. Ga naar de bestaande solution in DEV
  2. Kies Create Patch
  3. Geef een duidelijke naam en verhoog de versie (bijv. 1.0.1.0)
  4. Voeg alleen de relevante componenten toe
  5. Voer de wijziging door binnen de patch
  6. Publiceer alle aanpassingen
  7. Test volledig in DEV
  8. Commit en push wijzigingen (indien Git gekoppeld)
  9. Deploy de patch via de pipeline naar TEST / ACC / PROD
👉 Gebruik patches voor beheerste, traceerbare wijzigingen binnen de normale release flow.

Belangrijk

  • Patch is afhankelijk van de base solution
  • Patch bevat alleen delta-wijzigingen
  • Meerdere patches stapelen op elkaar

7.3 Werkwijze: Hotfix (urgente productie fix)

Een hotfix wordt gebruikt voor kritieke productieproblemen die direct opgelost moeten worden. De nadruk ligt op snelheid en minimale impact.

  1. Analyseer het probleem en bepaal de minimale wijziging
  2. Maak een hotfix branch (indien Git gebruikt wordt)
  3. Open de bestaande solution in DEV (of een dedicated hotfix omgeving)
  4. Voer alleen de noodzakelijke wijziging door
  5. Publiceer de wijziging direct
  6. Test gericht op het specifieke probleem
  7. Valideer met business / key users
  8. Deploy zo snel mogelijk naar productie (versneld proces)
  9. Merge de wijziging terug naar develop/main branch
  10. Neem de fix op in de eerstvolgende reguliere release
❗ Hotfixes zijn noodmaatregelen en mogen alleen gebruikt worden voor kritieke issues.

Belangrijk

  • Houd de scope extreem klein
  • Vermijd extra wijzigingen of refactoring
  • Zorg dat de fix niet verloren gaat (altijd terug mergen)

Speciaal scenario: DEV loopt voor op productie

Wanneer de development omgeving al nieuwe wijzigingen bevat voor een volgende release, kan een hotfix niet rechtstreeks vanuit de solution worden gedeployed.

❗ Exporteer nooit direct de volledige solution — dit leidt tot ongewenste deployments.
  • Gebruik bij voorkeur een patch om alleen de fix te isoleren
  • Alternatief: maak een tijdelijke oplossing met alleen de noodzakelijke wijziging
  • Zorg dat de fix ook wordt opgenomen in de reguliere release
👉 Het doel is om alleen de fix te deployen, zonder andere wijzigingen mee te nemen.

7.4 Versioning richtlijnen

  • Major → grote releases
  • Minor → geplande uitbreidingen
  • Patch → kleine correcties
1.0.0.0 → initiële release
1.1.0.0 → nieuwe functionaliteit
1.1.1.0 → patch / bugfix
1.1.1.1 → correctie op een patch / bugfix
👉 Gebruik consistente versioning om deployments en traceability te vereenvoudigen.

7.5 Samenvoegen van patches (Upgrade)

  • Na meerdere patches → voer upgrade uit
  • Combineer patches in nieuwe solution versie
  • Publiceer volledige solution (bijv. 1.2.0.0)
👉 Dit voorkomt een lange keten van afhankelijkheden.

7.6 Veelgemaakte fouten

  • Te grote patches maken
  • Geen duidelijke versioning gebruiken
  • Patches stapelen zonder upgrade
  • Wijzigingen direct in productie doen
  • Hotfix gebruiken voor nieuwe features
❌ Ongecontroleerde patches en hotfixes leiden tot complexe deployments en fouten in productie.

📊 Samenvatting

Een consistente ontwikkelaanpak zorgt voor betere onderhoudbaarheid, stabielere deployments en hogere kwaliteit van implementaties.

✔ betere structuur
✔ voorspelbare deployments
✔ hogere kwaliteit
✔ minder technische schuld