Share via

Kies de beste ci/CD-werkstroomoptie voor fabric voor u

  • Artikel

Het doel van dit artikel is om Fabric-ontwikkelaars te presenteren met verschillende opties voor het bouwen van CI/CD-processen in Fabric, op basis van algemene klantscenario's. Dit artikel richt zich meer op de continue implementatie (CD) van het CI/CD-proces. Zie Git-vertakkingen beheren voor een discussie over het onderdeel continue integratie (CI).

Hoewel in dit artikel verschillende verschillende opties worden beschreven, hebben veel organisaties een hybride benadering.

Vereisten

Voor toegang tot de functie implementatiepijplijnen moet u aan de volgende voorwaarden voldoen:

Ontwikkelingsproces

Het ontwikkelingsproces is hetzelfde in alle implementatiescenario's en is onafhankelijk van het vrijgeven van nieuwe updates in productie. Wanneer ontwikkelaars met broncodebeheer werken, moeten ze in een geïsoleerde omgeving werken. In Fabric kan die omgeving een IDE zijn op uw lokale computer (zoals Power BI Desktop of VS Code) of een andere werkruimte in Fabric. U vindt informatie over de verschillende overwegingen voor het ontwikkelingsproces in Git-vertakkingen beheren

Diagram waarin wordt getoond hoe het ontwikkelingsproces werkt.

Vrijgaveproces

Het releaseproces wordt gestart zodra de nieuwe updates zijn voltooid en de pull-aanvraag (PR) is samengevoegd in de gedeelde vertakking van het team (zoals Main, Dev , enzovoort). Vanaf dit punt zijn er verschillende opties voor het bouwen van een releaseproces in Fabric.

Optie 1: implementaties op basis van Git

Diagram waarin wordt getoond hoe de implementatie op basis van Git werkt.

Met deze optie zijn alle implementaties afkomstig uit de Git-opslagplaats. Elke fase in de release-pijplijn heeft een toegewezen primaire vertakking (in het diagram zijn deze fasen Dev, Test en Prod), die de juiste werkruimte in Fabric voedt.

Zodra een pull-aanvraag voor de Dev-vertakking is goedgekeurd en samengevoegd:

  1. Er wordt een release-pijplijn geactiveerd om de inhoud van de Dev-werkruimte bij te werken. Dit proces kan ook een build-pijplijn bevatten om eenheidstests uit te voeren, maar het daadwerkelijke uploaden van bestanden wordt rechtstreeks vanuit de opslagplaats naar de werkruimte uitgevoerd, met behulp van Git-API's van Fabric. Mogelijk moet u andere Fabric-API's aanroepen voor bewerkingen na de implementatie die specifieke configuraties voor deze werkruimte instellen of gegevens opnemen.
  2. Vervolgens wordt er een pull-aanvraag gemaakt voor de testbranch . In de meeste gevallen wordt de pull-aanvraag gemaakt met behulp van een releasebranch die de inhoud kan kiezen om naar de volgende fase te gaan. De pull-aanvraag moet dezelfde beoordelings- en goedkeuringsprocessen bevatten als alle andere processen in uw team of organisatie.
  3. Een andere build- en release-pijplijn wordt geactiveerd om de testwerkruimte bij te werken, met behulp van een proces dat vergelijkbaar is met het proces dat in de eerste stap wordt beschreven.
  4. Er wordt een pull-aanvraag gemaakt voor de Prod-vertakking , met behulp van een proces dat vergelijkbaar is met het proces dat wordt beschreven in stap 2.
  5. Een andere build- en release-pijplijn wordt geactiveerd om de Prod-werkruimte bij te werken, met behulp van een proces dat vergelijkbaar is met het proces dat in de eerste stap wordt beschreven.

Wanneer moet u overwegen optie 1 te gebruiken?

  • Wanneer u uw Git-opslagplaats wilt gebruiken als de enige bron van waarheid en de oorsprong van alle implementaties.
  • Wanneer uw team Gitflow volgt als vertakkingsstrategie, inclusief meerdere primaire vertakkingen.
  • Het uploaden vanuit de opslagplaats gaat rechtstreeks naar de werkruimte, omdat we geen buildomgevingen nodig hebben om de bestanden te wijzigen vóór implementaties. U kunt dit wijzigen door API's aan te roepen of items in de werkruimte uit te voeren na de implementatie.

Optie 2: op Git gebaseerde implementaties met behulp van Build-omgevingen

Diagram van de stroom van implementatie op basis van Git met behulp van buildomgevingen.

