Najvhodnejšie postupy spravovania životného cyklu

Tento článok poskytuje usmernenie pre tvorcov údajov a analýz, ktorí spravujú svoj obsah počas celého životného cyklu v službe Microsoft Fabric. Článok sa zameriava na používanie integrácie Git pre kanály riadenia zdrojov a nasadenia ako nástroja na vydanie. Všeobecné pokyny na publikovanie podnikového obsahu nájdete v časti Publikovanie podnikového obsahu.

Dôležité

Táto funkcia je vo verzii Preview.

Článok je rozdelený do štyroch sekcií:

• Príprava obsahu – pripravte svoj obsah na správu životného cyklu.

• Vývoj – získajte informácie o najlepších spôsoboch vytvárania obsahu vo fáze vývoja kanálov nasadenia.

• Testovanie – zistite, ako používať fázu testovania kanálov nasadenia na otestovanie prostredia.

• Produkcia – využite fázu produkcie kanálov nasadenia na sprístupnenie obsahu na spotrebu.

Príprava obsahu

Ak chcete čo najlepšie pripraviť svoj obsah na priebežnú správu počas jeho životného cyklu, pred začatím celého životného cyklu si prečítajte informácie v tejto časti:

• Uvoľnenie obsahu do produkcie.

• Začnite používať kanál nasadenia pre konkrétny pracovný priestor.

Oddelenie vývoja medzi tímami

Rôzne tímy v organizácii majú zvyčajne rôzne odborné znalosti, vlastníctvo a pracovné metódy, dokonca aj vtedy, keď pracujú na tom istom projekte. Je dôležité stanoviť hranice a zároveň dať každému tímu ich nezávislosť pracovať tak, ako sa im páči. Zvážte, či máte samostatné pracovné priestory pre rôzne tímy. So samostatnými pracovnými priestormi môže mať každý tím rôzne povolenia, pracovať s rôznymi odkladacími priestormi ovládania zdrojov a odosielať obsah do produkcie iným počtom záznamov. Väčšina položiek sa môže pripájať a používať údaje v pracovných priestoroch, takže nie je blokuje spoluprácu na rovnakých údajoch a projekte.

Plánovanie modelu povolení

Kanály integrácie a nasadenia systému Git vyžadujú iné povolenia, ako len povolenia pre pracovné priestory. Prečítajte si informácie o požiadavkách na povolenia pre integráciu a kanály nasadenia Git.

Ak chcete implementovať zabezpečený a jednoduchý pracovný postup, naplánujte, kto získa prístup ku každej časti používaných prostredí, a to ako do odkladacieho priestoru Git, tak aj do fáz vývojár/test/prod v kanáli. Toto sú niektoré dôležité informácie, ktoré treba vziať do úvahy:

• Kto by mal mať prístup k zdrojového kódu v odkladacom priestore Git?

• Ktoré operácie by používatelia s prístupom ku kanálu mali byť schopní vykonávať v každej fáze?

• Kto kontroluje obsah v testovacej fáze?

• Mali by posudzovatelia testovacej fázy mať prístup ku kanálu?

• Kto by mali dohliadať na nasadenie do produkčnej fázy?

• Ktorý pracovný priestor priraďujete kanálu alebo sa pripájate k službe git?

• Ku ktorej vetve pripájate pracovný priestor? Aká je politika definovaná pre túto vetvu?

• Zdieľajú pracovný priestor viacerí členovia tímu? Majú vykonávať zmeny priamo v pracovnom priestore alebo iba prostredníctvom žiadostí o prijatie zmien?

• Do ktorej fázy priraďujete svoj pracovný priestor?

• Potrebujete vykonať zmeny v povoleniach pracovného priestoru, ktorý priraďujete?

Pripojenie rôznych fázach do rôznych databáz

Produkčná databáza by mala byť vždy stabilná a dostupná. Odporúča sa nepreťažovať ho dotazmi vygenerovanými tvorcami BI na vývoj alebo testovanie sémantických modelov. Vytvorte samostatné databázy na vývoj a testovanie s cieľom chrániť produkčné údaje a nezaťažovať vývojovú databázu celým objemom produkčných údajov.

Používanie parametrov pre konfigurácie, ktoré sa budú medzi fázami meniť

