Zdieľať cez


Scenáre používania služby Power BI: Publikovanie podnikového obsahu

Poznámka

Tento článok je súčasťou série článkov k plánovaniu implementácie služby Power BI. Táto séria sa zameriava predovšetkým na prostredie služby Power BI v rámci služby Microsoft Fabric. Úvod do série nájdete v téme Plánovanie implementácie služby Power BI.

Keď tvorcovia obsahu spolupracujú na poskytovaní analytických riešení, ktoré sú pre organizáciu dôležité, musia zabezpečiť včasné a spoľahlivé doručovanie obsahu spotrebiteľom. Technické tímy riešia túto výzvu pomocou procesu s názvom DevOps. DevOps umožňuje tímom automatizovať a škálovať procesy prijímaním postupov, ktoré zlepšujú a urýchľujú poskytovanie.

Poznámka

Dátové tímy, ktoré riešia rovnaké výzvy, môžu tiež cvičiť DataOps. DataOps stavia na princípoch DevOps, ale DataOps obsahuje ďalšie postupy špecifické pre správu údajov, ako napríklad zabezpečenie kvality údajov a riadenie. V tomto článku odkazujeme na devOps, ale uvedomte si, že základné princípy sa môžu vzťahovať aj na DataOps.

Tvorcovia obsahu a spotrebitelia môžu pri prijímaní postupov DevOps pri publikovaní obsahu služby Power BI využívať niekoľko výhod. Nasledujúce body predstavujú podrobný prehľad fungovania tohto procesu.

  1. Vývoj obsahu a práca na záväzkoch do vzdialeného odkladacieho priestoru: Tvorcovia obsahu vyvíjajú svoje riešenie na vlastnom počítači. Potvrdiť a uložiť svoju prácu do vzdialeného odkladacieho priestoru v pravidelných intervaloch počas vývoja. Vzdialený odkladací priestor obsahuje najnovšiu verziu riešenia a je dostupný pre celý vývojový tím.
  2. Spolupráca a spravovanie zmien obsahu pomocou ovládania verzií: Ostatní tvorcovia obsahu môžu vykonávať revízie riešenia vytvorením vetvy. Vetva je kópiou vzdialeného odkladacieho priestoru. Po dokončení a schválení týchto revízií sa vetva zlúči s najnovšou verziou riešenia. Všetky revízie riešenia sa sledujú. Tento proces je známy ako ovládanie verzií (alebo ovládací prvok zdroja).
  3. Nasadenie a propagácia obsahu pomocou kanálov: V scenári samoobslužného publikovania obsahu sa propaguje (alebo nasadzuje) obsah prostredníctvom vývojových, testovacích a produkčných pracovných priestorov pomocou kanálov nasadenia služby Power BI. Kanály nasadenia služby Power BI môžu propagovať obsah do pracovných priestorov Power BI Premium manuálne pomocou používateľského rozhrania alebo pomocou programovania s rozhraním REST API. Naopak publikovanie podnikového obsahu (zameranie tohto scenára používania) podporuje obsah pomocou kanálov Azure. Kanály Azure sú službou Azure DevOps, ktorá automatizuje testovanie, správu a nasadenie obsahu pomocou série prispôsobených programových krokov. V scenári používania publikovania podnikového obsahu môžu byť tieto kanály označované aj ako kanály nepretržitej integrácie a nasadenia (alebo CI/CD). Tieto kanály často a automaticky integrujú zmeny a zjednodušujú publikovanie obsahu.

Dôležité

V čase, keď sa tento článok týka služby Power BI Premium alebo jej predplatných kapacity (skladové jednotky SKU P). Spoločnosť Microsoft v súčasnosti konsoliduje možnosti nákupu a vyradí skladové jednotky SKU služby Power BI Premium na kapacitu. Noví a existujúci zákazníci by namiesto toho mali zvážiť zakúpenie predplatného kapacity služby Fabric (skladové jednotky F SKU).

Ďalšie informácie nájdete v téme Dôležitá aktualizácia pre licencie Power BI Premium a Power BI Premium: najčastejšie otázky.

DevOps podporuje vyspelý a systematický prístup k správe obsahu a publikovaniu. Umožňuje tvorcom obsahu spolupracovať na riešeniach a zaisťuje rýchle a spoľahlivé doručovanie obsahu spotrebiteľom. Pri dodržiavaní postupov DevOps môžete využívať výhody z zjednodušených pracovných postupov, menšieho počtu chýb a vylepšených možností pre tvorcov obsahu a používateľov obsahu.

Postupy devOps môžete nastaviť a spravovať pre riešenie služby Power BI pomocou služby Azure DevOps. V podnikových scenároch môžete automatizovať publikovanie obsahu pomocou služby Azure DevOps a rozhraní REST API služby Power BI tromi rôznymi spôsobmi.

  • Rozhrania REST API služby Power BI s kanálmi nasadenia služby Power BI: Obsah môžete importovať do vývojových pracovných priestorov a použiť kanály nasadenia na nasadenie obsahu prostredníctvom testovacích a produkčných pracovných priestorov. Stále máte kontrolu nad nasadením zo služby Azure DevOps a pomocou rozhraní REST API služby Power BI môžete spravovať kanály nasadenia namiesto jednotlivých položiek obsahu. Okrem toho môžete použiť koncový bod XMLA na nasadenie metaúdajov dátového modelu namiesto súboru aplikácie Power BI Desktop (.pbix) so službou Azure DevOps. Tieto metaúdaje vám umožňujú sledovať zmeny na úrovni objektu pomocou ovládacieho prvku verzie. Hoci je údržba robustnejšia a jednoduchšia, na nastavenie importu a nasadenia obsahu pomocou rozhraní REST API služby Power BI vyžaduje licencovanie verzie Premium a mierne úsilie na skriptovanie. Tento prístup použite, ak chcete zjednodušiť správu životného cyklu obsahu s kanálmi nasadenia a máte licenciu Premium. Koncový bod XMLA a kanály nasadenia služby Power BI sú funkcie verzie Premium.
  • Rozhrania REST API služby Power BI: Obsah môžete tiež importovať do vývojových, testovacích a produkčných pracovných priestorov pomocou služby Azure DevOps a len rozhraní REST API služby Power BI. Tento prístup nevyžaduje licencovanie verzie Premium, ale zahŕňa vysoké úsilie pri skriptovaní a nastavovaní, pretože nasadenie sa spravuje mimo služby Power BI. Tento prístup použite, ak chcete nasadiť obsah služby Power BI centrálne zo služby Azure DevOps alebo ak nemáte licenciu Premium. Vizuálne porovnanie medzi prvými dvoma prístupmi nájdete v diagrame prístupov kanálov vydania.
  • Nástroje na automatizáciu služby Power BI s kanálmi nasadenia služby Power BI: Na spravovanie kanálov nasadenia namiesto rozhraní REST API služby Power BI môžete použiť rozšírenie Azure DevOps pre automatizáciu služby Power BI. Tento prístup je alternatívou k prvej možnosti, ktorá používa rozhrania REST API služby Power BI s kanálmi nasadenia služby Power BI. Rozšírenie nástrojov automatizácie služby Power BI predstavuje nástroj open-source. Pomáha spravovať a publikovať obsah zo služby Azure DevOps bez nutnosti zapisovania skriptov prostredia PowerShell. Tento prístup použite, ak chcete spravovať kanály nasadenia zo služby Azure DevOps s minimálnym úsilím skriptovania a máte kapacitu Premium.

