Scénáře použití Power BI: Publikování podnikového obsahu

  • Článek

Poznámka:

Tento článek je součástí řady článků o plánování implementace Power BI. Tato série se zaměřuje především na úlohy Power BI v Rámci Microsoft Fabric. Úvod do série najdete v tématu Plánování implementace Power BI.

Když tvůrci obsahu spolupracují na poskytování analytických řešení, která jsou pro organizaci důležitá, musí zajistit včasné a spolehlivé doručování obsahu příjemcům. Technické týmy tuto výzvu řeší pomocí procesu označovaného jako DevOps. DevOps umožňuje týmům automatizovat a škálovat procesy přijetím postupů, které zlepšují a urychlují doručování.

Poznámka:

Datové týmy, které řeší stejné výzvy, můžou také procvičovat DataOps. DataOps vychází z principů DevOps, ale DataOps zahrnuje další postupy specifické pro správu dat, jako je kontrola kvality dat a zásady správného řízení. V tomto článku se odkazujeme na DevOps, ale mějte na paměti, že základní principy se můžou vztahovat i na DataOps.

Tvůrci obsahu a spotřebitelé získají při publikování obsahu Power BI několik výhod z několika výhod. Následující body představují obecný přehled toho, jak tento proces funguje.

  1. Vývoj obsahu a potvrzení práce do vzdáleného úložiště: Tvůrci obsahu vyvíjejí své řešení na vlastním počítači. Potvrdí a uloží svou práci do vzdáleného úložiště v pravidelných intervalech během vývoje. Vzdálené úložiště obsahuje nejnovější verzi řešení a je přístupné celému vývojovému týmu.
  2. Spolupráce a správa změn obsahu pomocí správy verzí: Jiní tvůrci obsahu můžou provádět revize řešení vytvořením větve. Větev je kopie vzdáleného úložiště. Jakmile jsou tyto revize připravené a schválené, větev se sloučí s nejnovější verzí řešení. Všechny revize řešení se sledují. Tento proces se označuje jako správa verzí (nebo správa zdrojového kódu).
  3. Nasazení a zvýšení úrovně obsahu pomocí kanálů: Ve scénáři použití samoobslužného publikování obsahu se obsah propaguje (nebo nasazuje) prostřednictvím kanálů nasazení Power BI pro vývoj, testování a produkční prostředí. Kanály nasazení Power BI můžou ručně propagovat obsah do pracovních prostorů Power BI Premium pomocí uživatelského rozhraní nebo programově pomocí rozhraní REST API. Naproti tomu publikování podnikového obsahu (zaměření tohoto scénáře použití) podporuje obsah pomocí Azure Pipelines. Azure Pipelines je služba Azure DevOps, která automatizuje testování, správu a nasazení obsahu pomocí řady přizpůsobených programových kroků. Ve scénáři využití publikování podnikového obsahu se tyto kanály dají také označovat jako kanály kontinuální integrace a nasazování (nebo CI/CD). Tyto kanály často a automaticky integrují změny a zjednodušují publikování obsahu.

Důležité

Někdy se tento článek týká Power BI Premium nebo jejích předplatných kapacity (SKU P). Mějte na paměti, že Microsoft v současné době konsoliduje možnosti nákupu a vyřazuje Power BI Premium na skladové položky kapacity. Místo toho by měli noví a stávající zákazníci zvážit nákup předplatných kapacity Fabric (SKU F).

Další informace najdete v tématu Důležité aktualizace týkající se licencování Power BI Premium a nejčastějších dotazů k Power BI Premium.

DevOps podporuje vyspělý, systematický přístup ke správě obsahu a publikování. Umožňuje tvůrcům obsahu spolupracovat na řešeních a zajišťuje rychlé a spolehlivé doručování obsahu uživatelům. Když dodržujete postupy DevOps, získáte výhody zefektivněných pracovních postupů, menšího počtu chyb a vylepšených prostředí pro tvůrce obsahu a uživatele obsahu.

Postupy DevOps pro vaše řešení Power BI můžete nastavit a spravovat pomocí Azure DevOps. V podnikových scénářích můžete automatizovat publikování obsahu pomocí Azure DevOps a rozhraní REST API Power BI třemi různými způsoby.

  • Rozhraní REST API Power BI s kanály nasazení Power BI: Obsah můžete importovat do vývojových pracovních prostorů a pomocí kanálů nasazení nasazovat obsah prostřednictvím testovacích a produkčních pracovních prostorů. Stále řídíte nasazení z Azure DevOps a pomocí rozhraní REST API Power BI můžete spravovat kanály nasazení místo jednotlivých položek obsahu. Kromě toho pomocí koncového bodu XMLA nasadíte metadata datového modelu místo souboru Power BI Desktopu (.pbix) s Azure DevOps. Tato metadata umožňují sledovat změny na úrovni objektu pomocí správy verzí. I když je tento přístup robustnější a jednodušší, vyžaduje licencování Premium a středně náročné skriptování k nastavení importu a nasazení obsahu pomocí rozhraní REST API Power BI. Tento přístup použijte, pokud chcete zjednodušit správu životního cyklu obsahu pomocí kanálů nasazení a máte licenci Premium. Koncové body XMLA a kanály nasazení Power BI jsou funkce Premium.
  • Rozhraní REST API Power BI: Obsah můžete také importovat do vývojových, testovacích a produkčních pracovních prostorů pomocí Azure DevOps a pouze rozhraní REST API Power BI. Tento přístup nevyžaduje licencování Premium, ale zahrnuje vysoké úsilí skriptování a nastavení, protože nasazení se spravuje mimo Power BI. Tento přístup použijte, když chcete obsah Power BI nasadit centrálně z Azure DevOps nebo pokud nemáte licenci Premium. Vizuální porovnání mezi prvními dvěma přístupy najdete v diagramu toku přístupů kanálu verze.
  • Nástroje pro automatizaci Power BI s kanály nasazení Power BI: Ke správě kanálů nasazení místo rozhraní REST API Power BI můžete použít rozšíření Nástroje pro automatizaci Power BI Azure DevOps. Tento přístup je alternativou k první možnosti, která používá rozhraní REST API Power BI s kanály nasazení Power BI. Rozšíření nástrojů pro automatizaci Power BI je opensourcový nástroj. Pomáhá spravovat a publikovat obsah z Azure DevOps bez nutnosti psát skripty PowerShellu. Tento přístup použijte, když chcete spravovat kanály nasazení z Azure DevOps s minimálním úsilím skriptování a máte kapacitu Premium.

