Bouwblokken voor het implementeren van CI/CD met Snowflake

De voordelen van het bouwen van een Devops cultuur zijn duidelijk. DevOps praktiseert het integreren van teams die eerst in silo’s werkten binnen de software ontwikkel life cycle, van Dev naar Acceptatie naar Ops. Dit resulteert in zowel snellere innovatie als verbeterde product kwaliteit. De voordelen zijn dermate overtuigend dat bijna alle bedrijven die software bouwen bewegen naar een sterke DevOps cultuur en een volwassen tool chain creeren om dit mogelijk te maken.

Deze blog beschrijft hoe het Snowflake Cloud Data Platform applicatie ontwikkelaars in staat stelt om hun DevOps-processen te simplificeren. Deze eerste blog is onderdeel van een serie van drie blogs waar ik: DevOps, Technische implementatie van Continuous Integration / Continuous deployment (CI/CD) en Testen met Snowflake in detail zal bespreken.

• Deel 1: Bouwblokken voor het implementeren van CI/CD met Snowflake;
• Deel 2: Technische implementatie van CI/CD met Snowflake waarbij gebruik wordt gemaakt van Azure DevOps en Snowchange;
• Deel 3: Testen in een Data warehouse in een op Snowflake gebaseerd landschap.

In deze eerste blog, bespreek ik zes onderwerpen die gerelateerd zijn aan de essentiële bouwblokken voor het implementeren van CI/CD:

• DevOps en haar voordelen;
• Uitdagingen met Database DevOps;
• Database Change management benaderingen;
• Hoe Snowflake de adaptive van CI/CD simplificeert;
• Verschillende Database Change management tools beschikbaar voor Snowflake;
• CI/CD pipeline en tooling.

DevOps en haar voordelen 

DevOps is een cross-functionele systeemontwikkelingscultuur die tot doel heeft systeemontwikkeling (Dev) en de operatie van dat systeem (Ops) te verenigen.

DevOps is een van de belangrijkste pilaren die agile software delivery mogelijk maken met de volgende bedrijfsmatige resultaten:

• Sneller opleveren van software
• Meer efficiency
• Herhaalbaar en meetbare processen
• Efficient opleveren van software
• Hogere return on investment en winstgevendheid

Hoewel DevOps al lang een no-brainer is voor reguliere software ontwikkeling, blijft de wereld van databases wat achter. Graag geef ik een doorkijk waarom dat is. 

Uitdagingen bij Database DevOps 

Database DevOps (in het bijzonder voor data warehouses) is gecompliceerd en heeft een aantal unieke uitdagingen: 

• State: Databases bevatten kostbare business data en veranderingen aan de structuur van het object zouden moeten worden gemaakt zonder data te verliezen. Dit leidt tot handmatige aanpassingen van de change scripts voor elke release, hetgeen foutgevoelig is;
• Down Time: Database servers kunnen niet zomaar worden omgewisseld;
• Rolling back: Databases moeten van te voren expliciet gebackupped worden en gerestored indien nodig.  Bij grote databases kost dit tijd en dat zorgt ervoor dat niemand kan werken tijdens dit proces;
• Testen: Het uitvoeren van unit testen is uitdagend in databases. Unit testen vereist het genereren van test data, hetgeen gecompliceerd en kostbaar is;
• Controle: Meestal zijn DBA’s de enige personen die veranderingen mogen doorvoeren op databases, zij valideren en onderzoeken de change scripts die door ontwikkelaars zijn aangeleverd voordat ze handmatig worden geïmplementeerd.
• Overige uitdagingen: Vaak matcht de versie die in productie staat niet met de versie die ontwikkelaars gebruiken om hun change scripts of source control op maken;

Database Change Management benaderingen

Database DevOps vereist dat alle database objecten in de vorm van scripts opgeslagen worden in source control en het automatiseren van hun uitrol. Er zijn twee benaderingen voor database schema change management, te weten: declaratieve/status gebaseerd en imperatief/migratie gebaseerd. Hier volgt een korte uitleg van deze twee methodes:

In de onderstaande illustratie is dit nogmaals weergeven:

Snowflake simplificeert