Met deze optie zijn alle implementaties afkomstig uit dezelfde vertakking van de Git-opslagplaats (Main). Elke fase in de release-pijplijn heeft een toegewezen build- en release-pijplijn. Deze pijplijnen kunnen een build-omgeving gebruiken om eenheidstests en scripts uit te voeren die enkele definities in de items wijzigen voordat ze naar de werkruimte worden geüpload. U kunt bijvoorbeeld de gegevensbronverbinding, de verbindingen tussen items in de werkruimte of de waarden van parameters wijzigen om de configuratie voor de juiste fase aan te passen.

Zodra een pull-aanvraag voor de dev-vertakking is goedgekeurd en samengevoegd:

  1. Een build-pijplijn wordt geactiveerd om een nieuwe build-omgeving te maken en eenheidstests uit te voeren voor de ontwikkelfase . Vervolgens wordt een release-pijplijn geactiveerd om de inhoud te uploaden naar een build-omgeving, scripts uit te voeren om een deel van de configuratie te wijzigen, de configuratie aan te passen aan de ontwikkelfase en api's voor het bijwerken van itemdefinities van Fabric te gebruiken om de bestanden te uploaden naar de werkruimte.
  2. Wanneer dit proces is voltooid, inclusief het opnemen van gegevens en goedkeuring van releasebeheerders, kunnen de volgende build- en release-pijplijnen voor de testfase worden gemaakt. Deze fasen worden gemaakt in een proces dat vergelijkbaar is met het proces dat in de eerste stap wordt beschreven. Voor de testfase kunnen er na de implementatie andere geautomatiseerde of handmatige tests nodig zijn om te controleren of de wijzigingen gereed zijn om te worden vrijgegeven aan de Prod-fase .
  3. Wanneer alle geautomatiseerde en handmatige tests zijn voltooid, kan de releasemanager de build- en release-pijplijnen goedkeuren en starten naar de Prod-fase. Aangezien de Prod-fase meestal verschillende configuraties heeft dan test-/dev-fasen , is het belangrijk om ook de wijzigingen na de implementatie te testen. Bovendien moet de implementatie de opname van gegevens activeren, op basis van de wijziging, om potentiële niet-beschikbaarheid voor consumenten te minimaliseren.

Wanneer moet u overwegen optie 2 te gebruiken?

  • Wanneer u Git wilt gebruiken als uw enige bron van waarheid en de oorsprong van alle implementaties.
  • Wanneer uw team de op Trunk gebaseerde werkstroom volgt als vertakkingsstrategie.
  • U hebt een buildomgeving (met een aangepast script) nodig om werkruimtespecifieke kenmerken, zoals connectionId en LakehouseId, te wijzigen vóór de implementatie.
  • U hebt een releasepijplijn (aangepast script) nodig om iteminhoud op te halen uit Git en de bijbehorende FABRIC-item-API aan te roepen voor het maken, bijwerken of verwijderen van gewijzigde fabric-items.

Optie 3: Implementeren met infrastructuurimplementatiepijplijnen

Diagram van de stroom van implementatie op basis van Git met behulp van implementatiepijplijnen.

Met deze optie is Git alleen verbonden tot de ontwikkelfase . Vanuit de ontwikkelfase worden implementaties rechtstreeks uitgevoerd tussen de werkruimten van Dev/Test/Prod, met behulp van Infrastructuurimplementatiepijplijnen. Hoewel het hulpprogramma zelf intern is voor Fabric, kunnen ontwikkelaars de API's voor implementatiepijplijnen gebruiken om de implementatie te organiseren als onderdeel van hun Azure-releasepijplijn of een GitHub-werkstroom. Met deze API's kan het team een vergelijkbaar build - en releaseproces bouwen zoals in andere opties, met behulp van geautomatiseerde tests (die kunnen worden uitgevoerd in de werkruimte zelf of vóór de ontwikkelfase ), goedkeuringen, enzovoort.

Zodra de pull-aanvraag naar de hoofdbranch is goedgekeurd en samengevoegd:

  1. Er wordt een build-pijplijn geactiveerd waarmee de wijzigingen in de ontwikkelfase worden geüpload met behulp van Git-API's van Fabric. Indien nodig kan de pijplijn andere API's activeren om bewerkingen/tests na de implementatie in de ontwikkelfase te starten.
  2. Nadat de dev-implementatie is voltooid, wordt er een release-pijplijn gestart om de wijzigingen van de ontwikkelfase naar de testfase te implementeren. Geautomatiseerde en handmatige tests moeten plaatsvinden na de implementatie om ervoor te zorgen dat de wijzigingen goed worden getest voordat de productie wordt bereikt.
  3. Nadat de tests zijn voltooid en de releasemanager de implementatie naar de Prod-fase goedkeurt, wordt de release voor Prod gestart en wordt de implementatie voltooid.