Vždy, keď je to možné, pridajte parametre do ľubovoľnej definície, ktorá sa môže meniť medzi fázami dev/test/prod. Použitie parametrov pomáha jednoducho zmeniť definície pri presunutí zmien do produkcie. Zatiaľ čo v službe Fabric stále neexistuje jednotný spôsob spravovania parametrov, odporúčame ich používať s položkami, ktoré podporujú akýkoľvek typ parametrizácie. Parametre majú rôzne použitie, napríklad definovanie pripojení k zdrojom údajov alebo interných položiek v službe Fabric. Môžu sa tiež použiť na vykonanie zmien v dotazoch, filtroch a texte zobrazenom používateľom.
V kanáloch nasadenia môžete nakonfigurovať pravidlá parametrov na nastavenie rôznych hodnôt pre každú fázu nasadenia.

Vývoj

Táto časť poskytuje návod na prácu s kanálmi nasadenia a použitie vhodného pre vašu vývojovú fázu.

Zálohujte svoju prácu do odkladacieho priestoru Git

S integráciou systému Git môže každý vývojár zálohovať svoju prácu tak, že ju zaviaže do systému Git. Ak chcete svoju prácu v službe Fabric zálohovať správne, tu je niekoľko základných pravidiel:

• Uistite sa, že máte izolované prostredie, s ktorým môžete pracovať, aby ostatní neprepíšu vašu prácu skôr, než sa k nej dopustia. Znamená to, že práca v nástroji aplikácie Desktop (napríklad VS Code, Power BI Desktop alebo iných) alebo v samostatnom pracovnom priestore, ku ktorému nemajú prístup iní používatelia.

• Potvrdiť vetve, ktorú ste vytvorili, a žiaden iný vývojár ju nepoužíva. Ak používate pracovný priestor ako autorské prostredie, prečítajte si o práci s vetvami.

• Potvrdiť spoločne zmeny, ktoré musia byť nasadené spoločne. Táto rada sa vzťahuje na jednu položku alebo viacero položiek, ktoré súvisia s rovnakou zmenou. Spáchanie všetkých súvisiacich zmien spolu vám môže pomôcť neskôr pri nasadení do iných fáz, vytváraní žiadostí o prijatie zmien alebo obnovení zmien.

• Veľké hlásenia môžu mať maximálny limit veľkosti potvrdenia. Majte na pamäti počet položiek, ktoré potvrdíte spolu, alebo na všeobecnú veľkosť položky. Zostavy sa napríklad môžu pri pridávaní veľkých obrázkov zväčšiť. Je zlou praxou ukladať veľké položky v systémoch riadenia zdrojov, aj keď fungujú. Zvážte spôsoby, ako zmenšiť veľkosť položiek, ak majú veľké množstvo statických zdrojov, napríklad obrázkov.

Vrátenie zmien späť

Po zálohovaní práce sa môžu zobraziť prípady, v ktorých sa budete chcieť vrátiť na predchádzajúcu verziu a obnoviť ju v pracovnom priestore. Existuje niekoľko spôsobov, ako sa vrátiť na predchádzajúcu verziu:

• Tlačidlo späť: Operácia späť je jednoduchým a rýchlym spôsobom, ako vrátiť vykonané okamžité zmeny, pokiaľ ešte nie sú potvrdené. Každú položku môžete tiež vrátiť späť samostatne. Prečítajte si viac o operácii vrátenia zmeny .

• Návrat k starším záväzkom: Neexistuje žiadny priamy spôsob, ako sa vrátiť k predchádzajúcemu hláseniu v používateľskom rozhraní. Najlepšou možnosťou je propagovať staršie potvrdenie, aby sa head pomocou git vrátiť alebo git reset. To ukazuje, že na table ovládací prvok zdroja sa nachádza aktualizácia a pracovný priestor môžete aktualizovať týmto novým potvrdením.

Keďže údaje nie sú uložené v službe Git, majte na pamäti, že obnovenie položky údajov do staršej verzie môže viesť k narušeniu existujúcich údajov a môže vyžadovať zrušenie údajov alebo zlyhanie operácie. Pred vrátením zmien to vopred skontrolujte.

Práca s "súkromným" pracovným priestorom

Ak chcete pracovať oddelene, použite samostatný pracovný priestor ako izolované prostredie. Prečítajte si viac o izolovaní pracovného prostredia pri práci s vetvami. Optimálny pracovný postup pre vás a tím získate v nasledujúcich bodoch:

