När dataplattformar växer räcker det inte längre med att “ändra direkt i produktion”. Kraven på spårbarhet, kvalitet och samarbete ökar – och därmed behovet av versionshantering och strukturerade releaser. I Microsoft Fabric finns flera sätt att ta kontroll över förändringar, från inbyggd Git-integration till mer avancerade CI/CD-upplägg.
I det här inlägget går vi igenom alternativen och hur de kan kombineras i praktiken.
Varför versionshantering i Fabric?
Fabric samlar dataflöden, lakehouses, notebooks, semantiska modeller och rapporter i samma plattform. Det ger stora fördelar – men innebär också att:
- flera personer ofta arbetar parallellt
- ändringar påverkar många beroenden
- skillnaden mellan utveckling, test och produktion blir viktig
Versionshantering handlar därför inte bara om kod, utan om hela analyslösningen.
Git-integration i Fabric – grunden
Fabric har inbyggt stöd för Git, vilket gör det möjligt att koppla en workspace till ett repo i exempelvis GitHub eller Azure DevOps.
Det innebär att:
- artefakter i Fabric (notebooks, pipelines, lakehouses, semantiska modeller m.m.) lagras som filer i Git
- ändringar kan versioneras, granskas och återställas
- flera utvecklare kan arbeta parallellt med branches
För många organisationer räcker detta långt som ett första steg – särskilt om man tidigare saknat struktur för förändringar.
GitHub eller Azure DevOps?
Båda fungerar väl tillsammans med Fabric, men används ofta i lite olika sammanhang:
- GitHub
- vanligt i open source-miljöer och modern utveckling
- bra stöd för pull requests, kodgranskning och automation
- Azure DevOps
- ofta standard i Microsoft-centrerade organisationer
- stark koppling till pipelines, ärendehantering och releaseflöden
Valet handlar sällan om Fabric i sig, utan om vad organisationen redan använder.
CI/CD i Fabric – mer än bara versioner
Versionshantering svarar på vad som ändrats. CI/CD svarar på hur ändringar flyttas mellan miljöer.
Med CI/CD kan du till exempel:
- automatiskt validera förändringar
- deploya från utveckling till test och produktion
- säkerställa att samma version körs överallt
Fabric har idag inbyggt stöd för deployment pipelines (liknande dem i Power BI), men en del organisationer vill gå längre.
fabric-cicd – ett fristående paket
För mer avancerade scenarier finns community-drivna och fristående lösningar som ofta kallas fabric-cicd (eller liknande paket).
Dessa används vanligtvis för att:
- automatisera export/import av Fabric-artefakter
- köra deployment via GitHub Actions eller Azure Pipelines
- hantera parametrisering mellan miljöer (t.ex. lagringskonton, databaser, kapaciteter)
Det här tillvägagångssättet kräver mer initialt arbete, men ger:
- högre kontroll
- bättre repeterbarhet
- tydligare separation mellan miljöer
Ett pragmatiskt angreppssätt
Alla behöver inte börja med full CI/CD dag ett. Ett vanligt och fungerande stegvis upplägg är:
- Git-integration i Fabric – få versionshistorik och samarbete
- Manuella deployment pipelines – struktur mellan dev/test/prod
- Automatisering med CI/CD – när komplexiteten motiverar det
Det viktiga är inte att göra allt på en gång, utan att välja en nivå som organisationen faktiskt kan förvalta.
Sammanfattning
Versionshantering i Microsoft Fabric är inte ett “antingen eller”, utan ett spektrum av möjligheter:
- Inbyggd Git-integration för grundläggande kontroll
- GitHub eller Azure DevOps beroende på befintlig miljö
- CI/CD och fabric-cicd-lösningar för mer avancerade behov
Rätt upplägg ger tryggare förändringar, bättre samarbete och färre överraskningar i produktion.
Vill du diskutera vilket angreppssätt som passar just er Fabric-miljö? Hör av dig – en grupp från Drake Analytics hjälper gärna till att hitta en lösning som är hållbar även över tid.