Tento článek se zaměřuje na první možnost, která používá rozhraní REST API Power BI s kanály nasazení Power BI. Popisuje, jak můžete pomocí Azure DevOps nastavit postupy DevOps. Popisuje také, jak můžete azure Repos používat pro vzdálená úložiště a automatizovat testování, integraci a doručování obsahu pomocí Azure Pipelines. Azure DevOps není jediný způsob, jak nastavit publikování podnikového obsahu, ale jednoduchá integrace s Power BI je dobrou volbou.

Poznámka:

Tento scénář použití je jedním ze scénářů správy obsahu a nasazení . V zájmu stručnosti se v tomto článku nezabýváme některými aspekty popsanými v tématu věnovaném spolupráci a doručování obsahu. Úplné pokrytí si nejprve přečtěte v těchto článcích.

Tip

Microsoft Fabric nabízí další možnosti publikování podnikového obsahu pomocí integrace Gitu s prostředky infrastruktury. Integrace Gitu umožňuje propojit pracovní prostor Prostředků infrastruktury s větví ve vzdáleném úložišti Azure Repos. Obsah uložený v této větvi se automaticky synchronizuje s pracovním prostorem, jako by byl tento obsah publikován do pracovního prostoru. Tvůrci obsahu naopak můžou potvrdit a odeslat změny z pracovního prostoru Prostředků infrastruktury do vzdáleného úložiště.

Integrace Gitu může zjednodušit spolupráci a publikování obsahu, ale vyžaduje větší plánování používání pracovních prostorů Fabric a strategie větvení. Další informace o tom, jak můžete nastavit a používat integraci s Prostředky infrastruktury Git, najdete v tématu Začínáme s integrací Gitu nebo kurzem: Kompletní správa životního cyklu.

Diagram scénáře

Následující diagram znázorňuje základní přehled nejběžnějších uživatelských akcí a komponent Power BI, které podporují publikování podnikového obsahu. Zaměřuje se na použití Azure DevOps ke správě a publikování obsahu programově prostřednictvím vývojových, testovacích a produkčních pracovních prostorů v služba Power BI.

Diagram znázorňuje publikování podnikového obsahu, což je vylepšení spolupráce a správy obsahu ve velkém měřítku pomocí Azure DevOps. Položky v diagramu jsou popsány v tabulce.

Tip

Diagram scénáře doporučujeme stáhnout, pokud ho chcete vložit do prezentace, dokumentace nebo blogového příspěvku – nebo ho vytisknout jako plakát na zdi. Vzhledem k tomu, že se jedná o obrázek SVG (Scalable Vector Graphics), můžete ho škálovat nahoru nebo dolů bez ztráty kvality.

Diagram scénáře znázorňuje následující akce, procesy a funkce uživatelů.