Tento článok sa zameriava na prvú možnosť, ktorá používa rozhrania REST API služby Power BI s kanálmi nasadenia služby Power BI. Popisuje, ako môžete pomocou služby Azure DevOps nastaviť postupy pre DevOps. Popisuje tiež, ako môžete používať Odkladacie priestory Azure pre vzdialené odkladacie priestory a automatizovať testovanie obsahu, integráciu a doručovanie s kanálmi Azure. Azure DevOps nie je jediný spôsob ako nastaviť publikovanie podnikového obsahu, ale jednoduchá integrácia so službou Power BI ho robí dobrou voľbou.

Poznámka

Tento scenár použitia je jedným zo scenárov spravovania obsahu a nasadenia . Z dôvodu stručnosti nie sú niektoré aspekty popísané v téme Scenáre spolupráce s obsahom a doručovania zahrnuté v tomto článku. Ak chcete dokončiť pokrytie, prečítajte si tieto články ako prvé.

Tip

Microsoft Fabric poskytuje ďalšie možnosti publikovania podnikového obsahu pomocou integrácie Git služby Fabric. Integrácia systému Git umožňuje prepojiť pracovný priestor služby Fabric s vetvou vo vašom vzdialenom odkladacom priestore Azure Repos. Obsah uložený do danej vetvy sa automaticky synchronizuje do pracovného priestoru, akoby bol daný obsah publikovaný v pracovnom priestore. Naopak, tvorcovia obsahu môžu potvrdiť a presunúť zmeny z pracovného priestoru služby Fabric do vzdialeného odkladacieho priestoru.

Integrácia systému Git môže zjednodušiť spoluprácu a publikovanie obsahu, ale vyžaduje si viac plánovania používania pracovných priestorov služby Fabric a stratégie vetvenia. Ďalšie informácie o tom, ako môžete nastaviť a používať integráciu systému Git služby Fabric, nájdete v téme Začíname s integráciou systému Git alebo Kurz: Ukončiť spravovanie životného cyklu.

Diagram scenára

Nasledujúci diagram znázorňuje podrobný prehľad najčastejších akcií používateľa a súčastí služby Power BI, ktoré podporujú publikovanie podnikového obsahu. Dôraz sa kladie na používanie služby Azure DevOps na programovú správu a publikovanie obsahu prostredníctvom vývojových, testovacích a produkčných pracovných priestorov v služba Power BI.

Diagram znázorňujúci publikovanie podnikového obsahu, čo je o zlepšení spolupráce a spravovaní obsahu vo väčšom meradle pomocou služby Azure DevOps. Položky v diagrame sú popísané v tabuľke.

Tip

Odporúčame stiahnuť scenárový diagram , ak by ste ho chceli vložiť do prezentácie, dokumentácie alebo blogového príspevku, alebo ho vytlačiť ako plagát steny. Keďže ide o obrázok SVG (Scalable Vector Graphics), môžete ho škálovať nahor alebo nadol bez straty kvality.

Diagram scenára znázorňuje nasledujúce akcie, procesy a funkcie používateľa.