Het Snowflake Cloud Data Platform is ontworpen om organisaties in staat te stellen om data-intensieve applicaties zonder limitaties op performance , gelijktijdigheid of schaal te bouwen. Vanwege zijn multicluster, shared data architectuur, schaalt het horizontaal en verticaal naar gebruik, waardoor het snelle response tijden levert, ongeacht de load. Hier volgen enkele manieren waarop Snowflake de aanpassing naar DevOps-processen versimpelt:

• Creëert meteen ongelimiteerde geïsoleerde omgevingen – Snowflake zorgt voor de creatie van zo veel geisoleerde, ACID-compliant, SQL-gebaseerde rekenomgevingen (compute) als benodigd. Er is geen noodzaak om een apart cloud middel te kopen en te beheren. Rekenomgevingen in Snowflake zijn volledig onafhankelijk en worden begroot gebaseerd op de benodigde workload, in de kern van Snowflake’s unieke architectuur, is de mogelijkheid om een aantal geisoleerde workloads te draaien die allemaal dezelfde data benaderen. 
• Het opzetten van pre-productieomgevingen  – Het opzetten van pre-productieomgevingen met productie data is uit ervaring een van de grootste DevOps uitdagingen. Met Snowflake is opzetten van een pre-productieomgeving een kwestie van  enkele seconden! Snowflake biedt hiervoor twee mechanismes, Snowflake Secure Data Sharing wordt gebruikt wanneer de omgevingen op separate Snowflake accounts draaien, en Zero-Copy Cloning wordt gebruikt wanneer omgevingen op hetzelfde account zitten. Zero-Copy Cloning creeert onmiddelijk een virtuele kopie van live data in metadata, zonder de data te dupliceren of te verplaatsen. Het voordeel hiervan is dat dit tijd en geld bespaart.
• Direct schalen van omgevingen – Pre-productieomgevingen, hebben vanuit de historie vaak een  kleinere schaal vanwege de kosten die gepaard gingen met het omzetten van de data. Het gevolg was dat ontwikkelaars leden onder de trage ontwikkel-cycli. Maar met Snowflake betalen organisaties alleen voor de tijd dat een job runt en zorgt Snowflake voor de juiste schaling op het juiste moment.
• Gemakkelijke rollback met time travel – Foutafhandeling binnen een geautomatiseerde release van een database en de gerelateerde applicatie-code is een significante uitdaging. Met traditionele systemen, moeten ontwikkelaars backups maken voor de uitrol van nieuwe changes en dan restoren wanneer er iets mis gaat. Maar zowel backup-, als restoreprocessen zijn kostbaar en tijdrovend. Snowflake Time Travel simplificeert de handelingen om fouten en gepaarde rollbacks in een CI/CD  proces. Met Time Travel, kunnen objecten zoals: tabellen, schema’s en databases die zijn aangepast of verwijderd, makkelijk worden teruggezet tot een specifiek punt in de tijd binnen de voorgaande 90 dagen zonder hiervoor kostbare backups te draaien.

Verschillende Database Change Management tools beschikbaar voor Snowflake

Hoewel er uiteraard tooling beschikbaar is voor database changemanagement, zijn er weinig goede en werkbare tools beschikbaar voor de imperatieve benadering vergeleken met de declaratieve benadering.

De bovenstaande tabel geeft een doorkijk in het spectrum van tools. In mijn beoordeling van bovenstaande tools op volwassenheid en gebruiksgemak, vind ik Snowchange een zeer bruikbare tool omdat het flexibel en hierdoor altijd is aan te passen op de specifieke wensen van de organisatie. 

Snowchange 

Snowchange(externe link) is een python-gebaseerde open-source tool en is beschikbaar onder een Apache License (version 2.0). Het beheert alle objecten van Snowflake. Wanneer Snowchange gecombineerd wordt met version control en een CI/CD tool, dan zijn we in staat database veranderingen te akkorderen en uit te rollen via een pipleine. Uiteraard blijft het van belang dat we  hierbij gebruik maken van moderne software delivery practices. Als zodanig speelt Snowchange een kritische rol in het in staat stellen van Database (of Data) DevOps.

CI/CD pipeline en tooling 