Položka Popis
Položka 1. Tvůrci obsahu vyvíjejí datové modely pomocí Power BI Desktopu nebo tabulkového editoru a vyvíjejí sestavy pomocí Power BI Desktopu. Tvůrci obsahu během vývoje ukládají svou práci do místního úložiště.
Položka 2. Tvůrci obsahu můžou naklonovat vzdálené úložiště, aby získali místní kopii tohoto obsahu.
Položka 3. Některé zdroje dat můžou vyžadovat místní bránu dat nebo bránu virtuální sítě pro aktualizaci dat, například ty, které se nacházejí v privátní síti organizace.
Položka 4. Tvůrci obsahu se během vývoje pravidelně zavádějí a odsílají své změny do vzdáleného úložiště pomocí klienta Gitu, jako je Visual Studio Code. V diagramu je vzdálené úložiště Azure Repos.
Položka 5. Jiní tvůrci obsahu používají Azure Repos ke sledování změn pomocí správy verzí. Spolupracují tím, že potvrdí změny do samostatných větví.
Položka 6. Změny obsahu ve vzdáleném úložišti aktivují Azure Pipelines. Ověřovací kanál je první aktivovaný kanál. Kanál ověření provádí automatizované testy k ověření obsahu před publikováním.
Položka 7. Obsah, který předá ověřovací kanál, aktivuje další kanál buildu. Kanál buildu připraví obsah pro publikování do služba Power BI. Proces až do tohoto bodu se obvykle označuje jako kontinuální integrace (CI).
Položka 8. Obsah se publikuje a nasazuje pomocí kanálů verzí. Kanály verze používají rozhraní REST API Power BI nebo koncový bod XMLA pracovního prostoru k programovému importu obsahu do služba Power BI. Nasazení pomocí kanálů verze se obvykle označuje jako průběžné nasazování (CD).
Položka 9. Správce verzí řídí nasazení do testovacích a produkčních pracovních prostorů pomocí schválení verze Azure Pipelines. V publikování podnikového obsahu správce verzí obvykle plánuje a koordinuje vydání obsahu do testovacího a produkčního prostředí. Koordinují a komunikují s tvůrci obsahu, zúčastněnými stranami a uživateli.
Položka 10. Kanál verze publikuje obsah do vývojového pracovního prostoru nebo podporuje obsah z vývoje do testovacích pracovních prostorů nebo do produkčních pracovních prostorů.
Položka 11. Tvůrci obsahu pracující v pracovním prostoru, který má režim licence kapacity Fabric, můžou používat integraci Gitu. S integrací Gitu můžou tvůrci obsahu během vývoje pracovat v privátním pracovním prostoru. Tvůrce obsahu synchronizuje vzdálenou větev (obvykle konkrétní větev funkcí nebo větev chyby) z Azure Repos do svého privátního pracovního prostoru. Změny obsahu se synchronizují mezi vzdálenou větví v Azure Repos a pracovním prostorem. V tomto scénáři nemusí tvůrci obsahu k publikování obsahu používat Azure Pipelines. Tvůrci obsahu také můžou po publikování pravidelně potvrzovat a nasdílovat změny z pracovního prostoru. Až budou připravení, můžou tvůrci obsahu vytvořit žádost o přijetí změn ( PR), aby sloučili své změny do hlavní větve.
Položka 12. Při použití integrace Gitu se vývojový pracovní prostor synchronizuje s hlavní větví, aby získal nejnovější verze obsahu. Tento obsah zahrnuje všechny změny z žádostí o přijetí změn, které správce verzí zkontroluje, schválí a sloučí.
Položka 13. Pracovní prostory jsou nastavené na kapacitu Fabric, kapacitu Premium, Premium na uživatele nebo režim licence Embedded, aby bylo možné používat kanály nasazení Power BI a koncový bod XMLA pro čtení a zápis.
Položka 14. Správce kanálu nasazení nastaví kanál nasazení Power BI se třemi fázemi: vývoj, testování a produkční prostředí. Každá fáze odpovídá samostatnému pracovnímu prostoru v služba Power BI. Nastavení nasazení a přístup jsou nastavené pro kanál nasazení.
Položka 15. Pracovní prostor pro vývoj obsahuje nejnovější verze obsahu, včetně všech schválených a sloučených změn. Po schválení kanál verze nasadí obsah z vývoje do testovacího pracovního prostoru.
Položka 16. Kontroloři v testovacím pracovním prostoru provádějí testování a kontrolu kvality obsahu. Po schválení kanál verze nasadí obsah z testu do produkčního pracovního prostoru. Při použití integrace Gitu s kanály nasazení se testovací pracovní prostor nesynchronizuje s žádnou větví.
Položka 17. Jakmile kanál nasazení dokončí nasazení, tvůrci obsahu ručně provádějí aktivity po nasazení. Aktivity můžou zahrnovat nastavení plánované aktualizace dat nebo aktualizaci aplikace Power BI pro produkční pracovní prostor. Při použití integrace Gitu s kanály nasazení se produkční pracovní prostor nesynchronizuje s žádnou větví.
Položka 18. Čtenáři obsahu přistupují k obsahu pomocí produkčního pracovního prostoru nebo aplikace Power BI.

Tip

Doporučujeme také zkontrolovat samoobslužné publikování obsahu a pokročilé scénáře použití správy datových modelů. Scénář využití publikování podnikového obsahu vychází z konceptů, které tyto scénáře představují.

Klíčové body

Tady je několik klíčových bodů, které je potřeba zdůraznit ve scénáři publikování podnikového obsahu.

Správa verzí

Sledování změn během životního cyklu obsahu je důležité k zajištění stabilního a konzistentního doručování obsahu příjemcům. V tomto scénáři použití spravují tvůrci obsahu a vlastníci změny obsahu ve vzdáleném úložišti pomocí správy verzí. Správa verzí je postup správy změn souborů nebo kódu v centrálním úložišti. Tento postup umožňuje lepší spolupráci a efektivní správu historie verzí. Správa verzí má výhody pro tvůrce obsahu, včetně možnosti vrácení změn zpět nebo sloučení změn.

Tvůrci obsahu obvykle vyvíjejí datové modely v tabulkovém editoru, aby podporovali lepší správu verzí. Na rozdíl od datového modelu, který vyvíjíte v Power BI Desktopu, se datový model vyvinutý v tabulkovém editoru ukládá ve formátu metadat čitelných pro člověka. Tento formát umožňuje správu verzí na úrovni objektu datového modelu. Při spolupráci s více lidmi na stejném datovém modelu byste měli použít správu verzí na úrovni objektu. Další informace najdete v pokročilém scénáři použití správy datového modelu. Změny provedené v souboru Power BI Desktopu (.pbix), jako je definice sestavy nebo datový model, není možné zobrazit. Například nemůžete sledovat změny stránky sestavy, jako jsou použité vizuály, jejich pozice a mapování polí nebo formátování.