Položka Popis
Položka 1. Tvorcovia obsahu vyvíjajú dátové modely pomocou aplikácie Power BI Desktop alebo tabuľkového editora a vyvíjajú zostavy pomocou aplikácie Power BI Desktop. Tvorcovia obsahu si počas vývoja ukladajú prácu do lokálneho odkladacieho priestoru.
Položka 2. Tvorcovia obsahu môžu naklonovať vzdialený odkladací priestor a získať lokálnu kópiu tohto obsahu.
Položka 3. Niektoré zdroje údajov môžu na obnovenie údajov vyžadovať lokálnu bránu údajov alebo bránu VNet, napríklad tie, ktoré sa nachádzajú v súkromnej sieti organizácie.
Položka 4. Tvorcovia obsahu pravidelne potvrdia a presúvajú svoje zmeny do vzdialeného odkladacieho priestoru počas vývoja pomocou klienta Git, ako je napríklad Visual Studio Code. V diagrame je vzdialeným odkladacím priestorom Odkladacie priestory Azure.
Položka 5. Ostatní tvorcovia obsahu používajú odkladacie priestory Azure na sledovanie zmien pomocou riadenia verzií. Spolupracujú záväzkami zmien do samostatných vetiev.
Položka 6. Zmeny obsahu vo vzdialenom odkladacom priestore spúšťajú kanály Azure. Overovací kanál je prvým spúšťaným kanálom. Overovací kanál vykonáva automatizované testy na overenie obsahu pred jeho publikovaním.
Položka 7. Obsah, ktorý prechádza kanálom overenia, spustí nasledujúci kanál zostavy. Kanál zostavy pripravuje obsah na publikovanie v služba Power BI. Proces až do tohto bodu sa zvyčajne označuje ako spojitá integrácia (CI).
Položka 8. Obsah sa publikuje a nasadí pomocou kanálov vydania. Kanály vydania používajú buď rozhrania REST API služby Power BI, alebo koncový bod XMLA pracovného priestoru na programový import obsahu do služba Power BI. Nasadenie pomocou kanálov vydaní sa zvyčajne označuje ako nepretržité nasadenie (CD).
Položka 9. Správca vydaní riadi nasadenie na testovanie a produkciu pracovných priestorov pomocou schválenia vydania kanálov Azure. Pri publikovaní podnikového obsahu správca vydaní zvyčajne plánuje a koordinuje vydanie obsahu do testovacích a produkčných prostredí. Koordinujú a komunikujú s tvorcami obsahu, zainteresovanými stranami a používateľmi.
Položka 10. Kanál vydania publikuje obsah do vývojového pracovného priestoru alebo propaguje obsah z vývoja do testovacích pracovných priestorov alebo testuje do produkčných pracovných priestorov.
Položka 11. Tvorcovia obsahu pracujúci v pracovnom priestore, ktorý má režim licencie na kapacitu služby Fabric, môžu používať integráciu Git. S integráciou systému Git môžu tvorcovia obsahu pracovať počas vývoja v súkromnom pracovnom priestore. Tvorca obsahu synchronizuje vzdialenú vetvu (zvyčajne konkrétnu vetvu funkcie alebo vetvu chyby) zo služieb Azure Repos do svojho súkromného pracovného priestoru. Zmeny obsahu sa synchronizujú medzi vzdialenou vetvou v odkladacích priestoroch Azure a pracovnom priestore. V tomto scenári tvorcovia obsahu nemusia na publikovanie obsahu používať kanály Azure. Tvorcovia obsahu môžu tiež pravidelne potvrdiť a presúvať zmeny z pracovného priestoru po publikovaní. Keď je to pripravené, tvorcovia obsahu môžu požiadať o prijatie zmien (PR) na zlúčenie svojich zmien do hlavnej vetvy.
Položka 12. Keď používate integráciu systému Git, vývojársky pracovný priestor sa synchronizuje s hlavnou vetvou, aby sa získali najnovšie verzie obsahu. Tento obsah zahŕňa všetky zmeny zo žiadostí o prijatie zmien, ktoré správca vydaní skontroluje, schváli a zlúči.
Položka 13. Pracovné priestory sú nastavené na kapacitu služby Fabric, kapacitu Premium, Premium na používateľa alebo režim licencie Embedded, čím umožňujú používať kanály nasadenia Power BI a koncový bod XMLA na čítanie a zapisovanie.
Položka 14. Správca kanála nasadenia nastaví kanál nasadenia služby Power BI s tromi fázami: vývoj, testovanie a produkcia. Každá fáza sa zarovná k samostatnému pracovnému priestoru v služba Power BI. Nastavenia nasadenia a prístup sú nastavené pre kanál nasadenia.
Položka 15. Vývojový pracovný priestor obsahuje najnovšie verzie obsahu vrátane všetkých schválených a zlúčených zmien. Po schválení kanál vydania nasadzuje obsah z vývoja do testovacieho pracovného priestoru.
Položka 16. Posudzovatelia v rámci testovacieho pracovného priestoru vykonávajú testovanie a kontrolu kvality obsahu. Po schválení kanál vydania nasadí obsah z testu do produkčného pracovného priestoru. Keď používate integráciu systému Git s kanálmi nasadenia, testovací pracovný priestor sa nesynchronizuje so žiadnou vetvou.
Položka 17. Po dokončení nasadenia kanála nasadenia tvorcovia obsahu manuálne vykonávajú aktivity po nasadení. Aktivity môžu zahŕňať nastavenie plánovaného obnovenia údajov alebo aktualizáciu aplikácie služby Power BI pre produkčný pracovný priestor. Keď používate integráciu systému Git s kanálmi nasadenia, produkčný pracovný priestor sa nesynchronizuje so žiadnou vetvou.
Položka 18. Používatelia zobrazujúci obsah majú prístup k obsahu pomocou produkčného pracovného priestoru alebo aplikácie služby Power BI.

Tip

Odporúčame vám tiež prezrieť si scenáre používania samoobslužného obsahu a rozšírené scenáre používania správy dátových modelov. Scenár publikovania podnikového obsahu vychádza z konceptov, ktoré tieto scenáre predstavia.

Kľúčové body

Nižšie sú uvedené niektoré kľúčové body, ktoré treba zdôrazniť v scenári publikovania podnikového obsahu.

Správa verzií

Sledovanie zmien počas životného cyklu obsahu je dôležité na zabezpečenie stabilného a konzistentného doručovania obsahu spotrebiteľom. V tomto scenári používania tvorcovia obsahu a vlastníci spravujú zmeny obsahu vo vzdialenom odkladacom priestore pomocou ovládacieho prvku verzie. Správa verzií je praxou spravovania zmien súborov alebo kódu v centrálnom odkladacom priestore. Táto prax umožňuje lepšiu spoluprácu a efektívnu správu histórie verzií. Ovládanie verzií má pre tvorcov obsahu výhody vrátane možnosti vrátiť alebo zlúčiť zmeny.

Tvorcovia obsahu zvyčajne vyvíjajú dátové modely v nástroji Tabular Editor na podporu lepšej kontroly verzií. Na rozdiel od dátového modelu, ktorý vyvíjate v aplikácii Power BI Desktop, je dátový model vyvinutý v nástroji Tabular Editor uložený vo formáte metaúdajov čitateľnom ľuďmi. Tento formát umožňuje ovládanie verzií na úrovni objektu dátového modelu. Riadenie verzií na úrovni objektu by ste mali používať na spoluprácu s viacerými ľuďmi v tom istom dátovom modeli. Ďalšie informácie nájdete v scenári používania rozšírenej správy dátových modelov. Nie je možné zobraziť zmeny, ktoré ste vykonali v súbore Aplikácie Power BI Desktop (.pbix), ako je napríklad definícia zostavy alebo dátový model. Nemôžete napríklad sledovať zmeny strany zostavy, ako sú napríklad použité vizuály, ich pozície a priradenia polí či formátovanie.

