Zdieľať cez

Vyberte najlepšiu možnosť pracovného postupu služby Fabric CI/CD

  • Článok

Cieľom tohto článku je poskytnúť vývojárom služby Fabric rôzne možnosti na vytváranie procesov CI/CD v službe Fabric na základe bežných scenárov pre zákazníkov. Tento článok sa viac zameriava na nepretržité nasadenie procesu CI/CD. Diskusiu o spojitej integrácii (CI) nájdete v téme Spravovanie vetiev Git.

Hoci tento článok opisuje niekoľko rôznych možností, mnohé organizácie pristupujú k hybridnému prístupu.

Požiadavky

Ak chcete získať prístup k funkcii kanálov nasadenia, musíte spĺňať tieto podmienky:

  • Máte predplatné služby Microsoft Fabric

  • Ste správcom pracovného priestoru služby Fabric

Proces vývoja

Proces vývoja je rovnaký vo všetkých scenároch nasadenia a je nezávislý od toho, ako vydať nové aktualizácie do produkcie. Keď vývojári pracujú s ovládacím prvkom zdroja, musia pracovať v izolovanom prostredí. V službe Fabric môže byť dané prostredie IDE na lokálnom počítači (napríklad Power BI Desktop alebo VS Code) alebo iný pracovný priestor v službe Fabric. Informácie o rôznych aspektoch procesu vývoja nájdete v téme Spravovanie vetiev Git

Diagram znázorňujúci fungovanie vývojového procesu.

Proces vydania

Proces vydania sa spustí po dokončení nových aktualizácií a žiadosť o prijatie zmien sa zlúčila do zdieľanej vetvy tímu (napríklad Main, Dev atď.). Od tohto bodu existujú rôzne možnosti vytvorenia procesu vydania v službe Fabric.

Možnosť 1 – nasadenia na základe Git

Diagram znázorňujúci fungovanie nasadenia na základe systému Git.

S touto možnosťou majú všetky nasadenia pôvod v odkladacom priestore Git. Každá fáza kanála vydania má vyhradenú primárnu vetvu (v diagrame sú to Dev, Test a Prod), ktorá zásobuje príslušný pracovný priestor v fabrice.

Po schválení a zlúčení žiadosti o prijatie zmien do vetvy Dev :

  1. Spustí sa kanál vydania na aktualizáciu obsahu pracovného priestoru Dev . Tento proces môže zahŕňať aj kanál Build na spustenie testov zariadenia, ale skutočné nahrávanie súborov sa vykonáva priamo z odkladacieho priestoru pomocou rozhraní API služby Fabric Git. Možno budete musieť volať iné rozhrania API služby Fabric pre operácie po nasadení, ktoré nastavujú konkrétne konfigurácie pre tento pracovný priestor alebo údaje ingestu.
  2. Pr sa potom vytvorí vo vetve Test . Vo väčšine prípadov sa pr vytvorí pomocou uvoľnenie vetvy, ktorá môže cherry pick obsahu prejsť do ďalšej fázy. Žiadosť o prijatie zmien by mala obsahovať rovnaké procesy kontroly a schvaľovania ako akékoľvek iné procesy vo vašom tíme alebo organizácii.
  3. Spustí sa ďalší kanál zostavy a vydania na aktualizáciu testovacieho pracovného priestoru pomocou procesu podobného procesu, ktorý je popísaný v prvom kroku.
  4. Pr (PR) sa vytvorí vo vetve Prod pomocou procesu podobného procesu, ktorý je popísaný v kroku č. 2.
  5. Spustí sa ďalší kanál zostavy a vydania na aktualizáciu pracovného priestoru Prod pomocou procesu podobného procesu, ktorý je popísaný v prvom kroku.

Kedy je vhodné zvážiť použitie možnosti č. 1?

  • Ak chcete používať svoj odkladací priestor v službe Git ako jediný zdroj pravdy a pôvod všetkých nasadení.
  • Keď váš tím sleduje Gitflow ako stratégiu vetvenia vrátane viacerých primárnych vetiev.
  • Nahrávanie z odkladacieho priestoru prebieha priamo do pracovného priestoru, pretože pred nasadením nepotrebujeme vytvárať prostredia na zmenu súborov. Toto nastavenie môžete zmeniť volaním rozhraní API alebo spustením položiek v pracovnom priestore po nasadení.

Možnosť 2 – nasadenia na základe systému Git pomocou vytvárania prostredí

Diagram znázorňujúci tok nasadenia na základe systému Git pomocou vytvárania prostredí.