Tvůrci obsahu ukládají soubory metadat datového modelu a soubory .pbix v centrálním vzdáleném úložišti, jako je Azure Repos. Tyto soubory kurátoruje technický vlastník. Zatímco tvůrce obsahu vyvíjí řešení, technický vlastník zodpovídá za správu řešení a kontrolu změn a jejich sloučení do jednoho řešení. Azure Repos nabízí sofistikované možnosti pro sledování a správu změn. Tento přístup se liší od přístupu popsaného ve scénáři použití samoobslužného publikování obsahu, kdy tvůrce používá úložiště OneDrivu se sledováním verzí. Udržování dobře kurátorovaného a zdokumentovaného úložiště je nezbytné, protože je základem veškerého obsahu a spolupráce.

Tady je několik klíčových aspektů, které vám pomůžou nastavit vzdálené úložiště pro správu verzí.

  • Rozsah: Jasně definujte rozsah úložiště. V ideálním případě je rozsah úložiště shodný s rozsahem podřízených pracovních prostorů a aplikací, které používáte k doručování obsahu příjemcům.
  • Přístup: Měli byste nastavit přístup k úložišti pomocí podobného modelu oprávnění, jako jste nastavili pro oprávnění kanálu nasazení a role pracovního prostoru. Tvůrci obsahu potřebují přístup k úložišti.
  • Dokumentace: Přidejte do úložiště textové soubory, které dokumentuje jeho účel, vlastnictví, přístup a definované procesy. Dokumentace může například popsat, jak by se změny měly připravit a potvrdit.
  • Nástroje: K potvrzení a nasdílení změn do vzdáleného úložiště potřebují tvůrci obsahu klienta Gitu , jako je Visual Studio nebo Visual Studio Code. Git je distribuovaný systém správy verzí, který sleduje změny ve vašich souborech. Základní informace o Gitu najdete v tématu Co je Git?.

Poznámka:

Pokud plánujete potvrdit soubory Power BI Desktopu (.pbix), zvažte použití úložiště Git Large File Storage (LFS). Git LFS poskytuje pokročilé možnosti pro správu souborů, kde nejsou viditelné změny (soubory, které se nedají zobrazit), jako je soubor .pbix. Pomocí uzamčení souborů můžete například zabránit souběžným změnám sestavy Power BI během vývoje. Git LFS má ale vlastního klienta a konfiguraci.

Spolupráce s Azure DevOps

S rostoucím rozsahem a složitostí řešení může být nutné, aby ve spolupráci spolupracovalo více tvůrců obsahu a vlastníků. Tvůrci obsahu a vlastníci komunikují a spolupracují v centrálním uspořádaném centru pomocí Azure DevOps.

Ke spolupráci a komunikaci v Azure DevOps používáte podpůrné služby.

  • Azure Boards: Vlastníci obsahu používají panely ke sledování pracovních položek. Pracovní položky jsou přiřazené jednomu vývojáři v týmu a popisují problémy, chyby nebo funkce v řešení a odpovídající zúčastněné strany.
  • Azure Wiki: Tvůrci obsahu sdílejí informace se svým týmem, aby pochopili a přispěli k řešení.
  • Azure Repos: Tvůrci obsahu sledují změny ve vzdáleném úložišti a sloučí je do jednoho řešení.
  • Azure Pipelines: Vlastníci kanálů nastavují programovou logiku pro nasazení řešení, a to buď automaticky, nebo na vyžádání.

Diagram toku spolupráce

Následující diagram znázorňuje základní přehled jednoho příkladu toho, jak Azure DevOps umožňuje spolupráci ve scénáři využití publikování podnikového obsahu. Tento diagram se zaměřuje na použití Azure DevOps k vytvoření strukturovaného a zdokumentovaného procesu publikování obsahu.

Diagram, jak je popsáno v předchozím odstavci Položky v diagramu jsou popsány v následující tabulce.

Diagram znázorňuje následující akce, procesy a funkce uživatelů.