Tvorcovia obsahu ukladajú súbory metaúdajov dátového modelu a súbory .pbix v centrálnom vzdialenom odkladacom priestore, ako sú napríklad odkladacie priestory Azure Repos. Tieto súbory spravuje technický vlastník. Zatiaľ čo tvorca obsahu vyvíja riešenie, technický vlastník je zodpovedný za spravovanie riešenia, kontrolu zmien a ich zlúčenie do jedného riešenia. Odkladacie priestory Azure Repos poskytujú sofistikované možnosti sledovania a správy zmien. Tento prístup je odlišný od prístupu popísaného v scenári samoobslužného publikovania obsahu, v ktorom tvorca používa ukladací priestor OneDrivu so sledovaním verzií. Udržiavanie správne spravovaného a zdokumentovaného odkladacieho priestoru je nevyhnutné, pretože je základom všetkého obsahu a spolupráce.

Tu je niekoľko kľúčových dôležitých informácií, ktoré vám pomôžu nastaviť vzdialený odkladací priestor na riadenie verzií.

  • Rozsah: Jasne definujte rozsah odkladacieho priestoru. V ideálnom prípade je rozsah odkladacieho priestoru rovnaký ako rozsah následných pracovných priestorov a aplikácií, ktoré používate na doručenie obsahu spotrebiteľom.
  • Prístup: Prístup do odkladacieho priestoru by ste mali nastaviť pomocou podobného modelu povolení, ako ste nastavili pre povolenia pre kanál nasadenia a roly pracovného priestoru. Tvorcovia obsahu potrebujú prístup do odkladacieho priestoru.
  • Dokumentácia: Pridajte do odkladacieho priestoru textové súbory na dokumentovanie jeho účelu, vlastníctva, prístupu a definovaných procesov. V dokumentácii môže byť napríklad popísané, ako je potrebné vykonať zmeny.
  • Nástroje: Na potvrdenie a presunutie zmien do vzdialeného odkladacieho priestoru tvorcovia obsahu potrebujú klienta Git, ako je napríklad Visual Studio alebo Visual Studio Code. Git je distribuovaný systém riadenia verzií, ktorý sleduje zmeny v súboroch. Ak sa chcete naučiť základy systému Git, pozrite si tému Čo je Git?.

Poznámka

Ak plánujete potvrdiť súbory aplikácie Power BI Desktop (.pbix), zvážte použitie Git Large File Storage (LFS ). Git LFS poskytuje rozšírené možnosti správy súborov, kde zmeny nie sú viditeľné (nerozlišovateľné súbory), ako je napríklad súbor .pbix. Môžete napríklad použiť zamykanie súborov, čím zabránite súbežným zmenám v zostave Power BI počas vývoja. Však Git LFS má svojho vlastného klienta a konfiguráciu.

Spolupráca so službou Azure DevOps

Keďže rozsah a zložitosť riešenia sa zväčšujú, môže byť potrebné, aby viacerí tvorcovia obsahu a vlastníci mohli pracovať v spolupráci. Tvorcovia a vlastníci obsahu komunikujú a spolupracujú v centrálnom organizovanom centre pomocou služby Azure DevOps.

Na spoluprácu a komunikáciu v službe Azure DevOps sa používa podporné služby.

  • Panely Azure: vlastníci obsahu používajú tabule na sledovanie pracovných položiek. Pracovné položky sú priradené jednému vývojárovi v tíme a popisujú problémy, chyby alebo funkcie v riešení a príslušné zainteresované strany.
  • Azure Wiki: Tvorcovia obsahu zdieľajú informácie so svojím tímom, aby porozumeli riešeniu a prispievali k nim.
  • Odkladacie priestory Azure: Tvorcovia obsahu sledujú zmeny vo vzdialenom odkladacom priestore a zlúčia ich do jedného riešenia.
  • Azure Pipelines: Vlastníci kanálov nastavia programovú logiku na nasadenie riešenia buď automaticky, alebo na požiadanie.

Diagram postupu spolupráce

Nasledujúci diagram znázorňuje prehľad vysokej úrovne jedného príkladu toho, ako služba Azure DevOps umožňuje spoluprácu v scenári používania publikovania podnikového obsahu. Tento diagram sa zameriava na používanie služby Azure DevOps na vytvorenie štruktúrovaného a zdokumentovaného procesu publikovania obsahu.

Diagram, ako je popísané v vyššie uvedenom odseku. Položky v diagrame sú popísané v tabuľke nižšie.

Diagram znázorňuje nasledujúce akcie, procesy a funkcie používateľa.

