Dela via

Välj det bästa alternativet för Infrastruktur-CI/CD-arbetsflöde åt dig

  • Artikel

Målet med den här artikeln är att presentera infrastrukturutvecklare med olika alternativ för att skapa CI/CD-processer i Fabric, baserat på vanliga kundscenarier. Den här artikeln fokuserar mer på kontinuerlig distribution (CD) av CI/CD-processen. En diskussion om den kontinuerliga integreringsdelen (CI) finns i Hantera Git-grenar.

Den här artikeln beskriver flera olika alternativ, men många organisationer använder en hybridmetod.

Förutsättningar

För att få åtkomst till funktionen för distributionspipelines måste du uppfylla följande villkor:

Utvecklingsprocess

Utvecklingsprocessen är densamma i alla distributionsscenarier och är oberoende av hur nya uppdateringar släpps i produktion. När utvecklare arbetar med källkontroll måste de arbeta i en isolerad miljö. I Infrastruktur kan den miljön antingen vara en IDE på din lokala dator (till exempel Power BI Desktop eller VS Code) eller en annan arbetsyta i Infrastrukturresurser. Du hittar information om de olika övervägandena för utvecklingsprocessen i Hantera Git-grenar

Diagram som visar hur utvecklingsprocessen fungerar.

Släppningsprocess

Lanseringsprocessen startar när nya uppdateringar har slutförts och pull-begäran (PR) har slagits samman med teamets delade gren (till exempel Main, Dev osv.). Från och med nu finns det olika alternativ för att skapa en lanseringsprocess i Infrastrukturresurser.

Alternativ 1 – Git-baserade distributioner

Diagram som visar hur den Git-baserade distributionen fungerar.

Med det här alternativet kommer alla distributioner från Git-lagringsplatsen. Varje steg i versionspipelinen har en dedikerad primär gren (i diagrammet är dessa steg Dev, Test och Prod), som matar lämplig arbetsyta i Infrastrukturresurser.

När en PR till Dev-grenen har godkänts och sammanfogats:

  1. En versionspipeline utlöses för att uppdatera innehållet i Dev-arbetsytan . Den här processen kan också innehålla en Bygg-pipeline för att köra enhetstester, men den faktiska uppladdningen av filer görs direkt från lagringsplatsen till arbetsytan med hjälp av Git-API:er för infrastrukturresurser. Du kan behöva anropa andra Infrastruktur-API:er för åtgärder efter distributionen som anger specifika konfigurationer för den här arbetsytan eller matar in data.
  2. En PR skapas sedan till testgrenen. I de flesta fall skapas PR med hjälp av en versionsgren som kan plocka innehållet för att gå vidare till nästa steg. PR bör innehålla samma gransknings- och godkännandeprocesser som andra i ditt team eller din organisation.
  3. En annan bygg - och versionspipeline utlöses för att uppdatera testarbetsytan med en process som liknar den som beskrivs i det första steget.
  4. En PR skapas till Prod-grenen med en process som liknar den som beskrivs i steg 2.
  5. En annan bygg - och versionspipeline utlöses för att uppdatera Prod-arbetsytan med hjälp av en process som liknar den som beskrivs i det första steget.

När bör du överväga att använda alternativ 1?

  • När du vill använda git-lagringsplatsen som enskild sanningskälla och ursprunget för alla distributioner.
  • När ditt team följer Gitflow som förgreningsstrategi, inklusive flera primära grenar.
  • Uppladdningen från lagringsplatsen går direkt till arbetsytan eftersom vi inte behöver skapa miljöer för att ändra filerna före distributioner. Du kan ändra detta genom att anropa API:er eller köra objekt på arbetsytan efter distributionen.

Alternativ 2 – Git-baserade distributioner med hjälp av byggmiljöer

Diagram som visar flödet för Git-baserad distribution med hjälp av byggmiljöer.

