Ga naar hoofdinhoud

Het wijzigingsproces (DTAP)

Je datawarehouse staat nooit stil: er komen bronnen bij, tabellen veranderen, je bouwt nieuwe views. Yres zorgt dat je die wijzigingen veilig kunt doorvoeren — je test alles eerst in een aparte omgeving en brengt pas naar productie wat klopt. Deze pagina beschrijft dat proces vanuit jouw perspectief als klant: wat je zelf doet, en wat Yres automatisch voor je regelt.

Voor de schermen en knoppen, zie Projecten & Changes. Voor de techniek eronder (DACPAC, ADF-publish, Azure DevOps), zie CI/CD & DTAP.

Het idee: dev → test → prod​

Yres richt je omgeving in volgens het DTAP-model: gescheiden omgevingen die elk hun eigen rol hebben.

OmgevingWaarvoorWie werkt hier
Development (dev)Hier bouw en wijzig je. De eerste omgeving is altijd dev.Jij / je data-team
Test (test)Hier controleer je of een wijziging klopt vóór productie.Jij / acceptatie
Productie (prod)De stabiele omgeving waar je rapportages op draaien.Niemand bewerkt hier rechtstreeks

Het uitgangspunt: je bouwt alleen in dev en je bewerkt nooit rechtstreeks in productie. Een wijziging reist als één pakket gecontroleerd van dev → test → prod, zodat je omgevingen gelijk blijven lopen en er nooit half werk in productie belandt.

Eén omgeving? Dan is er geen transport

Heb je maar één omgeving, dan is dit hele proces niet zichtbaar: er valt niets te promoten. Je wijzigingen worden direct toegepast en de sectie Projects verschijnt niet. De rest van deze pagina gaat over organisaties met meerdere omgevingen. Zie de licentietiers voor wie hoeveel omgevingen heeft.

De twee eenheden: Project en Change​

Al je werk bundel je in twee eenheden, zodat het als geheel reist en traceerbaar blijft:

  • Een Project is een container met een naam, omschrijving en einddatum — bijvoorbeeld "AFAS-uitbreiding Q3".
  • Een Change is de eenheid die je daadwerkelijk releaset en promoot. Elke bewerking die je in dev doet — een bron koppelen, tabellen toevoegen, een view persisteren, een scripted object toevoegen via Database objects — wordt automatisch onder een Change geboekt. Een Change hoort altijd bij een Project.

Je hoeft dus niet handmatig bij te houden wat er veranderd is: Yres verzamelt het in de Change, en die Change is straks je transporteenheid naar test en prod.

De reis van een wijziging — stap voor stap​

   DEV                         TEST                        PROD
 ┌───────────┐   release    ┌───────────┐   installeren  ┌───────────┐
 │  bouwen   │ ───────────▶ │ valideren │ ─────────────▶ │  live     │
 │  (Change) │   (vergrendeld)│         │                │           │
 └───────────┘              └───────────┘                └───────────┘
      1–3            4            5                6

Je doorloopt deze hele reis vanuit de changes-tabel: op het Changes-scherm (sectie Projects → sub-link Changes) staat per change een rij met onder meer een Status overview (per omgeving een voortgangsindicator — groen als die stap klaar is, grijs als die nog moet), een NextStep (de voorgestelde volgende actie, bijv. "Release on dev" of "Install on prd") en een Actions-menu (☰) helemaal rechts. Releasen, importeren en installeren doe je allemaal vanuit dat ☰-menu — de acties die je krijgt zijn afhankelijk van de status van de change. Je hoeft dus niet naar aparte release- of install-schermen.

  1. Plan je werk — maak een Project. Geef het een naam, omschrijving en einddatum. Onder dit project verzamel je je changes.
  2. Bouw in dev. Koppel bronnen, voeg tabellen toe, maak persisted views, en voeg scripted objects toe via Database objects (de objectboom onder Data Engineering). Alles wat je doet wordt onder je Change vastgelegd. Je laadt en test hier vrij — dit raakt test en prod niet.
  3. Bekijk en controleer de Change. Je ziet de inhoud als diagram (bron → schema → tabel) of als tabel (per object het load type, de delta-kolom, en wat er gebeurt als het object al bestaat). Zo weet je precies wat er straks meereist.
  4. Release de Change. Open het Actions-menu (☰) van de change en kies bij dev ▸ de actie release change. Hiermee vergrendel je de change: er kan niets meer aan worden bewerkt en hij wordt een verzegeld, promoteerbaar pakket. Yres controleert eerst de afhankelijkheden — bevat je change iets dat steunt op een andere, nog niet vrijgegeven change, dan blokkeert Yres de release en noemt die andere change(s). Zo neem je nooit per ongeluk half werk mee.
  5. Promoot naar test en valideer. Open opnieuw het Actions-menu (☰), kies het submenu van de doelomgeving — test ▸ — en klik Reinstall change. Yres brengt je wijziging naar test en je controleert daar of de loads en structuren kloppen.
  6. Promoot naar productie. Klopt het in test? Open dan het Actions-menu (☰), kies prd ▸ en klik weer Reinstall change. Daarmee staat je wijziging live — getest en wel.

