Binnen je organisatie wordt Git gebruikt voor het versiebeheer van de BI-oplossingen. Hoewel het volgens verlichte geesten “de toekomst” lijkt te zijn, vraag je je toch sterk af of dat zo is. Of gebruiken jullie het wellicht op de verkeerde manier? Hoe werkt Git eigenlijk op de achtergrond?

Git: net even heel erg anders

Git is een versiebeheersysteem ontwikkeld door Linus Torvalds (de bedenker van de Linux-kernel). In de jaren ‘90 hadden de ontwikkelaars van de Linux-kernel een nieuw versiebeheersysteem nodig - en hij had ideeën hoe enkele fundamentele problemen met versiebeheer zouden kunnen worden aangepakt. Dat resulteerde in één van de meestgebruikte versiebeheersystemen van vandaag: Git.

Waarom ik je dit vertel: het helpt je om te onthouden hoe Git in elkaar zit:

• Git is decentraal. In de jaren ‘90 gebeurde de ontwikkeling van de Linux-kernel nog voornamelijk door vrijwilligers, die verspreid over de hele wereld. En niet iedereen had een breedband-internetverbinding. Altijd verbonden zijn met één centrale server is dan niet handig
• Git is gebouwd voor branching en merging. In een kernel gebeuren talloze ontwikkelingen tegelijkertijd, in het bijzonder wanneer je zoveel “losse” ontwikkelaars hebt die samenwerken aan één project. Dus heb je veel afwijkende lijnen van nieuwe ontwikkelingen (branches).

Hoewel Git zijn oorsprong kent in het ontwikkelen van besturingssystemen en aanvankelijk voornamelijk in de open source-wereld gebruikt werd, is het gebruik inmiddels veel breder geworden. Zelfs het versiebeheer van de Windows-kernel wordt tegenwoordig in Git gedaan!

Wat zijn de “best practices” in Git?

Git is een enorm flexibel systeem, dat je op veel verschillende manieren kunt inzetten. Dat betekent niet dat er geen best practices zijn. Microsoft heeft hun manier van werken samengevat in een werkwijze die ze Release Flow noemen. Het belangrijkste punt uit deze werkwijze is het gebruik maken van Trunk based development. In twee punten:

• master is de samenwerkings-branch. Deze moet van hoge kwaliteit blijven, dus bewaak je. Niemand voert hier ontwikkelingen of wijzigingen direct op door!
• Alle ontwikkelingen - zowel features als bugfixes - vinden plaats in topic branches. Deze takken direct af van de master branch en zijn kortlevend.

Releases worden ook afgetakt van de master branch. Dit is de trunk-based aanpak (https://trunkbaseddevelopment.com/).

Gaat dit ook werken voor mijn Data Warehouse, Data Platform of BI-oplossing?

Ja! Sterker nog, nieuwe data platform-oplossingen als Azure Data Factory zijn bijna om Git heen gebouwd. Dat wil niet zeggen dat je geen uitdagingen tegen gaat komen natuurlijk. Een belangrijk voorbeeld hier is SSIS: de packages hier worden opgeslagen in een XML-formaat dat het lastig maakt om twee afwijkende versies van één package weer samen te voegen.

Dat betekent niet dat je Git in zijn geheel niet kunt gebruiken, of van de best practice van feature branching moet afzien. Je kunt ook goed nadenken over de manier waarop je SSIS gebruikt. Kun je je werk wellicht opbreken in kleinere stukjes?

One more thing

Een belangrijke techniek in het werken met topic branches is de feature toggle. In de basis betekent dit dat je een stukje techniek wél integreert, maar nog niet zichtbaar laat zijn voor de gebruiker. Dit geeft je niet alleen extra mogelijkheden om je topic branches kortlevend te laten zijn, maar ook om te voorkomen dat je Data Platform als één grote monolithische oplossing een deployment nodig heeft!