Wanneer moet u overwegen optie 3 te gebruiken?

  • Wanneer u alleen broncodebeheer gebruikt voor ontwikkelingsdoeleinden en liever wijzigingen rechtstreeks tussen fasen van de release-pijplijn implementeert.
  • Wanneer implementatieregels, automatische binding en andere beschikbare API's voldoende zijn om de configuraties tussen de fasen van de release-pijplijn te beheren.
  • Wanneer u andere functies van Infrastructuurimplementatiepijplijnen wilt gebruiken, zoals het weergeven van wijzigingen in Fabric, implementatiegeschiedenis, enzovoort.
  • Houd er ook rekening mee dat implementaties in Infrastructuurimplementatiepijplijnen een lineaire structuur hebben en andere machtigingen nodig hebben om de pijplijn te maken en te beheren.

Optie 4: CI/CD voor ISV's in Fabric (meerdere klanten/oplossingen beheren)

Diagram met de stroom van git-implementatie voor ISV's.

Deze optie verschilt van de andere. Het is het meest relevant voor onafhankelijke softwareleveranciers (ISV) die SaaS-toepassingen bouwen voor hun klanten boven op Fabric. ISV's hebben meestal een afzonderlijke werkruimte voor elke klant en kunnen zo veel mogelijk honderden of duizenden werkruimten hebben. Wanneer de structuur van de analyse die aan elke klant wordt verstrekt, vergelijkbaar is en out-of-the-box is, raden we u aan om een gecentraliseerd ontwikkelings- en testproces te hebben dat alleen wordt gesplitst voor elke klant in de Prod-fase .

Deze optie is gebaseerd op optie 2. Zodra de pull-aanvraag naar de hoofdmap is goedgekeurd en samengevoegd:

  1. Een build-pijplijn wordt geactiveerd om een nieuwe build-omgeving te maken en eenheidstests uit te voeren voor de ontwikkelfase . Wanneer de tests zijn voltooid, wordt er een release-pijplijn geactiveerd. Deze pijplijn kan de inhoud uploaden naar een build-omgeving, scripts uitvoeren om een deel van de configuratie te wijzigen, de configuratie aan te passen aan de ontwikkelfase en vervolgens de definitie-API's van Fabric gebruiken om de bestanden te uploaden naar de werkruimte.
  2. Nadat dit proces is voltooid, inclusief het opnemen van gegevens en goedkeuring van releasebeheerders, kunnen de volgende build- en release-pijplijnen voor de testfase worden gestart. Dit proces is vergelijkbaar met het proces dat in de eerste stap wordt beschreven. Voor de testfase kunnen er na de implementatie andere geautomatiseerde of handmatige tests nodig zijn om te controleren of de wijzigingen gereed zijn om in de Prod-fase van hoge kwaliteit te worden uitgebracht.
  3. Zodra alle tests zijn geslaagd en het goedkeuringsproces is voltooid, kan de implementatie voor Prod-klanten worden gestart. Elke klant heeft een eigen release met eigen parameters, zodat de specifieke configuratie en gegevensverbinding kunnen plaatsvinden in de werkruimte van de relevante klant. De configuratiewijziging kan plaatsvinden via scripts in een buildomgeving of met behulp van API's na de implementatie. Alle releases kunnen parallel plaatsvinden omdat ze niet gerelateerd zijn of afhankelijk zijn van elkaar.

Wanneer moet u overwegen optie 4 te gebruiken?

  • U bent een ISV-bouwtoepassing boven op Fabric.
  • U gebruikt verschillende werkruimten voor elke klant om de multitenancy van uw toepassing te beheren
  • Voor meer scheiding, of voor specifieke tests voor verschillende klanten, wilt u mogelijk meerdere tenants hebben in eerdere fasen van ontwikkelen of testen. Houd er in dat geval rekening mee dat met meerdere tenants het aantal vereiste werkruimten aanzienlijk toeneemt.

Samenvatting

In dit artikel vindt u een overzicht van de belangrijkste CI/CD-opties voor een team dat een geautomatiseerd CI/CD-proces in Fabric wil bouwen. Hoewel we vier opties schetsen, kunnen de werkelijke beperkingen en oplossingsarchitectuur zich lenen voor hybride opties of volledig verschillende opties. U kunt dit artikel gebruiken om u door verschillende opties te leiden en hoe u ze kunt bouwen, maar u bent niet gedwongen om slechts een van de opties te kiezen.

Sommige scenario's of specifieke items hebben mogelijk beperkingen die ervoor kunnen zorgen dat u geen van deze scenario's kunt gebruiken.

Hetzelfde geldt voor tooling. Hoewel we hier verschillende hulpprogramma's noemen, kunt u andere hulpprogramma's kiezen die hetzelfde functionaliteitsniveau kunnen bieden. Houd er rekening mee dat Fabric beter kan worden geïntegreerd met sommige hulpprogramma's, zodat het kiezen van andere hulpprogramma's resulteert in meer beperkingen die verschillende tijdelijke oplossingen nodig hebben.

Gerelateerde inhoud