Položka Popis
Položka 1. Tvorca obsahu vytvorí novú vetu s krátkym životom naklonovaním hlavnej vetvy, ktorá obsahuje najnovšiu verziu obsahu. Nová vetva sa často označuje ako vetva funkcie , pretože sa používa na vývoj konkrétnej funkcie alebo na opravu konkrétneho problému.
Položka 2. Tvorca obsahu potvrdí svoje zmeny v lokálnom odkladacom priestore počas vývoja.
Položka 3. Tvorca obsahu prepojí svoje zmeny na pracovné položky, ktoré sa spravujú v Paneloch Azure. Works items (Funguje) popisujú konkrétny vývoj, vylepšenia alebo opravy chýb, ktoré sa týkajú ich vetvy.
Položka 4. Tvorca obsahu pravidelne potvrduje svoje zmeny. Keď je to pripravené, tvorca obsahu publikuje svoju vetvu do vzdialeného odkladacieho priestoru.
Položka 5. Na testovanie svojich zmien tvorca obsahu nasadí svoje riešenie do izolovaného pracovného priestoru na vývoj (nie je zobrazené v tomto diagrame). Tvorca obsahu môže tiež synchronizovať vetvu funkcie s pracovným priestorom pomocou integrácie Git služby Fabric.
Položka 6. Tvorcovia obsahu a vlastníci obsahu dokumentujú riešenie a jeho procesy v nástroji Azure Wiki, ktorý je k dispozícii celému vývojárskemu tímu.
Položka 7. Keď bude zostava obsahu pripravená, otvorí sa žiadosť o prijatie zmien na zlúčenie vetvy funkcie do hlavnej vetvy.
Položka 8. Technický vlastník je zodpovedný za kontrolu žiadosti o prijatie zmien a zlúčenie zmien. Po schválení žiadosti o prijatie zmien zlúčia vetvu funkcií do hlavnej vetvy.
Položka 9. Úspešné zlúčenie spustí nasadenie riešenia do vývojového pracovného priestoru pomocou kanála Azure (nie je zobrazené v tomto diagrame). Keď používate integráciu Git služby Fabric, hlavná vetva sa synchronizuje s pracovným priestorom vývoja.
Položka 10. Správca vydaní vykoná záverečnú kontrolu a schválenie riešenia. Toto schválenie vydania bráni publikovaniu riešenia ešte predtým, ako bude pripravené. Pri publikovaní podnikového obsahu správca vydaní zvyčajne plánuje a koordinuje vydanie obsahu do testovacích a produkčných pracovných priestorov. Koordinujú a komunikujú s tvorcami obsahu, zainteresovanými stranami a používateľmi.
Položka 11. Keď správca vydaní schváli vydanie, Azure Pipelines automaticky pripraví riešenie na nasadenie. Prípadne môže kanál Azure spustiť kanál nasadenia na podporu obsahu medzi pracovnými priestormi.
Položka 12. Používatelia testovať a overovať obsah v testovacom pracovnom priestore. Keď používate integráciu systému Git s kanálmi Azure Pipelines na nasadenie, testovací pracovný priestor sa nesynchronizuje so žiadnou vetvou.
Položka 13. Keď používatelia prijmú a overia zmeny, správca vydania vykoná záverečnú kontrolu a schválenie riešenia na nasadenie do produkčného pracovného priestoru.
Položka 14. Používatelia zobrazujú obsah publikovaný v produkčnom pracovnom priestore. Keď používate integráciu systému Git s kanálmi Azure Pipelines na nasadenie, produkčný pracovný priestor sa nesynchronizuje so žiadnou vetvou.

Spresnenie umožňuje tvorcom obsahu spolupráca pomocou stratégie vetvenia. Stratégia vetvenia predstavuje spôsob, akým tvorcovia obsahu vytvárajú, používajú a zlučujú vetvy, aby mohli efektívne vykonávať a spravovať zmeny obsahu. Jednotliví tvorcovia obsahu pracujú v lokálnom odkladacom priestore oddelene. Keď sú pripravené, skombinujú svoje zmeny ako jedno riešenie vo vzdialenom odkladacom priestore. Tvorcovia obsahu by mali obmedziť svoju prácu na vetvy tak, že ich prepoja s pracovnými položkami pre konkrétny vývoj, vylepšenia alebo opravy chýb. Každý tvorca obsahu vytvorí svoju vlastnú vetvu vzdialeného odkladacieho priestoru pre svoj rozsah práce. Práca na ich lokálnom riešení je odhodlaná a odoslaná do verzie vetvy vo vzdialenom odkladacom priestore s hlásením potvrdenia. Správa potvrdenia popisuje zmeny vykonané v tomto potvrdení.

Ak chcete zlúčiť zmeny, tvorca obsahu otvorí žiadosť o prijatie zmien. Žiadosť o prijatie zmien je odoslanie na partnerskú kontrolu, ktorá môže viesť k zlúčeniu práce vykonanej do jedného riešenia. Zlúčením sa môžu viesť konflikty, ktoré je potrebné vyriešiť pred zlúčením vetvy. Revízie žiadostí o prijatie zmien sú dôležité na zabezpečenie toho, aby tvorcovia dodržiavali štandardy a postupy organizácie týkajúce sa vývoja, kvality a dodržiavania súladu.

Odporúčania na spoluprácu

Odporúčame, aby ste definovali štruktúrovaný proces spolupráce tvorcov obsahu. Skontrolujte, či ste určili:

  • Ako sa pracuje a ako sa vytvárajú vetvy, pomenované a používané.
  • Ako sa autori v skupine menia a popisujú pomocou správ potvrdenia.
  • Kto je zodpovedný za preskúmanie a schvaľovanie žiadostí o prijatie zmien.
  • Ako sa riešia konflikty zlúčenia.
  • Spôsob zlučuje zmeny vykonané v rôznych vetvách do jednej vetvy.
  • Spôsob testovania obsahu a spôsob testovania pred nasadením obsahu.
  • Ako a kedy sa zmeny nasadzujú do vývojových, testovacích a produkčných pracovných priestorov.
  • Spôsob a kedy sa majú vrátiť zmeny alebo verzie riešenia.

Dôležité

Hodnota, ktorú poskytuje DevOps, je priamo úmerná dodržiavaniu procesov, ktoré definujú jej použitie.

Úspešná spolupráca závisí od presne definovaného procesu. Je dôležité jasne opísať a zdokumentovať pracovný postup vývoja od konca. Uistite sa, že vybraté stratégie a procesy sú v súlade s existujúcimi postupmi vo vašom tíme, a ak nie, ako budete spravovať zmeny. Okrem toho sa uistite, že procesy sú jasné a oznámené všetkým členom tímu a zúčastneným stranám. Uistite sa, že členovia tímu a účastníci projektu, ktorí sú novými procesmi, sú školení na to, ako ich prijať, a aby ocenili hodnotu úspešného prijatia DevOps.

Power BI REST API

