kevin-chant-sogeti-data-azure

Een modern dataplatform met Azure Synapse Analytics en Azure DevOps

Dit artikel laat je zien hoe je Azure DevOps kunt gebruiken in combinatie met Azure Synapse Analytics om de implementatieketen te versterken, en dat te herhalen dankzij gestandaardiseerde bouwstenen en automatisering. Lees hier verder.

Dit artikel is deel twee van een blog die samen een rondreis vormen op een modern dataplatform met Azure Synapse Analytics en Azure DevOps. Lees voor een inleiding tot Azure Synapse Analytics het eerste deel van de blog.

Inleiding tot Azure DevOps

Azure DevOps is een platform van Microsoft waarop je verschillende stappen van je ontwikkelingswerkzaamheden kunt beheren. Denk aan het beheren van je werkitems, het opslaan van je code en het implementeren van je releases. Daarnaast kun je er ook je tests op verschillende niveaus mee beheren. Met Azure Test Plans kun je namelijk verschillende tests binnen één pipeline automatiseren, en handmatige tests beheren. Hieronder beschrijf ik een van de manieren waarop je de standaarddiensten van Azure DevOps samen kunt gebruiken.

azure-synapse-analytics-sogeti

 
Een voorbeeld waarbij de diensten van Azure DevOps samenwerken.

Azure DevOps is beschikbaar voor gebruik in de cloud (Azure DevOps clouddiensten) of lokaal (Azure DevOps Server). In dit blog behandel ik de cloudvariant. Alle ideeën kunnen echter ook worden aangepast voor gebruik met Azure DevOps Server.
Speciaal voor dit blog heb ik ook nog een whitepaper geschreven, met daarin een uitgebreidere introductie. Zo kan ik me in dit blog richten op het gebruik van Azure DevOps met Azure Synapse Analytics. De titel van het whitepaper is ‘Een korte inleiding tot Azure DevOps’.

Objecten van Synapse Studio in Azure DevOps

In Synapse Studio kun je een Git-configuratie opzetten om verschillende objecten van Synapse Studio in één centrale Git-opslagplaats op te slaan. Daarbij kun je denken aan gekoppelde diensten, notebooks en SQL-scripts. Het onderstaande screenshot geeft je een idee van waar en hoe je dit kunt configureren in de hub ‘Manage’ van Synapse Studio.

azure-synapse-analytics-sogeti

Git-configuratie in Synapse Studio

Zoals je kunt zien, heb ik de naam van de hoofdmap in ‘resources’ veranderd. Dit heb ik gedaan, zodat de objecten in een submap in de Git-opslagplaats worden opgeslagen. Hieronder zie je hoe de opslagplaats in Azure Repos eruitziet.

azure-synapse-analytics-sogeti

Opgeslagen objecten in Azure Repos

Je ziet verder dat ik ook een collaboration branch heb opgezet. Dit is de standaardbranch waarin mensen in Synapse Studio gaan werken. Je kunt daarvoor je standaardbranch (doorgaans de main branch) gebruiken. Maar door een andere branch te gebruiken, is het makkelijker om continue integratie en levering (CI/CD) van individuele objecten te implementeren. Zowel jij als je collega’s kunnen andere branches in Synapse Studio aanmaken.

azure-synapse-analytics-sogeti

Een nieuwe branch in Git aanmaken

Wanneer je een nieuwe branch aanmaakt, dan kopieer je de inhoud van een bestaande branch zodat je die onafhankelijk kunt bewerken. Daarna voeg je indien gewenst je veranderingen samen met de collaboration branch. Dat doe je door een zogeheten ‘pull request’ aan te maken; net zoals ontwikkelaars dat doen bij versiebeheer. Let op dat wanneer je een pull request in Synapse Studio aanmaakt, dit een nieuw pull request in Azure DevOps opent.

azure-synapse-analytics-sogeti

Pull request in Azure DevOps
Nog een belangrijk punt dat ik wil benoemen, is dat de Git-configuratie in Synapse Studio bestaande objecten binnen SQL-pools of Spark-clusters niet automatisch opslaat.

Speciale branch

Je ziet hierboven dat de Git-opslagplaats een workspace_publish-branch bevat die je in Synapse Studio niet kunt selecteren. Dat komt omdat dit een speciale branch is, die gebruikt wordt om alle objecten die je naar Azure hebt gepubliceerd, op te slaan binnen Azure Synapse. Nadat je de Git-configuratie hebt ingesteld, klik je op ‘Commit’ om de wijzigingen op te slaan in de Git-opslagplaats in Azure DevOps. In plaats daarvan kun je echter ook kiezen voor ‘Publish’ om al je Synapse-objecten in Azure op te slaan.
Wanneer je objecten in Synapse Studio publiceert, worden ze toegevoegd aan een JSON-bestand in de workspace_publish-branch in je Git-opslagplaats. Dit bestand bevat de definitie van elk afzonderlijk object dat in Azure wordt opgeslagen.

azure-synapse-analytics-sogeti

Een voorbeeld van de workspace_publish-branch
Je kunt de inhoud van deze branch gebruiken om de volledige inhoud van de workspace die je naar Azure hebt gepubliceerd, naar een andere workspace te migreren. Als je bijvoorbeeld een ontwikkelwerkruimte hebt, dan kun je al je objecten publiceren. De JSON-bestanden in je Git-opslagplaats worden dan weer bijgewerkt. Daarna kun je ofwel een YAML-pipeline of de Releases-functie van Azure Pipelines gebruiken om de bijgewerkte inhoud in een productiewerkruimte te implementeren.
Hieronder zie je hoe dat er in de Releases-functie uitziet. Dit is de ouderwetse GUI-gebaseerde manier van werken met Releases. Wanneer je overstapt op moderne Infrastructure-as-Code-werkwijzen, dan zou ik eerder adviseren om dit binnen een YAML-pipeline te doen met de Pipelines-functie.