• Nastavenie pracovného priestoru: Skôr než začnete, uistite sa, že môžete vytvoriť nový pracovný priestor (ak ho ešte nemáte), môžete ho priradiť ku kapacite služby Fabric a tiež, že máte prístup k údajom na prácu v pracovnom priestore.

• Vytvorenie novej vetvy: Vytvorte novú vetvu z hlavnej vetvy, aby ste mali najnovšiu verziu obsahu. Uistite sa tiež, že sa pripájate k správnemu priečinku vo vetve, aby ste mohli do pracovného priestoru vytiahnuť správny obsah.

• Malé, časté zmeny: Najvhodnejším postupom v službe Git je vykonávať malé prírastkové zmeny, ktoré sa dajú jednoducho zlúčiť, a s menšou pravdepodobnosťou sa dostať do konfliktov. Ak to nie je možné, nezabudnite aktualizovať svoju vetvu z hlavnej, aby ste mohli najprv vyriešiť konflikty na vlastnú päsť.

• Zmeny konfigurácie: Ak je to potrebné, zmeňte konfigurácie v pracovnom priestore, aby vám pomohli pracovať produktívnejšie. Niektoré zmeny môžu zahŕňať prepojenie medzi položkami, alebo na rôzne zdroje údajov či zmeny parametrov danej položky. Pamätajte si, že čokoľvek, čo potvrdíte, sa stane súčasťou potvrdenia a môže sa náhodne zlúčiť do hlavnej vetvy.

Používanie klientskych nástrojov na úpravu vašej práce

V prípade položiek a nástrojov, ktoré ju podporujú, sa môže zjednodušiť práca s klientskymi nástrojmi na vytváranie, ako je napríklad power BI Desktop pre sémantické modely a zostavy, VSCode pre poznámkové bloky atď. Tieto nástroje môžu byť vaším lokálnym vývojárskym prostredím. Po dokončení práce zatlačte zmeny do vzdialeného odkladacieho priestoru a synchronizujte pracovný priestor, aby ste nahrali zmeny. Len sa uistite, že pracujete s podporovanou štruktúrou položky, ktorú vytvárate. Ak si nie ste istí, najprv naklonujte odkladací priestor s obsahom, ktorý je už synchronizovaný s pracovným priestorom, a potom začnite vytvárať odtiaľ, kde je už štruktúra na mieste.

Spravovanie pracovných priestorov a vetiev

Keďže pracovný priestor je možné pripojiť len k jednej vetve súčasne, odporúča sa, aby ste ho vnímali ako priradenie 1:1. Ak však chcete znížiť množstvo pracovných priestorov, zvážte tieto možnosti:

• Ak vývojár nastaví súkromný pracovný priestor so všetkými požadovanými konfiguráciami, môže tento pracovný priestor naďalej používať pre ľubovoľnú budúcu vetvu, ktorú vytvorí. Po skončení šprintu sa vaše zmeny zlúčia a spustíte novú úlohu. Stačí prepnúť pripojenie na novú vetvu v tom istom pracovnom priestore. Môžete to urobiť aj vtedy, ak náhle potrebujete opraviť chybu uprostred šprintu. Predstavte si ho ako pracovný adresár na webe.

• Vývojári, ktorí používajú klientsky nástroj (napríklad VS Code, Power BI Desktop alebo iné), nemusia nevyhnutne potrebovať pracovný priestor. Môžu vytvárať vetvy a potvrdiť zmeny v danej vetve lokálne, odosielať ich do vzdialeného odkladacieho priestoru a vytvárať žiadosti o prijatie zmien do hlavnej vetvy, a to všetko bez pracovného priestoru. Pracovný priestor je potrebný len ako testovacie prostredie na kontrolu, či všetko funguje v scenári reálneho života. Je na vás, aby ste sa rozhodli, kedy sa to stane.

Duplikovanie položky v odkladacom priestore Git

Duplikovanie položky v odkladacom priestore Git:

1. Skopírujte celý adresár položiek.
2. Zmeňte logickú hodnotuId na niečo jedinečné pre tento pripojený pracovný priestor.
3. Zmeňte zobrazovaný názov, aby ste ju odlíšili od pôvodnej položky, a aby sa predišlo chybe duplicitného zobrazovaného názvu.
4. Ak je to potrebné, aktualizujte logický identifikátor a/alebo zobrazované názvy v závislostiach.