Vyvíjate programovú logiku na import a nasadenie obsahu zo služby Azure DevOps pomocou rozhraní REST API služby Power BI. Súbory Power BI (.pbix) importujete do pracovného priestoru pomocou operácie importu. Pomocou operácie kanála môžete nasadiť nejaký obsah alebo všetok obsah do testovacích alebo produkčných pracovných priestorov pomocou kanálov nasadenia služby Power BI. Programová logika je definovaná v kanáloch Azure.

Odporúčame, aby ste vo vašich kanáloch zavolali rozhranie REST API služby Power BI pomocou objektu služby . Objekt služby je určený na automatické a automatizované aktivity a nespolieha sa na prihlasovacie údaje používateľa. Niektoré položky a aktivity však nie sú podporované rozhraniami REST API služby Power BI ani pri používaní objektu služby, ako sú napríklad toky údajov.

Keď používate objekt služby, nezabudnite starostlivo spravovať povolenia. Vaším cieľom by malo byť dodržovať zásadu najmenej oprávnení. Mali by ste pre objekt služby nastaviť dostatočné povolenia bez prílišného zriaďovania povolení. Použite službu Azure Key Vault alebo inú službu, ktorá bezpečne ukladá tajné kódy a prihlasovacie údaje objektov služby.

Výstraha

Ak máte dátový model, ktorý je uložený vo formáte metaúdajov čitateľnom ľuďmi, nemôže byť publikovaný pomocou rozhraní REST API služby Power BI. Namiesto toho ho musíte publikovať pomocou koncového bodu XMLA. Súbory metaúdajov môžete publikovať pomocou nástrojov tretích strán, ako je napríklad rozhranie príkazového riadka nástroja Tabular Editor (CLI). Súbory metaúdajov môžete publikovať aj pomocou programovania s použitím vlastného vývoja vlastných rozhraní .NET. Vývoj vlastného riešenia si vyžaduje viac úsilia, pretože musíte použiť rozšírenie Microsoft Tabular Object Model (TOM) klientskych knižníc Analysis Management Object (AMO).

Kanály Azure

Kanály Azure programovo automatizujú testovanie, správu a nasadenie obsahu. Po spustení kanála sa kroky v kanáli automaticky vykonávajú. Vlastníci kanála môžu prispôsobiť spúšťače, kroky a funkcie tak, aby spĺňali potreby nasadenia. Počet a typy kanálov sa preto líšia v závislosti od požiadaviek na riešenie. Kanál Azure môže napríklad pred nasadením spustiť automatizované testy alebo upraviť parametre dátového modelu.

Existujú tri typy kanálov Azure, ktoré môžete nastaviť na testovanie, spravovanie a nasadenie vášho riešenia služby Power BI:

  • Overovacie kanály.
  • Vytváranie kanálov.
  • Kanály vydania.

Poznámka

Nie je potrebné mať všetky tri tieto kanály vo vašom riešení publikovania. V závislosti od pracovného postupu a potrieb môžete nastaviť jeden alebo viac variantov kanálov popísaných v tomto článku na automatizáciu publikovania obsahu. Táto možnosť prispôsobiť kanály je výhodou kanálov Azure oproti vstavaným kanálom nasadenia služby Power BI. Nemusíte napríklad mať overovací kanál. Môžete používať iba kanály na vytváranie a vydávanie.

Overovacie kanály

Kanály overenia vykonávajú základné kontroly kvality dátových modelov pred ich publikovaním vo vývojovom pracovnom priestore. Zmeny vo vetve vzdialeného odkladacieho priestoru zvyčajne spustia kanál, aby sa tieto zmeny overili automatizovaným testovaním.

Príklady automatizovaného testovania zahŕňajú skenovanie dátového modelu s dôvodu porušenia pravidiel najvhodnejších postupov pomocou Analyzátora najvhodnejších postupov (BPA) alebo spúšťanie dotazov DAX na publikovanom sémantickom modeli. Výsledky týchto testov sa potom uložia do vzdialeného odkladacieho priestoru na účely dokumentácie a auditu. Dátové modely, ktoré zlyhajú overenie, by sa nemali publikovať. Namiesto toho by mal kanál informovať tvorcov obsahu o problémoch.

Vytváranie kanálov

Vytvárajte kanály, ktoré pripravujú dátové modely na publikovanie do služba Power BI. Tieto kanály kombinujú metaúdaje serializovaného modelu do jedného súboru, ktorý je neskôr publikovaný kanálom vydania (ako je popísané v diagrame kanály vydania). Kanál zostavy môže vykonať aj ďalšie zmeny metaúdajov, napríklad upraviť hodnoty parametrov. Kanály zostáv vytvárajú artefakty nasadenia pozostávajúce z metaúdajov dátového modelu (pre dátové modely) a zo súborov aplikácie Power BI Desktop (.pbix), ktoré sú pripravené na publikovanie do služba Power BI.

Kanály vydania

Kanály vydania publikujte alebo nasadzujte obsah. Publikovanie riešenia zvyčajne obsahuje niekoľko kanálov vydania v závislosti od cieľového prostredia.

  • Kanál vydania vývoja: Tento prvý kanál sa spustí automaticky. Publikuje obsah do vývojového pracovného priestoru po úspešnom úspechu kanálov vytvárania a overenia.
  • Testovacie a produkčné kanály vydaní: Tieto kanály sa nespustí automaticky. Namiesto toho sa spúšťajú na požiadanie alebo po schválení. Kanály testovacích a produkčných vydaní nasadzujú obsah do testovacieho alebo produkčného pracovného priestoru po schválení vydania. Schválenia vydania zaisťujú , že obsah sa automaticky nenasadí do testovacej alebo produkčnej fázy skôr, než bude pripravený. Tieto schválenia poskytujú správcovia vydaní, ktorí sú zodpovední za plánovanie a koordináciu vydania obsahu do testovacích a produkčných prostredí.

Existujú dva rôzne prístupy na publikovanie obsahu pomocou testovacích a release kanálov. Buď propagujú obsah pomocou kanála nasadenia služby Power BI, alebo publikujú obsah do služba Power BI zo služby Azure DevOps.