Med det här alternativet kommer alla distributioner från samma gren av Git-lagringsplatsen (Main). Varje steg i versionspipelinen har en dedikerad bygg- och versionspipeline. Dessa pipelines kan använda en Build-miljö för att köra enhetstester och skript som ändrar vissa definitioner i objekten innan de laddas upp till arbetsytan. Du kanske till exempel vill ändra datakällans anslutning, anslutningarna mellan objekt på arbetsytan eller värdena för parametrar för att justera konfigurationen för rätt fas.

När en PR till utvecklingsgrenen har godkänts och sammanfogats:

  1. En byggpipeline utlöses för att starta en ny build-miljö och köra enhetstester för utvecklingsfasen . Sedan utlöses en versionspipeline för att ladda upp innehållet till en Build-miljö, köra skript för att ändra en del av konfigurationen, justera konfigurationen till utvecklingsfasen och använda API:er för uppdateringsobjektdefinition för att ladda upp filerna till arbetsytan.
  2. När den här processen är klar, inklusive inmatning av data och godkännande från versionshanterare, kan nästa bygg - och versionspipelines för testfasen skapas. Dessa steg skapas i en process som liknar den som beskrivs i det första steget. För testfasen kan andra automatiserade eller manuella tester krävas efter distributionen för att verifiera att ändringarna är redo att släppas till Prod-fasen .
  3. När alla automatiserade och manuella tester är klara kan versionshanteraren godkänna och starta bygg- och versionspipelines till Prod-fasen. Eftersom Prod-fasen vanligtvis har andra konfigurationer än test-/dev-faser är det viktigt att även testa ändringarna efter distributionen. Distributionen bör också utlösa mer datainmatning, baserat på ändringen, för att minimera potentiell icke-tillgänglighet för konsumenter.

När bör du överväga att använda alternativ 2?

  • När du vill använda Git som din enda sanningskälla och ursprunget för alla distributioner.
  • När ditt team följer Trunk-baserat arbetsflöde som sin förgreningsstrategi.
  • Du behöver en byggmiljö (med ett anpassat skript) för att ändra arbetsytespecifika attribut, till exempel connectionId och lakehouseId, före distributionen.
  • Du behöver en versionspipeline (anpassat skript) för att hämta objektinnehåll från git och anropa motsvarande API för infrastrukturobjekt för att skapa, uppdatera eller ta bort ändrade infrastrukturobjekt.

Alternativ 3 – Distribuera med infrastrukturdistributionspipelines

Diagram som visar flödet för Git-baserad distribution med hjälp av distributionspipelines.

Med det här alternativet är Git endast anslutet till utvecklingssteget. Från utvecklingsfasen sker distributioner direkt mellan arbetsytorna i Dev/Test/Prod med hjälp av infrastrukturdistributionspipelines. Även om själva verktyget är internt för Fabric kan utvecklare använda API: erna för distributionspipelines för att samordna distributionen som en del av sin Azure-versionspipeline eller ett GitHub-arbetsflöde. Dessa API:er gör det möjligt för teamet att skapa en liknande bygg- och lanseringsprocess som i andra alternativ genom att använda automatiserade tester (som kan göras på själva arbetsytan eller före utvecklingsfasen), godkännanden osv.

När PR till huvudgrenen har godkänts och sammanfogats:

  1. En byggpipeline utlöses som överför ändringarna till utvecklingsfasen med hjälp av Git-API:er för infrastrukturresurser. Vid behov kan pipelinen utlösa andra API:er för att starta åtgärder/tester efter distributionen i utvecklingsfasen .
  2. När utvecklingsdistributionen har slutförts startar en versionspipeline för att distribuera ändringarna från utvecklingsfasen till testfasen. Automatiserade och manuella tester bör utföras efter distributionen för att säkerställa att ändringarna testas väl innan de når produktion.
  3. När testerna har slutförts och versionshanteraren godkänner distributionen till Prod-fasen startar versionen till Prod och slutför distributionen.