Položka Popis
Položka 1. Tvůrce obsahu vytvoří novou krátkodobou větev klonováním hlavní větve, která obsahuje nejnovější verzi obsahu. Nová větev se často označuje jako větev funkcí , protože se používá k vývoji konkrétní funkce nebo k opravě konkrétního problému.
Položka 2. Tvůrce obsahu potvrdí své změny do místního úložiště během vývoje.
Položka 3. Tvůrce obsahu propojuje své změny s pracovními položkami spravovanými v Azure Boards. Položky práce popisují konkrétní vývoj, vylepšení nebo opravy chyb omezené na jejich větev.
Položka 4. Tvůrce obsahu pravidelně potvrdí své změny. Jakmile je tvůrce obsahu připravený, publikuje svou větev do vzdáleného úložiště.
Položka 5. Tvůrce obsahu nasadí své řešení do izolovaného pracovního prostoru pro vývoj (nezobrazuje se v tomto diagramu). Tvůrce obsahu může také synchronizovat větev funkce s pracovním prostorem pomocí integrace Gitu s prostředky infrastruktury.
Položka 6. Tvůrci obsahu a vlastníci obsahu dokumentují řešení a jeho procesy na wikiwebu Azure, který je dostupný pro celý vývojový tým.
Položka 7. Jakmile je tvůrce obsahu připravený, otevře žádost o přijetí změn, která větev funkce sloučí do hlavní větve.
Položka 8. Technický vlastník zodpovídá za kontrolu žádosti o přijetí změn a slučování změn. Když žádost o přijetí změn schválí, sloučí větev funkce do hlavní větve.
Položka 9. Úspěšné sloučení aktivuje nasazení řešení do vývojového pracovního prostoru pomocí kanálu Azure (nezobrazuje se v tomto diagramu). Při použití integrace Gitu s prostředky infrastruktury se hlavní větev synchronizuje s pracovním prostorem pro vývoj.
Položka 10. Správce verzí provede konečnou kontrolu a schválení řešení. Schválení této verze zabrání publikování řešení dříve, než bude připravené. V publikování podnikového obsahu správce verzí obvykle plánuje a koordinuje vydání obsahu do testovacích a produkčních pracovních prostorů. Koordinují a komunikují s tvůrci obsahu, zúčastněnými stranami a uživateli.
Položka 11. Když správce verzí verzi schválí, Azure Pipelines automaticky připraví řešení pro nasazení. Kanál Azure Může také aktivovat kanál nasazení, který zvýší úroveň obsahu mezi pracovními prostory.
Položka 12. Uživatelé testují a ověřují obsah v testovacím pracovním prostoru. Při použití integrace Gitu se službou Azure Pipelines pro nasazení se testovací pracovní prostor nesynchronizuje s žádnou větví.
Položka 13. Jakmile uživatelé přijmou a ověří změny, správce verzí provede konečnou kontrolu a schválení řešení, které se nasadí do produkčního pracovního prostoru.
Položka 14. Uživatelé zobrazí obsah publikovaný v produkčním pracovním prostoru. Při použití integrace Gitu s Azure Pipelines pro nasazení se produkční pracovní prostor nesynchronizuje s žádnou větví.

Aby tvůrci obsahu mohli vypracovat spolupráci pomocí strategie větvení. Strategie větvení je způsob, jakým tvůrci obsahu vytvářejí, používají a slučují větve, aby mohli efektivně provádět a spravovat změny obsahu. Jednotliví tvůrci obsahu pracují izolovaně v místním úložišti. Až budou připravení, zkombinují své změny jako jediné řešení ve vzdáleném úložišti. Tvůrci obsahu by měli svou práci vymezit na větve tím, že je propojí s pracovními položkami pro konkrétní vývoj, vylepšení nebo opravy chyb. Každý tvůrce obsahu vytvoří svou vlastní větev vzdáleného úložiště pro rozsah práce. Práce na místním řešení se potvrdí a odešle do verze větve ve vzdáleném úložišti se zprávou potvrzení. Zpráva potvrzení popisuje změny provedené v tomto potvrzení.

Pokud chcete změny sloučit, tvůrce obsahu otevře žádost o přijetí změn. Žádost o přijetí změn je odeslání pro peer review, které může vést ke sloučení práce provedené do jednoho řešení. Sloučení může vést ke konfliktům, které je potřeba vyřešit před sloučením větve. Kontroly žádostí o přijetí změn jsou důležité, aby tvůrci dodržovali standardy a postupy organizace pro vývoj, kvalitu a dodržování předpisů.

Doporučení pro spolupráci

Doporučujeme definovat strukturovaný proces, jak by tvůrci obsahu měli spolupracovat. Ujistěte se, že určíte:

  • Jak je práce vymezená a jak se vytvářejí, pojmenované a používané větve.
  • Jak autoři seskupují změny a popisují je s potvrzením zpráv.
  • Kdo zodpovídá za kontrolu a schvalování žádostí o přijetí změn.
  • Způsob řešení konfliktů při slučování
  • Jak se změny provedené v různých větvích sloučí do jedné větve.
  • Jak se obsah testuje a kdo provádí testování před nasazením obsahu.
  • Jak a kdy se změny nasazují do vývojových, testovacích a produkčních pracovních prostorů.
  • Postup a kdy se mají vrátit zpět nasazené změny nebo verze řešení.

Důležité

Hodnota poskytovaná DevOps je přímo úměrná dodržování procesů, které definují jeho použití.

Úspěšná spolupráce závisí na dobře definovaném procesu. Je důležité jasně popsat a zdokumentovat kompletní pracovní postup vývoje. Ujistěte se, že vybrané strategie a procesy odpovídají stávajícím postupům ve vašem týmu, a pokud ne, jak budete spravovat změny. Dále se ujistěte, že jsou procesy jasné a komunikované všem členům týmu a zúčastněným stranám. Ujistěte se, že členové týmu a účastníci, kteří s procesy začíná, jsou vytrénovaní, jak je přijmout, a že ocení hodnotu úspěšného přijetí DevOps.

Rozhraní REST API pro Power BI

Pomocí rozhraní REST API Power BI vyvíjíte programovou logiku pro import a nasazení obsahu z Azure DevOps. Soubory Power BI (.pbix) importujete do pracovního prostoru pomocí operace importu. Pomocí operace kanálu nasadíte nějaký obsah nebo veškerý obsah k testování nebo produkčnímu pracovnímu prostoru pomocí kanálů nasazení Power BI. Programová logika je definovaná v Azure Pipelines.

