# 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](https://yres.eu/nl/wiki/frontend/projecten-changes). Voor de > techniek eronder (DACPAC, ADF-publish, Azure DevOps), zie [CI/CD & DTAP](https://yres.eu/nl/wiki/architectuur/cicd-dtap). ## Het idee: dev → test → prod Yres richt je omgeving in volgens het **DTAP-model**: gescheiden omgevingen die elk hun eigen rol hebben. | Omgeving | Waarvoor | Wie 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. :::note 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](https://yres.eu/nl/wiki/referentie/licentie-limieten) 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.  *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](https://yres.eu/nl/wiki/architectuur/cicd-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](https://yres.eu/nl/wiki/frontend/admin). - **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](https://yres.eu/nl/wiki/concepten/historie-scd2). Gaat er onverhoopt toch iets mis, dan kun je een load of wijziging terugdraaien — zie [Rollback & reset](https://yres.eu/nl/wiki/concepten/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 - [Projecten & Changes](https://yres.eu/nl/wiki/frontend/projecten-changes) — de schermen, knoppen en velden - [CI/CD & DTAP](https://yres.eu/nl/wiki/architectuur/cicd-dtap) — de techniek: DACPAC, `adf_publish`, Azure DevOps - [Rollback & reset](https://yres.eu/nl/wiki/concepten/rollback-reset) — een wijziging of load terugdraaien - [Gegevensstroom](https://yres.eu/nl/wiki/concepten/gegevensstroom) en [Historie & SCD2](https://yres.eu/nl/wiki/concepten/historie-scd2) — wat een load met je data doet