S touto možnosťou všetky nasadenia pochádzajú z rovnakej vetvy odkladacieho priestoru Git (Main). Každá fáza kanála vydania má vyhradený kanál zostavy a vydania . Tieto kanály môžu používať prostredie na vytváranie na spustenie testov a skriptov zariadenia, ktoré zmenia niektoré definície v položkách pred ich nahratím do pracovného priestoru. Môžete napríklad zmeniť pripojenie zdroja údajov, pripojenia medzi položkami v pracovnom priestore alebo hodnoty parametrov na úpravu konfigurácie pre správnu fázu.

Po schválení a zlúčení žiadosti o prijatie zmien do vetvy dev :

  1. Spustí sa kanál zostavy, ktorý roztočí nové prostredie na vytváranie a spustí testy zariadenia pre fázu vývojára. Potom sa spustí kanál vydania, ktorý nahrá obsah do prostredia zostavy, spustí skripty, zmení časť konfigurácie, upraví konfiguráciu na vývojárnu fázu a na nahratie súborov do pracovného priestoru použije rozhrania API na aktualizáciu položky služby Fabric.
  2. Po dokončení tohto procesu vrátane spracovania údajov a schválenia od manažérov vydaní je možné vytvoriť ďalšie kanály zostáv a vydaní pre testovaciu fázu. Tieto fázy sa vytvárajú v procese podobnom procesu, ktorý je popísaný v prvom kroku. V prípade fázy testovania môžu byť po nasadení potrebné ďalšie automatizované alebo manuálne testy, aby sa overili, či sú zmeny pripravené na vydanie do fázy Prod .
  3. Po dokončení všetkých automatizovaných a manuálnych testov môže manažér vydania schváliť a spustiť kanály zostáv a vydaní do fázy Prod . Keďže fáza Prod má zvyčajne iné konfigurácie ako fázy test/Vývoj, je dôležité otestovať zmeny aj po nasadení. Nasadenie by tiež malo na základe zmien spúšťať príjem ďalších údajov, aby sa minimalizovala potenciálna nedostupnosť pre spotrebiteľov.

Kedy je vhodné zvážiť použitie možnosti č. 2?

  • Ak chcete používať Git ako jediný zdroj pravdy a pôvod všetkých nasadení.
  • Keď tím sleduje pracovný postup založený na kufra ako svoju stratégiu vetvenia.
  • Na zmenu atribútov špecifických pre pracovný priestor, ako je napríklad connectionId a lakehouseId, je potrebné pred nasadením vytvoriť prostredie na vytváranie (s vlastným skriptom).
  • Na načítanie obsahu položky zo služby git potrebujete kanál vydania (vlastný skript) a zavolať príslušné rozhranie API položky služby Fabric na vytváranie, aktualizáciu alebo odstránenie upravených položiek služby Fabric.

Možnosť 3 – Nasadenie kanálov nasadenia služby Fabric

Diagram znázorňujúci tok nasadenia na základe systému Git pomocou kanálov nasadenia.

Pomocou tejto možnosti je Git pripojený iba do fázy vývojára. Vo fáze vývoja prebieha nasadenie priamo medzi pracovnými priestormi Dev/Test/Prod pomocou kanálov nasadenia služby Fabric. Zatiaľ čo samotný nástroj je pre službu Fabric interný, vývojári môžu použiť rozhrania API kanálov nasadenia na koordinovanie nasadenia ako súčasť svojho kanála vydania služby Azure alebo pracovného postupu služby GitHub. Tieto rozhrania API umožňujú tímu vytvoriť podobný proces zostavy a vydania ako v iných možnostiach pomocou automatizovaných testov (ktoré sa dajú vykonať v samotnom pracovnom priestore alebo pred fázou vývojára ), schválenia atď.

Po schválení a zlúčení žiadosti o prijatie zmien do hlavnej vetvy:

  1. Spustí sa kanál zostáv, ktorý nahrá zmeny do vývojovej fázy pomocou rozhraní API Git služby Fabric. Ak je to potrebné, kanál môže spustiť ďalšie rozhrania API a spustiť operácie po nasadení/testy vo fáze vývojára.
  2. Po dokončení nasadenia vývojára sa spustí kanál vydania na nasadenie zmien z vývojovej fázy do testovacej fázy. Automatizované a manuálne testy by sa mali vykonať po nasadení, aby sa zabezpečilo, že zmeny sa pred dosiahnutím produkcie dobre otestujú.
  3. Po dokončení testov a správca vydania schváli nasadenie do fázy Prod , vydanie do fázy Prod sa spustí a dokončí nasadenie.