azure-synapse-analytics-sogeti

De Releases-functie gebruiken voor het uitvoeren van CI/CD in je workspace
Microsoft biedt een handleiding over het uitvoeren van CI/CD via deze methode met de titel ‘Continuous integration and delivery for an Azure Synapse Analytics workspace’. Maar voordat je hiermee aan de slag gaat, moet je, zoals vermeld onder het kopje ‘Vereisten’, de Synapse Workspace Deployment-extensie in Azure DevOps installeren.

Objecten van branches kopiëren

Een andere manier die je kan gebruiken, is het kopiëren van de afzonderlijke objecten vanuit je bestaande Git-opslagplaats naar een Git-opslagplaats van een andere workspace. Zo kan ik bijvoorbeeld het onderstaande SQL-script van deze Git-opslagplaats kopiëren naar een andere Git-opslagplaats die is opgezet om gebruikt te worden voor productie.

azure-synapse-analytics-sogeti

Afzonderlijk object in Git

Ik kan dit op verschillende manieren aanpakken. Ik kan het object handmatig kopiëren en dan plakken in de nieuwe opslagplaats. Maar een nog mooiere oplossing is om dit te automatiseren met Azure Pipelines. Enige tijd terug heb ik hier een blog over geschreven met de titel ‘De migratie van een pipeline naar een Synapse-workspace automatiseren met behulp van Azure DevOps’. Dit geeft je een idee van hoe je dit met een YAML-pipeline in Azure DevOps kan doen.

SQL-pools

Zoals ik al eerder in dit blog aangaf, worden objecten in SQL-pools niet in een in Synapse Studio opgezette Git-opslagplaats opgeslagen. In plaats daarvan moet je andere manieren gebruiken. Een belangrijk punt om te onthouden, is dat als je CI/CD bij SQL-pools wil uitvoeren, je via een SQL-eindpunt verbinden moet maken in plaats van via een servernaam. Je vindt deze eindpunten in het menu-item ‘Overview’ van je Synapse-workspace in de Azure Portal.

azure-synapse-analytics-sogeti

SQL-eindpunten in de Azure Portal

Je kunt CI/CD bij dedicated SQL-pools uitvoeren op basis van statusgestuurde of migratiegestuurde implementaties. Bij statusgestuurde migratie kopieer je over een bestaande status heen, terwijl je bij migratiegestuurde implementaties alle incrementele veranderingen afzonderlijk uitvoert.

Dedicated SQL-pools

Veel van de tools die je bij SQL Server gebruikt voor het uitvoeren van CI/CD, kun je ook bij dedicated SQL-pools gebruiken. Voor statusgestuurde implementaties kun je bijvoorbeeld de populaire DACPAC-methode gebruiken. Daarbij maak je een speciaal bestand, ook wel DACPAC genoemd, dat je gebruikt om een dedicated SQL-pool bij te werken. De meeste mensen creëren een DACPAC ofwel op basis van een bestaande database of op basis van een verzameling bestanden die het databaseschema vertegenwoordigen (wat bekendstaat als een databaseproject). Je kunt een databaseproject aanmaken op basis van een bestaande dedicated SQL-pool. Daarbij maak je gebruik van uiteenlopende applicaties als Visual Studio en Azure Data Studio. Over een van de manieren waarop je dit kunt doen, heb ik een blog geschreven met de titel ‘Een DACPAC maken voor een dedicated SQL-pool in Azure Synapse Analytics met behulp van Azure Data Studio’. Zoals je in dat blog kunt lezen, kun je een DACPAC direct op basis van een databaseproject binnen verschillende applicaties aanmaken. Als je echter CI/CD wilt uitvoeren, dan moet je ervoor zorgen dat er bij elke update van een databaseproject een DACPAC wordt aangemaakt. Om dit in Azure DevOps te doen, sla je het databaseproject op in Azure Repos. Daarna kun je een implementatiepipeline in Azure DevOps opzetten, zodat er bij iedere update van het databaseproject een DACPAC wordt aangemaakt. Hoe je dit doet, leg ik uit in mijn blog ‘Een DACPAC maken voor een dedicated SQL-pool in Azure Synapse Analytics met behulp van Azure DevOps’. Hierna komen migratiegestuurde implementaties aan de orde.

Serverloze SQL-pools

Op dit moment is het nog niet mogelijk om de DACPAC-methode te hanteren voor het uitvoeren van CI/CD bij serverloze SQL-pools. Dit heeft binnen de Microsoft Data Platform-community aardig wat discussie opgeleverd.Maar ik heb een manier gevonden om dat toch te kunnen doen, namelijk met een migratiegebaseerde methode. Lang verhaal kort: in Visual Studio kun je een C# project voor de DbUp .NET library aanmaken. Heb je dat gedaan, dan kun je de projectmap in een Git-opslagplaats veranderen en de inhoud synchroniseren met een Git-opslagplaats in Azure Repos. Van daaruit kun je CI/CD in een implementatiepipeline implementeren. Daarvoor gebruik je een PowerShell-module met de naam DBOps. Je leest er meer over in mijn blog met de titel ‘CI/CD voor serverloze SQL-pools met behulp van Azure DevOps’.

Verder met Azure DevOps

Dit was het tweede deel van de blog over een modern dataplatform met Azure DevOps en Azure Synapse Analytics. Meer weten? Neem gerust contact op, ik vertel je er graag meer over. Wil jij iedere dag leren en kunnen sparren met vakgenoten? Bekijk dan de vacatures.

Naar vacatures

Kan ik je helpen?

Sogeti Maaike Somers Recruiter
Phone number: +31625755508