När bör du överväga att använda alternativ 3?

  • När du endast använder källkontroll i utvecklingssyfte och föredrar att distribuera ändringar direkt mellan stegen i versionspipelinen.
  • När distributionsregler, automatiskbindning och andra tillgängliga API:er räcker för att hantera konfigurationerna mellan faserna i versionspipelinen.
  • När du vill använda andra funktioner i Infrastrukturdistributionspipelines, till exempel att visa ändringar i Infrastrukturresurser, distributionshistorik osv.
  • Tänk också på att distributioner i infrastrukturdistributionspipelines har en linjär struktur och kräver andra behörigheter för att skapa och hantera pipelinen.

Alternativ 4 – CI/CD för ISV:er i Infrastrukturresurser (hantering av flera kunder/lösningar)

Diagram som visar flödet för Git-baserad distribution för ISV:er.

Det här alternativet skiljer sig från de andra. Det är mest relevant för oberoende programvaruleverantörer (ISV) som skapar SaaS-program för sina kunder ovanpå Fabric. ISV:er har vanligtvis en separat arbetsyta för varje kund och kan ha så många som flera hundra eller tusentals arbetsytor. När strukturen för analyserna som tillhandahålls varje kund är liknande och inbyggda rekommenderar vi att du har en centraliserad utveckling och testningsprocess som delas upp till varje kund endast i Prod-fasen .

Det här alternativet baseras på alternativ 2. När pr till main har godkänts och sammanfogats:

  1. En byggpipeline utlöses för att starta en ny build-miljö och köra enhetstester för utvecklingsfasen . När testerna är klara utlöses en versionspipeline . Den här pipelinen kan ladda upp innehållet till en Build-miljö, köra skript för att ändra en del av konfigurationen, justera konfigurationen till utvecklingsfasen och sedan använda API:er för uppdateringsobjektsdefinition för att ladda upp filerna till arbetsytan.
  2. När den här processen är klar, inklusive inmatning av data och godkännande från versionshanterare, kan nästa bygg - och versionspipelines för testfasen starta. Den här processen liknar den som beskrivs i det första steget. För teststeg kan andra automatiserade eller manuella tester krävas efter distributionen, för att verifiera att ändringarna är redo att släppas till Prod-stadiet i hög kvalitet.
  3. När alla tester har godkänts och godkännandeprocessen är klar kan distributionen till Prod-kunder starta. Varje kund har en egen version med sina egna parametrar, så att dess specifika konfiguration och dataanslutning kan ske på den relevanta kundens arbetsyta. Konfigurationsändringen kan ske via skript i en byggmiljö eller med hjälp av API:er efter distributionen. Alla versioner kan ske parallellt eftersom de inte är relaterade eller beroende av varandra.

När bör du överväga att använda alternativ 4?

  • Du är ett ISV-byggprogram ovanpå Fabric.
  • Du använder olika arbetsytor för varje kund för att hantera flera innehavare av ditt program
  • För mer separation, eller för specifika tester för olika kunder, kanske du vill ha flera innehavare i tidigare utvecklings- eller testfaser. I så fall bör du tänka på att antalet arbetsytor som krävs ökar avsevärt med flera innehavare.

Sammanfattning

Den här artikeln sammanfattar de viktigaste CI/CD-alternativen för ett team som vill skapa en automatiserad CI/CD-process i Infrastrukturresurser. Vi beskriver fyra alternativ, men de verkliga begränsningarna och lösningsarkitekturen kan ge sig själva hybridalternativ eller helt olika alternativ. Du kan använda den här artikeln för att vägleda dig genom olika alternativ och hur du skapar dem, men du är inte tvungen att välja ett av alternativen.

Vissa scenarier eller specifika objekt kan ha begränsningar som kan hindra dig från att använda något av dessa scenarier.

Samma sak gäller för verktyg. Även om vi nämner olika verktyg här kan du välja andra verktyg som kan ge samma funktionsnivå. Tänk på att Fabric har bättre integrering med vissa verktyg, så att välja andra resulterar i fler begränsningar som behöver olika lösningar.

Relaterat innehåll