K volání rozhraní REST API Power BI ve vašich kanálech doporučujeme použít instanční objekt . Instanční objekt je určený pro bezobslužné, automatizované aktivity a nespoléhá na přihlašovací údaje uživatele. Některé položky a aktivity ale rozhraní REST API Power BI nepodporují ani při použití instančního objektu, jako jsou toky dat.

Při použití instančního objektu nezapomeňte pečlivě spravovat oprávnění. Vaším cílem by mělo být dodržovat zásadu nejnižších oprávnění. Pro instanční objekt byste měli nastavit dostatečná oprávnění bez oprávnění k nadměrnému zřizování. Použijte Azure Key Vault nebo jinou službu, která bezpečně ukládá tajné kódy a přihlašovací údaje instančního objektu.

Upozornění

Pokud máte datový model, který je uložený jako formát metadat čitelný pro člověka, nejde ho publikovat pomocí rozhraní REST API Power BI. Místo toho ho musíte publikovat pomocí koncového bodu XMLA. Soubory metadat můžete publikovat pomocí nástrojů třetích stran, jako je rozhraní příkazového řádku (CLI) tabulkového editoru. Soubory metadat můžete publikovat také programově pomocí vlastního vývoje .NET. Vývoj vlastního řešení vyžaduje větší úsilí, protože musíte použít rozšíření Microsoft Tabular Object Model (TOM) klientských knihoven AMO (Analysis Management Object).

Azure Pipelines

Azure Pipelines programově automatizuje testování, správu a nasazování obsahu. Při spuštění kanálu se kroky v kanálu spustí automaticky. Vlastníci kanálů můžou přizpůsobit své triggery, kroky a funkce tak, aby vyhovovaly potřebám nasazení. Počet a typy kanálů se proto liší v závislosti na požadavcích řešení. Kanál Azure může například spustit automatizované testy nebo upravit parametry datového modelu před nasazením.

Existují tři typy Azure Pipelines, které můžete nastavit pro testování, správu a nasazení řešení Power BI:

  • Ověřovací kanály.
  • Kanály sestavení
  • Kanály vydaných verzí

Poznámka:

Ve vašem řešení publikování není nutné mít všechny tři z těchto kanálů. V závislosti na vašem pracovním postupu a potřebách můžete nastavit jednu nebo více variant kanálů popsaných v tomto článku pro automatizaci publikování obsahu. Tato schopnost přizpůsobit kanály je výhodou Azure Pipelines oproti integrovaným kanálům nasazení Power BI. Nemusíte mít například ověřovací kanál; můžete použít pouze kanály buildu a verze.

Kanály ověření

Kanály ověření provádějí základní kontroly kvality datových modelů před publikováním do vývojového pracovního prostoru. Změny ve větvi vzdáleného úložiště obvykle aktivují kanál, aby tyto změny ověřily pomocí automatizovaného testování.

Mezi příklady automatizovaného testování patří prohledávání datového modelu pro porušení pravidel osvědčených postupů pomocí analyzátoru osvědčených postupů (BPA) nebo spouštění dotazů DAX na publikovaný sémantický model. Výsledky těchto testů se pak uloží do vzdáleného úložiště pro účely dokumentace a auditování. Datové modely, které selžou ověření, by se neměly publikovat. Místo toho by kanál měl informovat tvůrce obsahu o problémech.

Kanály buildu

Kanály sestavení připraví datové modely pro publikování do služba Power BI. Tyto kanály kombinují serializovaná metadata modelu do jednoho souboru, který později publikuje kanál verze (popsaný v diagramu kanálů verze). Kanál buildu může také provádět další změny metadat, jako je úprava hodnot parametrů. Kanály buildu vytvářejí artefakty nasazení, které se skládají z metadat datového modelu (pro datové modely) a souborů Power BI Desktopu (.pbix), které jsou připravené k publikování do služba Power BI.

Kanály vydaných verzí

Kanály vydaných verzí publikují nebo nasazují obsah. Řešení publikování obvykle zahrnuje několik kanálů verze v závislosti na cílovém prostředí.

  • Kanál verze pro vývoj: Tento první kanál se aktivuje automaticky. Po úspěšném vytvoření kanálu sestavení a ověření publikuje obsah do vývojového pracovního prostoru.
  • Kanály testovací a produkční verze: Tyto kanály se neaktivují automaticky. Místo toho se aktivují na vyžádání nebo po schválení. Kanály testovací a produkční verze nasazují obsah do testovacího nebo produkčního pracovního prostoru po schválení verze. Schválení vydaných verzí zajistí, že se obsah před přípravou automaticky nenasadí do testovací nebo produkční fáze. Tato schválení poskytují správci verzí, kteří zodpovídají za plánování a koordinaci vydávání obsahu do testovacího a produkčního prostředí.

Existují dva různé přístupy k publikování obsahu s kanály testování a verze. Buď propagují obsah pomocí kanálu nasazení Power BI, nebo publikují obsah do služba Power BI z Azure DevOps.

