Het Interdobs Webflix SQL Data Warehouse, Agile ontwikkelen met Git – deel 3
Zoals u heeft kunnen lezen in mijn vorige blogs (hier kunt u deel 1 en deel 2 vinden) is het HANA SQL Data Warehouse een bijzondere oplossing. Niet alleen krijgt u met de SQL Data Warehouse foundation de mogelijkheid om een native SQL data warehouse te bouwen, ook heeft het de mogelijkheid om agile ontwikkelingen door te voeren. Het SQL DWH kent containers waarin ontwikkelaars het SQL DWH ontwikkelen in hun eigen afgeschermde gebied. De code welke het SQL DWH genereerd moet vervolgens ergen opgeslagen worden op een manier welke het agile ontwikkelen omarmt. GIT is een zogeheten repository waarin code gedeeld kan worden tussen containers en dus verschillende ontwikkelaars.
Wat is Git?
Volgens Wikipedia:
Git is een vrij gedistribueerd versiebeheersysteem. Het wordt ook wel een softwarebroncode-managementproject genoemd. De nadruk ligt op snelheid.
Iedere Git-werkmap bevat de volledige repository met een compleet historisch overzicht en volledige trackingcapaciteiten. Git is niet afhankelijk van een gemeenschappelijke locatie of een centrale server zoals het Concurrent Versions System (CVS) of Subversion (SVN).
Ideaal dus voor agile ontwikkelen!
Klassiek ontwikkelen versus Agile
In een klassiek data warehouse worden alle ontwikkelen op dezelfde objecten uitgevoerd. Denk aan een BW systeem waar de data flows worden aangepast. Er zal niet vaak gekozen worden om voor elke aanpassing een totaal nieuwe flow te maken. De bestaande objecten zullen aangepast worden en door het landschap getransporteerd worden. Een tweede ontwikkelaar zal dus rekening moeten houden met de wijzigingen van zijn voorganger. Er wordt simpelweg op hetzelde “runtime” object ontwikkeld. Er is geen verschil tussen een “runtime object” of “designtime object”.
Met de agile aanpak in combinatie met GIT wordt er op een andere manier ontwikkeld. Elke ontwikkelaar werkt binnen een project in zijn eigen container. Technisch gezien werkt hij dan ook in zijn eigen database schema. In dat schema worden alle database-artefacten van een project speciaal geactiveerd voor deze ontwikkelaar en opgeslagen.
De opslag wordt, u raadt het al, in een GIT repository gedaan. Ook dit is volledig geautomatiseerd. Er is dus hier wel verschil tussen “designtime” en “runtime”. Alleen na het build proces wordt de data van een design time naar een runtime verplaatst. De GIT repository wordt dus gebruikt voor de designtime, terwijl de container de runtime objecten laat zien.
Hoewel elke ontwikkelaar een individuele container heeft, worden alle designtime objecten dus gedeeld via de Git-repository, en het is aan de ontwikkelaar om te beslissen wanneer moet worden gesynchroniseerd en wanneer een nieuwe lokale build van alle wijzigingen moet worden gemaakt. Er moet natuurlijk nogsteeds nagedacht worden wanneer welke wijzigingen gesynchroniseerd worden!
Branching
Een belangrijk kenmerk van Git is “branching”. In een gegeven repository kunt u vertakken (branching) om te werken aan een afzonderlijke versie van de repository. Op deze manier kunt u de ontwikkeling van designtime objecten isoleren. U kunt bijvoorbeeld een nieuwe flowgraph maken, terwijl uw collega een betstaande flowgraph aanpast binnen hetzelfde project. Wanneer de ontwkkelingen zijn voltooid, voegt u de wijzigingen samen in een “main branch”.
Een voorbeeld in het Webflix SQL DWH
Ik kan mij voorstellen dat u door de branches het bos niet meer ziet. In onderstaande video zal ik u meenemen in het principe van wijzigingen doorvoeren via Git.
Bedankt voor het lezen en luisteren!