Nasledujúci diagram znázorňuje prvý prístup. V tomto prístupe kanály vydania zosúladzujú nasadenie obsahu do testovacích a produkčných pracovných priestorov pomocou kanálov nasadenia služby Power BI. Obsah sa propaguje prostredníctvom vývojových, testovacích a produkčných pracovných priestorov v službe Power BI. Hoci je tento prístup robustnejší a jednoduchší na údržbu, vyžaduje si licenciu Premium.

Diagram znázorňuje prvý prístup, ako je popísané vo vyššie uvedenom odseku. Položky v diagrame sú popísané v tabuľke nižšie.

Diagram znázorňuje nasledujúce akcie, procesy a funkcie prvého prístupu používateľa.

Položka Popis
Položka 1. V prvom postupe kanály vydania publikuujú obsah pomocou koncového bodu XMLA a rozhraní REST API služby Power BI s kanálmi nasadenia služby Power BI. Obsah sa publikuje a potom sa propaguje prostredníctvom pracovných priestorov vývoja, testovania a produkcie. Kanály nasadenia služby Power BI a koncový bod XMLA na čítanie a zapisovanie sú funkcie verzie Premium.
Položka 2. Úspešné zlúčenie vetvy alebo dokončenie upstreamového kanála spustí kanál zostavy. Kanál zostavy potom pripraví obsah na publikovanie a spustí kanál vydania vývoja.
Položka 3. Kanál vydania vývoja publikuje obsah do vývojového pracovného priestoru pomocou koncového bodu XMLA (pre metaúdaje dátového modelu) alebo rozhraní REST API služby Power BI (pre súbory aplikácie Power BI Desktop, ktoré môžu obsahovať dátové modely a zostavy). Kanál vývoja používa rozhranie príkazového riadka nástroja Tabular Editor (CLI) na nasadenie metaúdajov dátového modelu pomocou koncového bodu XMLA.
Položka 4. Spúšťač schválenia vydania alebo spúšťač na požiadanie aktivuje kanál testovacieho vydania.
Položka 5. Kanál testovacieho vydania nasadzuje obsah pomocou operácií nasadenia rozhrania REST API služby Power BI, ktoré spúšťajú kanál nasadenia služby Power BI.
Položka 6. Kanál nasadenia služby Power BI propaguje obsah z vývojového pracovného priestoru do testovacieho pracovného priestoru. Po nasadení kanál vydania vykonáva aktivity po nasadení pomocou rozhraní REST API služby Power BI (nie sú zobrazené v diagrame).
Položka 7. Spúšťač schválenie vydania alebo spúšťač na požiadanie aktivuje kanál produkčného vydania.
Položka 8. Kanál produkčného vydania nasadzuje obsah pomocou operácií nasadenia rozhrania REST API služby Power BI, ktoré riadia kanál nasadenia služby Power BI.
Položka 9. Kanál nasadenia služby Power BI propaguje obsah z testovacieho pracovného priestoru do produkčného pracovného priestoru. Po nasadení kanál vydania vykonáva aktivity po nasadení pomocou rozhraní REST API služby Power BI (nie sú zobrazené v diagrame).

Nasledujúci diagram znázorňuje druhý prístup. Tento prístup nepoužíva kanály nasadenia. Namiesto toho používa kanály vydania na publikovanie obsahu na testovanie a produkciu pracovných priestorov zo služby Azure DevOps. Tento druhý prístup nevyžaduje licencovanie premium, keď publikujete iba súbory Power BI Desktop s rozhraniami Power BI REST API. Vyžaduje to však väčšiu snahu o nastavenie a zložitosť, pretože je potrebné spravovať nasadenie mimo služby Power BI. Vývojové tímy, ktoré už používajú DevOps pre údajové riešenia mimo služby Power BI, môžu byť s týmto prístupom lepšie oboznámení. Vývojové tímy, ktoré používajú tento prístup, môžu konsolidovať nasadenie údajových riešení v službe Azure DevOps.

Diagram znázorňuje druhý prístup, ako je popísané v vyššie uvedenom odseku. Položky v diagrame sú popísané v tabuľke nižšie.

Diagram znázorňuje v druhom prístupe nasledujúce akcie, procesy a funkcie používateľa.

Položka Popis
Položka 1. V druhom prístupe kanály vydania publikuujú obsah pomocou koncového bodu XMLA a len rozhraní REST API služby Power BI. Obsah je publikovaný v pracovných priestoroch vývoja, testovania a produkcie.
Položka 2. Úspešné zlúčenie vetvy alebo dokončenie upstreamového kanála spustí kanál zostavy. Kanál zostavy potom pripraví obsah na publikovanie a spustí kanál vydania vývoja.
Položka 3. Kanál vydania vývoja publikuje obsah do vývojového pracovného priestoru pomocou koncového bodu XMLA (pre metaúdaje dátového modelu) alebo rozhraní REST API služby Power BI (pre súbory aplikácie Power BI Desktop, ktoré môžu obsahovať dátové modely a zostavy). Kanál vývoja používa rozhranie príkazového riadka nástroja Tabular Editor (CLI) na nasadenie metaúdajov dátového modelu pomocou koncového bodu XMLA.
Položka 4. Spúšťač schválenia vydania alebo spúšťač na požiadanie aktivuje kanál testovacieho vydania.
Položka 5. Kanál vydania vývoja publikuje obsah do testovacieho pracovného priestoru pomocou koncového bodu XMLA (pre metaúdaje dátového modelu) alebo rozhraní REST API služby Power BI (pre súbory aplikácie Power BI Desktop, ktoré môžu obsahovať dátové modely a zostavy). Kanál vývoja používa rozhranie príkazového riadka nástroja Tabular Editor (CLI) na nasadenie metaúdajov dátového modelu pomocou koncového bodu XMLA. Po nasadení kanál vydania vykonáva aktivity po nasadení pomocou rozhraní REST API služby Power BI (nie sú zobrazené v diagrame).
Položka 6. Spúšťač schválenie vydania alebo spúšťač na požiadanie aktivuje kanál produkčného vydania.
Položka 7. Kanál vydania vývoja publikuje obsah do produkčného pracovného priestoru pomocou koncového bodu XMLA (pre metaúdaje dátového modelu) alebo rozhraní REST API služby Power BI (pre súbory aplikácie Power BI Desktop, ktoré môžu obsahovať dátové modely a zostavy). Kanál vývoja používa rozhranie príkazového riadka nástroja Tabular Editor (CLI) na nasadenie metaúdajov dátového modelu pomocou koncového bodu XMLA. Po nasadení kanál vydania vykonáva aktivity po nasadení pomocou rozhraní REST API služby Power BI (nie sú zobrazené v diagrame).