Následující diagram znázorňuje první přístup. V tomto přístupu kanály verzí orchestrují nasazení obsahu do testovacích a produkčních pracovních prostorů pomocí kanálů nasazení Power BI. Obsah se propaguje prostřednictvím pracovních prostorů pro vývoj, testování a produkční prostředí v Power BI. I když je tento přístup robustnější a jednodušší, vyžaduje licencování Premium.

Diagram znázorňuje první přístup, jak je popsáno v předchozím odstavci. Položky v diagramu jsou popsány v následující tabulce.

Diagram znázorňuje následující akce, procesy a funkce uživatele prvního přístupu.

Položka Popis
Položka 1. V prvním přístupu kanály verze publikují obsah pomocí koncového bodu XMLA a rozhraní REST API Power BI s kanály nasazení Power BI. Obsah se publikuje a pak propaguje prostřednictvím vývojových, testovacích a produkčních pracovních prostorů. Kanály nasazení Power BI a koncový bod XMLA pro čtení a zápis jsou funkce Premium.
Položka 2. Úspěšné sloučení větve nebo dokončení nadřazeného kanálu aktivuje kanál buildu. Kanál buildu pak připraví obsah pro publikování a aktivuje kanál verze pro vývoj.
Položka 3. Kanál verze pro vývoj publikuje obsah do vývojového pracovního prostoru pomocí koncového bodu XMLA (pro metadata datového modelu) nebo rozhraní REST API Power BI (pro soubory Power BI Desktopu, které můžou obsahovat datové modely a sestavy). Vývojový kanál používá k nasazení metadat datového modelu pomocí koncového bodu XMLA rozhraní příkazového řádku (CLI) tabulkového editoru.
Položka 4. Aktivační událost schválení verze nebo aktivace na vyžádání aktivuje kanál testovací verze.
Položka 5. Kanál testovací verze nasadí obsah pomocí operací nasazení rozhraní REST API Power BI, které spouští kanál nasazení Power BI.
Položka 6. Kanál nasazení Power BI podporuje obsah z vývojového pracovního prostoru do testovacího pracovního prostoru. Po nasazení kanál verze provádí aktivity po nasazení pomocí rozhraní REST API Power BI (nezobrazuje se v diagramu).
Položka 7. Aktivace schválení verze nebo aktivace na vyžádání aktivuje kanál produkční verze.
Položka 8. Kanál produkční verze nasadí obsah pomocí operací nasazení rozhraní REST API Power BI, které spouští kanál nasazení Power BI.
Položka 9. Kanál nasazení Power BI podporuje obsah z testovacího pracovního prostoru do produkčního pracovního prostoru. Po nasazení kanál verze provádí aktivity po nasazení pomocí rozhraní REST API Power BI (nezobrazuje se v diagramu).

Následující diagram znázorňuje druhý přístup. Tento přístup nepoužívá kanály nasazení. Místo toho používá kanály verze k publikování obsahu do testovacích a produkčních pracovních prostorů z Azure DevOps. Tento druhý přístup nevyžaduje licencování Premium, pokud publikujete jenom soubory Power BI Desktopu pomocí rozhraní REST API Power BI. Zahrnuje to větší úsilí o nastavení a složitost, protože musíte spravovat nasazení mimo Power BI. Vývojové týmy, které už používají DevOps pro datová řešení mimo Power BI, můžou být s tímto přístupem lépe obeznámené. Vývojové týmy, které tento přístup používají, můžou konsolidovat nasazení datových řešení v Azure DevOps.

Diagram znázorňuje druhý přístup, jak je popsáno v předchozím odstavci. Položky v diagramu jsou popsány v následující tabulce.

Diagram znázorňuje následující akce, procesy a funkce uživatelů v druhém přístupu.

Položka Popis
Položka 1. V druhém přístupu kanály verze publikují obsah pouze pomocí koncového bodu XMLA a rozhraní REST API Power BI. Obsah se publikuje do pracovních prostorů pro vývoj, testování a produkční prostředí.
Položka 2. Úspěšné sloučení větve nebo dokončení nadřazeného kanálu aktivuje kanál buildu. Kanál buildu pak připraví obsah pro publikování a aktivuje kanál verze pro vývoj.
Položka 3. Kanál verze pro vývoj publikuje obsah do vývojového pracovního prostoru pomocí koncového bodu XMLA (pro metadata datového modelu) nebo rozhraní REST API Power BI (pro soubory Power BI Desktopu, které můžou obsahovat datové modely a sestavy). Vývojový kanál používá k nasazení metadat datového modelu pomocí koncového bodu XMLA rozhraní příkazového řádku (CLI) tabulkového editoru.
Položka 4. Aktivační událost schválení verze nebo aktivace na vyžádání aktivuje kanál testovací verze.
Položka 5. Kanál verze pro vývoj publikuje obsah do testovacího pracovního prostoru pomocí koncového bodu XMLA (pro metadata datového modelu) nebo rozhraní REST API Power BI (pro soubory Power BI Desktopu, které můžou obsahovat datové modely a sestavy). Vývojový kanál používá k nasazení metadat datového modelu pomocí koncového bodu XMLA rozhraní příkazového řádku (CLI) tabulkového editoru. Po nasazení kanál verze provádí aktivity po nasazení pomocí rozhraní REST API Power BI (nezobrazuje se v diagramu).
Položka 6. Aktivace schválení verze nebo aktivace na vyžádání aktivuje kanál produkční verze.
Položka 7. Kanál verze pro vývoj publikuje obsah do produkčního pracovního prostoru pomocí koncového bodu XMLA (pro metadata datového modelu) nebo rozhraní REST API Power BI (pro soubory Power BI Desktopu, které můžou obsahovat datové modely a sestavy). Vývojový kanál používá k nasazení metadat datového modelu pomocí koncového bodu XMLA rozhraní příkazového řádku (CLI) tabulkového editoru. Po nasazení kanál verze provádí aktivity po nasazení pomocí rozhraní REST API Power BI (nezobrazuje se v diagramu).

