Samenwerken aan Azure Data Factory met Git-integratie
Als je met meerdere collega’s wilt samenwerken aan een Data Factory in Azure, biedt Git-integratie uitkomst. Met Git-integratie voor Azure Data Factory zorg je voor versiebeheer door een collaboration branch en feature branches in te richten. En met een release pipeline zorg je voor een stukje continuous development and integration. Het enige dat je hiervoor nodig hebt is uiteraard een subscription op Azure om de Data Factory in te maken en Azure DevOps. In deze blog laat BI consultant Frank Schepel je zien hoe je dit doet.
Geschreven door
Frank Schepel
Wanneer biedt Git-integratie uitkomst?
Stel, je maakt een Data Factory aan op de portal.azure.com om eens te kijken of dit een cloud based ETL-tool voor jou is. Ik ga er even vanuit dat je een Data Factory hebt gemaakt met daarin 1 pipeline en verder geen Git-integratie hebt ingericht. Zodra je tevreden bent met de pipeline die je gemaakt hebt en je je wijzigingen wilt vastleggen, moet je gebruik maken van de Publish optie (Figuur 1). Hiermee worden de wijzigingen gedeployed naar je Data Factory en is je pipeline ook gelijk beschikbaar om aan te roepen of te triggeren.
Als je in je eentje aan deze Data Factory werkt en nooit langer dan een dag bezig bent, kan dit een prima oplossing zijn. Maar nadat je een tijdje aan het prutsen en bouwen bent, kom je er waarschijnlijk achter dat je toch wel wat mist. Want wat doe je als je een publish hebt gedaan van je Data Factory maar toch terug wilt naar de vorige versie? Hoe sla je tussentijds op? En hoe zorg je ervoor dat je samen met een collega aan die Data Factory kan werken? Als je onafhankelijk van elkaar een publish doet overschrijf je elkaars wijzigingen. Dat is niet echt heel handig. Daarvoor heeft Microsoft Git-integratie voor Azure Data Factory beschikbaar gesteld.
Inrichten van Git-integratie in Azure DevOps
In deze blog gaan we de Git-integratie vanuit Azure DevOps regelen. Als eerste heb je dan een Azure DevOps project nodig. Zodra je dit hebt aangemaakt, kun je vanuit je Data Factory de integratie regelen door op “Set up code repository” te klikken (Figuur 2).
Vervolgens moet je een aantal settings invullen (Figuur 3):
- Repository type: ‘Azure DevOps Git’.
- Azure DevOps Account: kies je eigen Azure DevOps Account.
- Project name: Kies het project op Azure Devops waar je de Data Factory in wilt integreren.
- Git repository name: Use existing en kies dan je aangemaakte project of maak een nieuwe aan.
- Collaboration branch: standaard is dit master, je kunt hier ook zelf een naam voor je collaboration branch kiezen. Dit is wel belangrijk omdat dit de branch is van waaruit je een publish kan doen.
- Root folder: /
- Import existing Data Factory resources to repository: vink deze optie aan (let op: hiervoor moet je al wel iets gebouwd hebben in je Data Factory).
- Branch to import resources into: kies de collaboration branch.
Als je dit hebt doorlopen heb je vanaf nu Git-integratie in de Data Factory. Dit geeft je nu al de mogelijkheid om tussentijds op te slaan voordat je een publish doet.
Aanmaken feature branches
Als je samen met anderen aan je Data Factory werkt, vereist dit ook wel een andere werkwijze. Het is aan te raden om met feature branches te gaan werken. Dat houdt in dat je voor een bepaalde aanpassing of functionaliteit een nieuwe branch aanmaakt (Figuur 4). Binnen die feature branch ontwikkel je je toepassingen en test je ze. Wanneer het naar tevredenheid werkt, kun je vervolgens een pull request doen om te zorgen dat de functionaliteit in de collaboration branch wordt opgenomen. Als je dan op Create pull request klikt kom je uit in Azure DevOps, waar je de pull request kunt afhandelen. Je hebt hier de mogelijkheid om te controleren welke files aangepast worden, je kunt teamleden aanwijzen om een review te doen en, als alles in orde is, de merge uit te voeren.
Release pipeline voor continuous integration and delivery
Dit werkt op zich al mooi, maar hoe ga je dan om met een omgeving waar je bijvoorbeeld een splitsing wilt hebben tussen een DEV-omgeving en een PRODUCTIE omgeving? Dan heb je dus twee Data Factories nodig. De vraag is dan: hoe krijg je je pipelines, dataflows etc. van je DEV Data Factory naar Productie? Ook hier kun je Azure DevOps inzetten om een realease pipeline te maken voor een stukje CI/CD. Microsoft heeft een mooie plaat die weergeeft hoe Azure Data Factory en Azure DevOps samenwerken voor ‘Continuous integration and delivery’ (Figuur 5). Dat gaan we in deze blog ook realiseren, alleen doen we dat met iets minder omgevingen. We beperken het tot een DEV en PROD Data Factory.
Als eerste hebben we een extra Data Factory nodig. Die noem ik hier even blog-factory-prod. Vervolgens ga je in Azure DevOps naar het project waar je Data Factory onder valt. Hier heb je aan de linker kant een optie Pipelines en vervolgens releases (Figuur 6). Klik op New Pipeline en kies vervolgens voor ‘start with an Empty Job’. In het veld stage name vul je bijvoorbeeld de naam van de omgeving in waar je naartoe wilt deployen.
Artifact toevoegen vanuit Azure Repository
Vervolgens klik je op add an artifact. Je selecteert dat je een artifact vanuit Azure Repository wilt toevoegen (Figuur 7). Nu vul je de volgende dingen in:
- Project: Je Azure DevOps project waar je Data Factory onder valt.
- Source: Je code repository.
- Default branch: De branch van waaruit een artifact opgehaald moet worden. Dit moet de adf_publish branch worden. Deze is standaard aanwezig als je een keer een publish hebt gedaan binnen je Data Factory.
- Default version: De versie die je wilt deployen, hier selecteren we Latest version.
- Source Alias: Dev, die vullen we in om aan te geven dat de Dev versie hier de bron is.
Deployment trigger instellen
Zodra je de artifact geconfigureerd hebt, kun je op het bliksemschicht-icoontje klikken om een deployment trigger in te stellen. Hiermee zorgen we ervoor dat elke keer dat er vanuit de collaboration branch een publish wordt gedaan, automatisch een deployment naar onze productie Data Factory wordt uitgevoerd. Dit doen we door de switch ‘Continuous deployment trigger’ op enabled te zetten (Figuur 8). Vervolgens voegen we een branch filter toe op de branch adf_publish om ervoor te zorgen dat er alleen een deployment gebeurt als we een publish doen vanuit de blog-factory-dev.
Taken toevoegen aan de stage
Dan moet er nog een taak toegevoegd worden aan de Prod stage. Stages zijn de hoofdonderdelen waaruit je release pipeline bestaat. In deze blog bestaat onze release maar uit een stap, namelijk een deployment doen van DEV naar PROD. Deze stap gaat de artifacts die we opgehaald hebben deployen naar de blog-factory-prod Data Factory. Klik daarvoor op de tekst ‘1 job, 0 task’ (Figuur 9).
Voeg vervolgens aan de agent job een taak toe door op het plusje te klikken. Zoek naar ARM Template deployment en klik op add (Figuur 10).
- In de Deployment taak, selecteer de subscription, resource group en als target Data Factory. Voer eventueel credentials in als dit nodig is.
- In de Actionlijst, selecteer Create or update resource group.
- Klik op de knop met de 3 puntjes (…) naast het Template veld. Zoek naar de Azure Resource Manager template die gegenereerd is in je publish branch van je Git repository en zoek naar de file ARMTemplateForFactory.json in de folder van de adf_publish branch.
- Klik vervolgens op de knop met de 3 puntjes (…) naast het Template parametersveld om de parameter file toe te voegen. Zoek naar de json file in de folder van de adf_publish branch.
- Klik op de knop met de 3 puntjes (…) naast het Override template parametersveld en vul als Factory name de waarde “blog-factory-prod” in (ervan uitgaande dat je de productie Data Factory zo genoemd hebt).
- Selecteer Incremental als de Deployment mode.
- Klik Rechtsboven op Save.
Je release pipeline is nu klaar. Als je op publish klikt in je blog-factory-dev en in Azure DevOps onder releases kijkt, zie je dat je release uitgevoerd wordt (Figuur 11). Het is ook handig om je pipeline een nette naam te geven. Bijvoorbeeld Dev to Prod o.i.d.
Extra instellingen bij meerdere omgevingen
Uiteraard zijn er nog veel meer dingen in te stellen. Zo kun je bijvoorbeeld op het bliksemschicht-icoontje klikken voor de Prod stage om pre-deployment condities in te stellen. Bijvoorbeeld of de deployment automatisch gaat of via een bepaald trigger. Of dat het alleen handmatig gedaan mag worden en of het dan door 1 of meerdere personen moet worden goedgekeurd. Ook kun je bijvoorbeeld kiezen wat er moet gebeuren als er meerdere deployments klaar staan.
Vooral in een situatie met meerdere omgevingen kan dit handig zijn. Denk bijvoorbeeld aan een situatie waarbij een deployment naar Test automatisch gaat, maar naar Acceptatie en Productie alleen als het aan bepaalde voorwaarden voldoet en goedgekeurd is.
De voordelen van Git-integratie voor Azure Data Factory
Je bent nu in staat om een Data Factory in te richten met Git-integratie en daarnaast je release management via Azure DevOps te regelen. Dit geeft je een bult voordelen. Zo heb je nu versiebeheer waardoor je terug kan naar een vorige versie van je Data Factory. Je hebt de mogelijkheid om tussentijds op te slaan, zodat je niet aan het einde van je werkdag verplicht bent een publish te doen. Je kunt nu samen met je collega’s aan dezelfde Data Factory werken en als klap op de vuurpijl je releases automatisch uitrollen naar je verschillende omgevingen.