Kedy je vhodné zvážiť použitie možnosti č. 3?

  • Keď používate ovládací prvok zdroja len na účely vývoja a uprednostňujete nasadenie zmien priamo medzi fázami kanála vydania.
  • Ak sú na spravovanie konfigurácií medzi fázami kanála vydania dostatočné automatické priradenie a ďalšie dostupné rozhrania API.
  • Ak chcete použiť ďalšie funkcie kanálov nasadenia služby Fabric, napríklad zobrazenie zmien v službe Fabric, história nasadenia atď.
  • Predpokladajme tiež, že nasadenia v kanáloch nasadenia služby Fabric majú lineárnu štruktúru a vyžadujú ďalšie povolenia na vytvorenie a spravovanie kanála.

Možnosť 4 – CI/CD pre nezávislých dodávateľov softvéru v spoločnosti Fabric (spravovanie viacerých zákazníkov/riešení)

Diagram znázorňujúci tok nasadenia Git pre nezávislých dodávateľov softvéru.

Táto možnosť je iná ako ostatné. Je to najdôležitejšie pre nezávislých dodávateľov softvéru (ISV), ktorí vytvárajú aplikácie SaaS pre svojich zákazníkov na základe služby Fabric. Dodávatelia softvéru majú zvyčajne samostatný pracovný priestor pre každého zákazníka a môžu mať až niekoľko stoviek či tisíc pracovných priestorov. Ak je štruktúra analýzy poskytovanej jednotlivým zákazníkom podobná a predpripravené, odporúčame mať centralizovaný vývojový a testovací proces, ktorý sa rozdelí s každým zákazníkom iba vo fáze Prod .

Táto možnosť je založená na možnosti č. 2. Keď sa žiadosť o prijatie zmien v hlavnej schváli a zlúči:

  1. Spustí sa kanál zostavy , ktorý roztočí nové prostredie na vytváranie a spustí testy zariadenia pre vývojárskou fázou. Po dokončení testov sa spustí kanál vydania . Tento kanál môže nahrať obsah do prostredia zostaviť, spustiť skripty a zmeniť časť konfigurácie, upraviť konfiguráciu na vývojárnu fázu a potom na nahratie súborov do pracovného priestoru použiť rozhrania API na aktualizáciu položky služby Fabric.
  2. Po dokončení tohto procesu vrátane spracovania údajov a schválenia od manažérov vydania sa môžu začať ďalšie kanály zostáv a kanálov vydania pre testovaciu fázu. Tento proces je podobný postupu, ktorý je popísaný v prvom kroku. V prípade fázy testovania môžu byť po nasadení potrebné ďalšie automatizované alebo manuálne testy, aby sa overili, či sú zmeny pripravené na vydanie do vysokokvalitnej fázy Prod .
  3. Po dokončení všetkých testov a dokončení procesu schvaľovania môže začať nasadenie zákazníkov s verziou Prod . Každý zákazník má svoje vlastné vydanie s vlastnými parametrami, aby sa v pracovnom priestore príslušného zákazníka mohla uskutočniť jeho špecifická konfigurácia a údajové pripojenie. Zmena konfigurácie sa môže uskutočniť prostredníctvom skriptov v prostredí na vytváranie alebo pomocou rozhraní API po nasadení. Všetky vydania sa môžu vyskytnúť paralelne, pretože nie sú vzájomne prepojené ani závislé.

Kedy je vhodné zvážiť použitie možnosti č. 4?

  • Ste nezávislým dodávateľom softvéru, ktorý vytvára aplikácie na základe služby Fabric.
  • Na spravovanie architektúry s viacerými nájommi aplikácie využívate pre každého zákazníka rôzne pracovné priestory.
  • V prípade väčšieho počtu odchodov alebo konkrétnych testov pre rôznych zákazníkov možno budete chcieť mať v predchádzajúcich fázach vývoja alebo testu viac nájomníkov. V takom prípade sa zoberme do úvahy, že s viacerými nájomníkmi počet požadovaných pracovných priestorov výrazne rastie.

Súhrn

Tento článok obsahuje súhrn hlavných možností CI/CD pre tím, ktorý chce v službe Fabric vytvoriť automatizovaný proces CI/CD. Hoci uvádzame štyri možnosti, obmedzenia reálneho života a architektúra riešenia si môžu sami prepožičať hybridné možnosti alebo úplne iné. Tento článok vás prevedie rôznymi možnosťami a vytváraním týchto možností, ale nie ste nútení vybrať len jednu z možností.

Niektoré scenáre alebo konkrétne položky môžu mať zavedené obmedzenia, ktoré vám bránia v prijímaní niektorého z týchto scenárov.

To isté platí aj pre nástroje. Aj keď tu zmieňujeme o rôznych nástrojoch, môžete si vybrať iné nástroje, ktoré môžu poskytovať rovnakú úroveň funkčnosti. Predpokladajme, že fabric má lepšiu integráciu s niektorými nástrojmi, takže výber iných má za následok ďalšie obmedzenia, ktoré potrebujú rôzne alternatívne riešenia.

Súvisiaci obsah