Kanály verze by měly spravovat aktivity po nasazení. Tyto aktivity můžou zahrnovat nastavení sémantických přihlašovacích údajů modelu nebo aktualizaci aplikace Power BI pro testovací a produkční pracovní prostory. Doporučujeme nastavit oznámení, která budou informovat relevantní lidi o aktivitách nasazení.

Tip

Použití úložiště pro správu verzí umožňuje tvůrcům obsahu vytvořit proces vrácení zpět. Proces vrácení zpět může vrátit zpět poslední nasazení obnovením předchozí verze. Zvažte vytvoření samostatné sady Azure Pipelines, kterou můžete aktivovat pro vrácení produkčních změn zpět. Pečlivě zvažte, jaké procesy a schválení jsou potřeba k zahájení vrácení zpět. Ujistěte se, že jsou tyto procesy zdokumentované.

Kanály nasazení Power BI

Kanál nasazení Power BI se skládá ze tří fází: vývoj, testování a produkce. Každému kroku v kanálu nasazení přiřadíte jeden pracovní prostor Power BI. Když dojde k nasazení, kanál nasazení podporuje položky Power BI z jednoho pracovního prostoru do druhého.

Kanál verze Azure Pipelines používá rozhraní REST API Power BI k nasazení obsahu pomocí kanálu nasazení Power BI. Pro uživatele provádějící nasazení se vyžaduje přístup k pracovnímu prostoru i kanálu nasazení. Doporučujeme naplánovat přístup ke kanálu nasazení, aby uživatelé kanálu mohli zobrazit historii nasazení a porovnat obsah.

Tip

Když oddělíte datové pracovní prostory od pracovních prostorů generování sestav, zvažte použití Azure Pipelines k orchestraci publikování obsahu s několika kanály nasazení Power BI. Nejprve se nasadí sémantický model a pak se aktualizuje. Nakonec se nasadí sestavy. Tento přístup vám pomůže zjednodušit nasazení.

Licencování Premium

Kanály nasazení Power BI a koncový bod XMLA pro čtení a zápis jsou funkce Premium. Tyto funkce jsou dostupné s kapacitou Power BI Premium a Power BI Premium na uživatele (PPU).

PPU je nákladově efektivní způsob správy publikování podnikového obsahu pro pracovní prostory vývoje a testování, které obvykle mají málo uživatelů. Tento přístup má přidanou výhodu izolace vývojových a testovacích úloh z produkčních úloh.

Poznámka:

Publikování podnikového obsahu můžete nastavit i bez licence Premium, jak popisuje druhý přístup v části kanálu verze. Ve druhém přístupu použijete Azure Pipelines ke správě nasazení souborů Power BI Desktopu do pracovních prostorů pro vývoj, testování a produkční prostředí. Metadata modelu ale nemůžete nasadit pomocí koncového bodu XMLA, protože není možné publikovat sémantický model formátu metadat pomocí rozhraní REST API Power BI. Není také možné propagovat obsah prostřednictvím prostředí s kanály nasazení bez licence Premium.

Nastavení brány

Brána dat se obvykle vyžaduje při přístupu ke zdrojům dat, které se nacházejí v privátní síti organizace nebo virtuální síti. Dva účely brány slouží k aktualizaci importovaných dat a zobrazení sestavy, která se dotazuje živého připojení nebo sémantického modelu DirectQuery (není znázorněno v diagramu scénáře).

Při práci s několika prostředími je běžné nastavit vývojová, testovací a produkční připojení k různým zdrojovým systémům. V tomto případě použijte pravidla zdroje dat a pravidla parametrů ke správě hodnot, které se mezi prostředími liší. Ke správě bran můžete použít Azure Pipelines pomocí operací brány rozhraní REST API Power BI.

Poznámka:

Centralizovaná brána dat ve standardním režimu se důrazně doporučuje u bran v osobním režimu. Ve standardním režimu podporuje brána dat živé připojení a operace DirectQuery (kromě plánovaných operací aktualizace dat).

Dohled nad systémem

Protokol aktivit zaznamenává události, ke kterým dochází v služba Power BI. Správci Power BI můžou protokol aktivit použít k auditování aktivit nasazení.

K vytvoření inventáře tenanta můžete použít rozhraní API pro kontrolu metadat Power BI. Výsledky rozhraní API jsou užitečné k ověření toho, které položky byly nasazeny do každého pracovního prostoru, ke kontrole rodokmenu a k ověření nastavení zabezpečení.

V Azure DevOps je také protokol auditu, který je mimo služba Power BI. Správci Azure DevOps můžou protokol auditu použít ke kontrole aktivit ve vzdálených úložištích a kanálech.

Související obsah

Další užitečné scénáře, které vám pomůžou s rozhodováním o implementaci Power BI, najdete v článku o scénářích použití Power BI.