Test

Táto časť poskytuje návod na prácu s testovacou fázou kanálov nasadenia.

Simulácia produkčného prostredia

Je dôležité vidieť, ako vaša navrhovaná zmena ovplyvní produkčnú fázu. Testovacia fáza kanálov nasadenia umožňuje simulovať skutočné produkčné prostredie na testovacie účely. Prípadne to môžete simulovať pripojením služby Git k inému pracovnému priestoru.

Uistite sa, že vo vašom testovacom prostredí sú riešené tieto tri faktory:

• Objem údajov

• Objem použitia

• Podobná kapacita ako vo výrobe

Pri testovaní môžete použiť rovnakú kapacitu ako fáza produkcie. Použitie rovnakej kapacity však môže počas testovania zaťaženia vytvoriť nestabilitu produkcie. Ak sa chcete vyhnúť nestabilnej produkcii, otestujte použitie inej kapacity, ktorá je zdrojmi podobná produkčnej kapacite. Ak sa chcete vyhnúť dodatočným nákladom, použite kapacitu, ktorú môžete zaplatiť len za čas testovania.

Použitie pravidiel nasadenia s reálnym zdrojom údajov

Ak používate testovaciu fázu na simuláciu používania údajov v reálnom živote, najlepšie je oddeliť vývojové a testovacie zdroje údajov. Vývojová databáza by mala byť relatívne malá a testovacia databáza by mala byť čo najviac podobná produkčnej databáze. Použite pravidlá zdroja údajov na prepínanie zdrojov údajov v testovacej fáze alebo parametrizovanie pripojenia, ak nepracujú cez kanály nasadenia.

Kontrola súvisiacich položiek

Vykonané zmeny môžu ovplyvniť aj závislé položky. Počas testovania overte, či vaše zmeny neovplyvňujú alebo neprerušujú výkon existujúcich položiek, ktoré môžu byť závislé od aktualizovaných položiek.

Pomocou analýzy vplyvu môžete ľahko nájsť súvisiace položky.

Aktualizácia údajových položiek

Položky údajov sú položky, ktoré ukladajú údaje. Definícia položky v Git definuje, ako sú údaje uložené. Pri aktualizácii položky v pracovnom priestore importujeme jej definíciu do pracovného priestoru a použijeme ju na existujúce údaje. Operácia aktualizácie údajových položiek je rovnaká pre kanály Git a nasadenia.

Keďže rôzne položky majú pri uchovávaní údajov pri použití zmien definície rôzne možnosti, pri použití zmien majte na pamäti. Niektoré postupy, ktoré vám môžu pomôcť použiť zmeny najbezpečnejším spôsobom:

• Vopred viete, aké zmeny majú a aký vplyv môžu mať na existujúce údaje. Použite hlásenia potvrdenia na popis vykonaných zmien.

• Ak chcete zistiť, ako daná položka narába so zmenou pomocou testovacích údajov, nahrajte zmeny najskôr do vývojového alebo testovacieho prostredia.

• Ak všetko ide dobre, odporúča sa tiež skontrolovať ho v prostredí pracovnej verzie s údajmi z reálneho života (alebo čo najbližšie k nemu), aby sa minimalizovalo neočakávané správanie v produkcii.

• Zvážte najlepšie načasovanie aktualizácie prostredia Prod na minimalizovanie poškodenia, ktoré môžu spôsobiť chyby vašim podnikovím používateľom, ktorí údaje spotrebúvajú.

• Po nasadení, post-nasadenie testy v Prod overiť, že všetko funguje podľa očakávania.

• Niektoré zmeny sa vždy budú považovať za prelomové zmeny. Dúfame, že predchádzajúce kroky vám pomôžu sledovať ich pred produkciou. Vytvorte si plán, ako použiť zmeny v službe Prod a obnoviť údaje, aby ste sa vrátili do normálneho stavu a minimalizovali prestoje pre podnikových používateľov.

Otestovanie aplikácie