CI/CD is de backbone om DevOps mogelijk te maken. Het overbrugt het gat tussen ontwikkeling en de operatie door de automatisering van de realisatie, het packagen en het testen binnen de software ontwikkeling. Hieronder is een voorbeeld van een model dat de verschillende CI/CD pipeline-stadia laat zien.

Dit voorbeeld van een CI/CD pipeline bestaat uit het CI deel (de bouw pipeline) en het CD deel (de uitrol pipeline), welke de volgende stappen bevatten:

CI Pipeline

• Source Stage – In de meeste gevallen wordt een pipeline run getriggerd door de broncode repository. Een verandering in die code triggert een notificatie naar de CI/CD-ochestratie-tool, welke de corresponderende pipeline activeert en uitvoerd. 
• Build Stage – Een bron code wordt gebouwd op een uitrolbare instantie, package of het wordt containerized.
• Team Test Stage – In deze fase worden geautomatiseerde code reviews, geautomatisserde unit tests en integratie tests uitgevoerd. 

CD Pipeline

• Deploy for Business Test Stage – Indien een appicatie is geslaagd voor alle code validatie en voorgedefinieerde unit en integratie tests, wordt de software uitgerold naar een staging test op een specifieke omgeving (staging-test server).
• Business Test Stage – In dit stadium worden Gebruikers acceptatie Tests, Performance Tests, Regressie Tests en Productie tests uitgevoerd. 
• Deploy for Production Stage – Zodra de applicatie is gevalideerd en goedgekeurd, wordt de software uitgerold naar de Productie omgeving 
• Production and monitoring – Na de uitrol in de productie omgeving, wordt het gedrag van de oplossing continu gemonitort.

In iedere fase van de CI/CD pipeline zijn de continue monitoring en feedback van de monitoring geintegreerd. Ieder probleem dat men tegenkomt in een van de fasen, wordt automatisch gerapporteert (met, bijvoorbeeld ALM Octane of Jira) en de CI/CD workflow wordt gestopt om zo de correctie uit te voeren en snel door te kunnen in het proces. Het CI/CD pipeline-ontwerp is gebaseerd op de best practises die door Sogeti zijn opgenomen. Voor een dieper begrip van het implementeren van Kwaliteit voor DevOps, verwijs ik naar ons boek ‘Quality for DevOps Teams(externe link)‘.

Voor de implementatie van CI/CD  is Azure DevOps een perfecte plaats om als Code Repository te dienen, om de CI/CD pipelines te bouwen, voor test management en tevens het inzicht te geven in het proces van uitrol via een dashboard. Door deze samenhang van functionalteit kies ik graag voor Azure DevOps. De componenten van Azure DevOps die ik in mij werk gebruik licht ik hieronder toe:

Azure Repos is een set van version control tools die ik gebruik om code te beheren. Het is hierin essentieel om een ‘release branching strategie’ te kiezen en te maken. Ik gebruik releaseflow, het is een trunk-based branching and merging strategie die Microsoft ook voor de Visual Studio producten gebruikt en inmiddels ook  een industrie standaard is.

Azure Pipeline is een cloud dienst die continuous integration (CI) and continuous delivery (CD) combineerd en consistente test and bouw code aflevert aan een doel. Ik voer hierin bijvoorbeeld de release pipeline uit via een op YAML gebaseerde pipeline.

Azure Test suite bevat tools voor zowel verkennende en handmatige tests maar juist ook continue geautomatiseerde tests zijn hierin zeer goed te doen.

Azure DevOps dashboards zijn aanpasbare interactieve dashboards die real-time informatie leveren. Ik gebruik deze dashboards om de status van bouw, uitrol en vrijgave weer te geven aan mijn stakeholders.

De volgende stap

In mijn volgende blog ga ik dieper in op de technische implementatie van CI/CD met Snowflake waarbij ik gebruik maak van Azure DevOps en Snowchange. Ik zal je hierbij door iedere configuratiestap begeleiden om Snowchange en Azure DevOps in te zetten in jouw situatie. Ondertussen benieuwd naar meer informatie? Neem gerust contact met mij op of bekijk onze Data & Business Analytics services.

Naar Data & Business Analytics