Kanály vydania by mali spravovať aktivity po nasadení. Tieto aktivity môžu zahŕňať nastavenie sémantických poverení modelu alebo aktualizáciu aplikácie Power BI pre testovacie a produkčné pracovné priestory. Odporúčame, aby ste nastavili oznámenia s cieľom informovať relevantných ľudí o aktivitách nasadenia.

Tip

Používanie odkladacieho priestoru na riadenie verzií umožňuje tvorcom obsahu vytvoriť proces vrátenia zmien. Proces vrátenia zmien môže vrátiť posledné nasadenie obnovením predchádzajúcej verzie. Zvážte vytvorenie samostatnej množiny kanálov Azure, ktorú môžete spustiť, aby ste vrátili produkčné zmeny. Dôkladne premyslite, aké procesy a schválenia sú potrebné na spustenie vrátenia zmien. Skontrolujte, či sú tieto procesy zdokumentované.

Kanály nasadenia Power BI

Kanál nasadenia služby Power BI sa skladá z troch fáz: vývoj, testovanie a produkcia. Ku každej fáze v kanáli nasadenia priradíte jeden pracovný priestor služby Power BI. Keď nastane nasadenie, kanál nasadenia podporuje položky služby Power BI z jedného pracovného priestoru do druhého.

Kanál vydania kanálov Azure využíva rozhrania REST API služby Power BI na nasadenie obsahu pomocou kanála nasadenia služby Power BI. Používatelia, ktorí vykonávajú nasadenie, potrebujú prístup k pracovnému priestoru aj kanálu nasadenia. Odporúčame naplánovať prístup ku kanálu nasadenia, aby používatelia kanála mohli zobraziť históriu nasadenia a porovnať obsah.

Tip

Keď oddelíte pracovné priestory údajov od pracovných priestorov zostáv, zvážte použitie kanálov Azure na koordinovanie publikovania obsahu s viacerými kanálmi nasadenia služby Power BI. Sémantický model sa nasadí ako prvý a potom sa obnoví. Napokon sú zostavy nasadené. Tento prístup vám pomôže zjednodušiť nasadenie.

Licencovanie Premium

Kanály nasadenia služby Power BI a koncový bod XMLA na čítanie a zapisovanie sú funkcie verzie Premium. Tieto funkcie sú k dispozícii v kapacite Premium služby Power BI a službe Power BI Premium na používateľa.

Premium na používateľa je nákladovo efektívny spôsob spravovania podnikového obsahu na vývoj a testovanie pracovných priestorov, ktoré majú zvyčajne málo používateľov. Tento prístup má pridanú výhodu izolovania vývojových a testovacích úloh z produkčných vyťažení.

Poznámka

Naďalej môžete nastaviť publikovanie podnikového obsahu bez licencie Premium, ako je to popísané v druhom postupe v časti Kanál vydania. V druhom prístupe môžete pomocou kanálov Azure spravovať nasadenie súborov aplikácie Power BI Desktop do vývojových, testovacích a produkčných pracovných priestorov. Nie je však možné nasadiť metaúdaje modelu pomocou koncového bodu XMLA, pretože nie je možné publikovať sémantický model formátu metaúdajov pomocou rozhraní REST API služby Power BI. Takisto nie je možné propagovať obsah prostredníctvom prostredí s kanálmi nasadenia bez licencie Premium.

Nastavenie brány

Brána údajov sa zvyčajne vyžaduje pri prístupe k zdrojom údajov, ktoré sa nachádzajú v súkromnej sieti organizácie alebo virtuálnej sieti. Brána má dva účely obnovovať importované údaje a zobraziť zostavu, ktorá dotazuje dynamické pripojenie alebo sémantický model DirectQuery (nie je znázornený v diagrame scenára).

Pri práci s viacerými prostrediami sa bežne nastavujú vývojové, testovacie a produkčné pripojenia k rôznym zdrojovým systémom. V tomto prípade môžete pomocou pravidiel zdroja údajov a pravidiel parametrov spravovať hodnoty, ktoré sa medzi prostrediami líšia. Pomocou kanálov Azure môžete spravovať brány pomocou operácií brán rozhraní REST API služby Power BI.

Poznámka

Centralizovaná brána údajov v štandardnom režime sa dôrazne odporúča v prípade brán v osobnom režime. V štandardnom režime podporuje brána údajov operácie dynamického pripojenia a režim DirectQuery (okrem plánovaných operácií obnovenia údajov).

Dohľad nad systémom

Denník aktivity zaznamenáva udalosti, ktoré sa vyskytujú v služba Power BI. Správcovia služby Power BI môžu pomocou denníka aktivity auditovať aktivity nasadenia.

Na vytvorenie súpisu nájomníkov môžete použiť rozhrania API na skenovanie metaúdajov v službe Power BI. Výsledky rozhrania API sú užitočné na overenie toho, ktoré položky boli nasadené do každého pracovného priestoru, kontrolu pôvodu a overenie nastavení zabezpečenia.

K dispozícii je aj denník auditu v rámci služby Azure DevOps, ktorá je mimo služba Power BI. Správcovia Azure DevOps môžu pomocou denníka auditu kontrolovať aktivity vo vzdialených odkladacích priestoroch a kanáloch.

Ďalšie užitočné scenáre, ktoré vám pomôžu pri rozhodnutiach o implementácii služby Power BI, nájdete v článku Scenáre používania služby Power BI.