Ak distribuujete obsah svojim zákazníkom prostredníctvom aplikácie, pred produkčnou verziou skontrolujte novú verziu aplikácie. Keďže každá fáza kanála nasadenia má svoj vlastný pracovný priestor, môžete jednoducho publikovať a aktualizovať aplikácie pre fázy vývoja a testovania. Publikovanie a aktualizácia aplikácií umožňuje otestovať aplikáciu z pohľadu koncového používateľa.

Dôležité

Proces nasadenia nezahŕňa aktualizáciu obsahu ani nastavení aplikácie. Ak chcete použiť zmeny na obsah alebo nastavenia, manuálne aktualizujte aplikáciu v požadovanej fáze kanála.

Produkčné

Táto časť poskytuje návod pre produkčnú fázu kanálov nasadenia.

Spravovanie používateľov, ktorí môžu nasadzovať do produkčnej fázy

Nasadenie do produkčného prostredia by sa malo vykonávať opatrne, preto je vhodné, aby túto citlivú operáciu riadili iba konkrétni ľudia. Pravdepodobne však chcete, aby všetci tvorcovia BI pre konkrétny pracovný priestor mali prístup ku kanálu. Pomocou povolení produkčného pracovného priestoru môžete spravovať prístupové povolenia. Ostatní používatelia môžu mať rolu zobrazovača produkčného pracovného priestoru, aby si mohli zobraziť obsah v pracovnom priestore, ale nemôžu vykonávať zmeny z kanálov Git alebo nasadenia.

Okrem toho obmedzte prístup k odkladaciemu priestoru alebo kanálu len tým, že povolíte povolenia len pre používateľov, ktorí sú súčasťou procesu vytvárania obsahu.

Nastavenie pravidiel na zabezpečenie dostupnosti produkčnej fázy

Pravidlá nasadenia sú účinným spôsobom ako zabezpečiť, aby údaje vo výrobe boli vždy pripojené a dostupné pre používateľov. S použitím pravidiel nasadenia môžu byť nasadenia spustené a vy budete mať istotu, že zákazníci uvidia relevantné informácie bez rušenia.

Uistite sa, že ste nastavili pravidlá nasadenia produkcie pre zdroje údajov a parametre definované v sémantickom modeli.

Aktualizácia produkčnej aplikácie

Nasadenie v kanáli prostredníctvom používateľského rozhrania aktualizuje obsah pracovného priestoru. Ak chcete aktualizovať priradenú aplikáciu, použite rozhranie API kanálov nasadenia. Aplikáciu nie je možné aktualizovať prostredníctvom používateľského rozhrania. Ak použijete aplikáciu na distribúciu obsahu, nezabudnite aplikáciu aktualizovať po nasadení do produkcie, aby koncoví používatelia okamžite mohli používať najnovšiu verziu.

Nasadenie do produkcie pomocou vetiev Git

Keďže odkladací priestor slúži ako "jediný zdroj pravdy", niektoré tímy môžu chcieť nasadiť aktualizácie do rôznych fáz priamo zo služby Git. Je to možné pri integrácii Git s niekoľkými dôležité informácieami:

• Odporúčame používať vydania vetiev. Pred každým nasadením je potrebné neustále meniť pripojenie pracovného priestoru k novým vetvám vydaní.

• Ak váš kanál na vytváranie alebo vydávanie vyžaduje zmenu zdrojového kódu alebo spustenie skriptov v prostredí zostavy pred nasadením do pracovného priestoru, pripojenie pracovného priestoru k službe Git vám nepomôže.

• Po nasadení do každej fázy nezabudnite zmeniť celú konfiguráciu špecifickú pre danú fázu.

Rýchle opravy obsahu

Niekedy sa vyskytli v produkcii problémy, ktoré si vyžadujú rýchlu opravu. Nasadenie opravy bez jej prvého testovania nie je zlý postup. Preto vždy implementujte opravu vo fáze vývoja a posúvajte ju do ďalších fáz kanála nasadenia. Nasadenie do fázy vývoja vám umožňuje skontrolovať, či oprava funguje pred jej nasadením do produkcie. Nasadenie v rámci kanála trvá len niekoľko minút.

Ak používate nasadenie zo služby Git, odporúčame postupovať podľa postupov popísaných v téme Prijatie stratégie vetvenia Git.

Súvisiaci obsah

• Kurz o spravovaní životného cyklu ukončiť
• Začíname s integráciou Git
• Začíname s kanálmi nasadenia