Het geopende Actions-menu (☰) van een change op het Changes-scherm, met per-omgeving submenu's (dev ▸, prd ▸): op dev een open change met release change; op een doelomgeving een gereleasede change met Reimport change en Reinstall change, plus Update, Delete, View dependencies en Logs.

Je releaset en promoot een change vanuit het Actions-menu (☰) van die change: op dev kies je release change, op een doelomgeving (test, prd) kies je Reimport change of Reinstall change. De voortgang verschijnt als melding, omdat het publiceren van de pipelines op de achtergrond doorloopt.

Importeren vs. installeren​

In het submenu van de doelomgeving (bijv. test ▸ of prd ▸) van het Actions-menu (☰) biedt een gereleasede change twee acties:

  • Reimport change — haalt de change alleen in het datawarehouse van de doelomgeving binnen (roept [Change].[spImport] aan). De ADF-pipelines worden hierbij niet vernieuwd. Handig als je alleen de DWH-structuur wilt klaarzetten.
  • Reinstall change — doet het volledige werk: de change in het datawarehouse én het opnieuw publiceren van de ADF-pipelines (roept [Change].[spInstall] aan plus de publish-datafactory-pipeline), zodat ook je nieuwe bron-pijplijnen in de doelomgeving landen. Dit is de stap die DWH en ADF synchroon brengt.

In de meeste gevallen kies je Reinstall change. Via dezelfde acties in het ☰-menu kun je een change later opnieuw importeren of installeren.

Wat Yres automatisch voor je regelt​

Het mooie: bij stap 5 en 6 hoef je zelf niets technisch te doen. Achter één actie in het ☰-menu regelt Yres:

  • De databasestructuur uitrollen in de doelomgeving (nieuwe/aangepaste tabellen, views, procedures).
  • De ADF-pipelines opnieuw publiceren zodat je bronladingen in de doelomgeving werken.
  • Namen vertalen tussen omgevingen. Een bron die in dev ERP_DEV.Product heet, wordt in test ERP_TST.Product en in prod ERP.Product — Yres past de change automatisch aan op de juiste fysieke objecten per omgeving (de change deployment rules).
  • Versies bewaken (zie hieronder).

Onder de motorkap draaien hiervoor [Change].[spRelease], [Change].[spImport] en [Change].[spInstall], plus de Azure DevOps-pipeline publish-datafactory. De volledige techniek staat in CI/CD & DTAP.

De vangrails — waarom dit veilig is​

Yres bouwt een aantal controles in zodat je productie niet kunt breken:

  • Versies moeten overeenkomen. Vóór een install controleert Yres of de DWH-versies van bron- en doelomgeving gelijk zijn. Zo niet, dan krijg je "Environment versions do not match, please update" en wordt er niets geïnstalleerd — werk eerst de achterlopende omgeving bij via Update environments.
  • Afhankelijkheden worden gecontroleerd bij het releasen: je kunt geen change vrijgeven die steunt op werk dat nog niet is vrijgegeven.
  • Een gereleasede change is vergrendeld — niemand kan er na vrijgave nog stilletjes iets aan veranderen.
  • Een project kun je niet verwijderen zolang het nog open changes bevat, en de einddatum van een change moet op of vóór die van het project liggen.
  • Niets gaat ongetest naar prod, omdat je altijd eerst via test promoot.
  • Je historie blijft behouden. De load-engine versioneert je data (SCD2), dus een structuurwijziging gooit bestaande historie niet weg. Zie Historie & SCD2.

Gaat er onverhoopt toch iets mis, dan kun je een load of wijziging terugdraaien — zie Rollback & reset.

Een voorbeeld uit de praktijk​

Illustratief — een typische gang van zaken, geen specifieke klant.

Acme wil hun AFAS-administratie ontsluiten:

  1. Een data-engineer maakt het project "AFAS-koppeling" aan met een einddatum.
  2. In dev koppelt ze de AFAS-bron, ververst de metadata en voegt de gewenste tabellen toe — alles wordt geboekt onder de change "AFAS tabellen v1".
  3. Ze laat de eerste loads in dev draaien en controleert de data.
  4. Ze bekijkt de change-inhoud (klopt het load type per tabel?), opent het Actions-menu (☰) en kiest bij dev ▸ de actie release change.
  5. Ze opent het ☰-menu opnieuw, kiest test ▸ Reinstall change, draait de loads in test en laat een collega de rapportage valideren.
  6. Akkoord? Dan kiest ze in het ☰-menu prd ▸ Reinstall change voor dezelfde change. De AFAS-data staat live, en dev, test en prod lopen weer gelijk.

Voor een nieuwe bron van een bestaand type (zoals hierboven) is er meestal geen codewijziging nodig — het zijn metadata-rijen die de install-flow netjes tussen je omgevingen promoot.

Verder lezen​