Plánování implementace Power BI: Nasazení obsahu

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 prostředí Power BI v Rámci Microsoft Fabric. Úvod do série najdete v tématu Plánování implementace Power BI.

Tento článek vám pomůže nasadit obsah jako součást správy životního cyklu obsahu. Primárně se zaměřuje na:

• Správci prostředků infrastruktury: Správci, kteří jsou zodpovědní za dohled nad prostředky infrastruktury v organizaci. Správci prostředků infrastruktury můžou potřebovat spolupracovat s dalšími správci, jako jsou ti, kteří dohlížejí na Microsoft 365 nebo Azure DevOps.
• Týmy Center of Excellence (COE) a BI: Týmy zodpovědné za dohled nad Power BI v organizaci. Mezi tyto týmy patří rozhodovací pracovníci, kteří se rozhodnou, jak spravovat životní cyklus obsahu Power BI. Tyto týmy mohou také zahrnovat správce verzí, kteří zpracovávají životní cyklus vydaných verzí obsahu, a technici, kteří vytvářejí a spravují komponenty potřebné k efektivnímu používání a podpoře správy životního cyklu.
• Tvůrci obsahu a vlastníci obsahu: Uživatelé, kteří vytvářejí obsah, který chtějí publikovat na portálu Fabric, aby ho mohli sdílet s ostatními. Tito jednotlivci zodpovídají za správu životního cyklu obsahu Power BI, který vytvářejí.

Správa životního cyklu se skládá z procesůach Ve třetí fázi správy životního cyklu ověřujete změny obsahu, které zahrnují ověření prováděné tvůrci obsahu i uživateli. Ve čtvrté fázi nasadíte obsah pro uživatele, kteří ho budou používat.

Pokud chcete sdílet obsah Power BI s uživateli, měli byste nejprve publikovat (nebo nasadit) obsah do pracovního prostoru Prostředky infrastruktury. Nasazení obsahu také zahrnuje přesun obsahu mezi prostředími, například nasazení z vývojového pracovního prostoru do testovacího pracovního prostoru nebo testovacího pracovního prostoru do produkčního pracovního prostoru.

Následující obrázek znázorňuje životní cyklus obsahu Power BI a zvýrazňuje fázi čtyři, kde nasazujete obsah.

Poznámka:

Přehled správy životního cyklu obsahu najdete v prvním článku této série.

Tento článek se zaměřuje na klíčové aspekty a rozhodnutí týkající se nasazení obsahu v průběhu životního cyklu. Další pokyny k nasazení obsahu najdete tady:

• Migrace do Power BI: Nasazení obsahu: Tento článek popisuje klíčové aspekty a rozhodnutí týkající se nasazení při migraci do Power BI z jiných technologií.
• Plánování řešení BI: Nasazení, podpora a monitorování: Tento článek popisuje, jak naplánovat nasazení při prvním vytvoření řešení Power BI nebo Fabric.
• Plánování implementace Power BI: Scénář použití samoobslužného publikování obsahu: Tento článek popisuje, jak uživatelé samoobslužných služeb můžou nasazovat obsah pomocí kanálů nasazení OneDrivu pro práci a školu a prostředky infrastruktury.
• Plánování implementace Power BI: Scénář využití publikování podnikového obsahu: Tento článek popisuje, jak můžou centrální týmy nasazovat a spravovat obsah pomocí Azure DevOps.

Během životního cyklu obsahu nasadíte obsah na dva hlavní body:

• Když publikujete obsah do vývojového pracovního prostoru. V tuto chvíli publikujete obsah, abyste ověřili změny.
• Když propagujete obsah mezi dvěma pracovními prostory (například zvýšení úrovně obsahu z vývojového pracovního prostoru na testovací pracovní prostor). V tomto okamžiku nasadíte obsah, když je připravený pro další fázi (například když je nový obsah připravený k otestování).

Následující části popisují přístupy, které můžete použít k publikování nebo zvýšení úrovně obsahu.

Rozhodnutí o způsobu publikování obsahu

Při vývoji obsahu na místním počítači musíte tento obsah publikovat do vývojového pracovního prostoru na portálu Fabric. Tento obsah obvykle publikujete, když chcete provést ověření provedených změn.

Poznámka:

V tomto článku odkazujeme na publikování obsahu jako počátečního nasazení do vývojového pracovního prostoru. V zásadě je ale publikování obsahu stejné jako jeho nasazení.

Obsah vytvořený na portálu Fabric (například toky dat, řídicí panely a přehledy výkonnostních metrik) se vytvoří přímo v pracovním prostoru pro vývoj a nemusí se publikovat.

Následující části popisují různé přístupy, které můžete použít k publikování obsahu.

Publikování pomocí Power BI Desktopu

Power BI Desktop umožňuje uživatelům publikovat sémantické modely a sestavy z místního počítače do pracovního prostoru na portálu Fabric. Tento přístup je nejjednodušší způsob publikování obsahu; Ale nejde ho automatizovat.

Zvažte použití tohoto přístupu v těchto případech:

• Tvůrci obsahu raději ručně řídí publikování obsahu na portálu Fabric.
• Tvůrci obsahu používají Power BI Desktop k vývoji a správě obsahu.
• Tvůrci obsahu nejsou obeznámeni s Azure DevOps ani Gitem.
• Obsah obsahuje pouze sémantické modely nebo sestavy.

Publikování pomocí nástrojů třetích stran

Nástroje třetích stran umožňují tvůrcům obsahu publikovat sémantický model pomocí koncového bodu XMLA pracovního prostoru pro čtení a zápis. Tvůrce obsahu například používá tabulkový editor k vývoji a správě metadat modelu, jako je TMDL (Tabular Model Definition Language) nebo .bim.

Tip

Další informace o tom, jak pomocí nástrojů třetích stran nasadit sémantické modely, najdete v pokročilém scénáři použití správy datových modelů.

Další informace o tom, jak povolit a používat koncové body XMLA pro čtení a zápis, najdete v tématu Sémantický model připojení ke koncovému bodu XMLA.

Zvažte použití tohoto přístupu v těchto případech:

• Tvůrci obsahu raději ručně řídí publikování obsahu na portálu Fabric.
• Tvůrci obsahu používají k vývoji a správě obsahu nástroj třetí strany.
• Obsah se publikuje do pracovního prostoru, který používá Premium na uživatele (PPU), kapacitu Premium nebo režim licence kapacity Fabric.
• Tvůrci obsahu nejsou obeznámeni s Azure DevOps ani Gitem.
• Obsah obsahuje pouze sémantické modely.

Publikování pomocí aktualizace OneDrivu

OneDrive umožňuje tvůrcům samoobslužného obsahu automaticky publikovat sémantické modely nebo sestavy do pracovního prostoru na portálu Fabric pomocí aktualizace OneDrivu. Tvůrci obsahu můžou ukládat soubory Power BI Desktopu (.pbix) do sdílené knihovny na OneDrivu. Sdílená knihovna může být také sharepointovou nebo microsoft teams knihovnou dokumentů.

Tip

Další informace o používání OneDrivu pro práci a školu s obsahem Power BI najdete ve scénáři použití samoobslužného publikování obsahu.

Další informace o tom, jak nastavit aktualizaci OneDrivu, najdete v tématu Aktualizace sémantického modelu uloženého na OneDrivu nebo SharePointu Online.

Zvažte použití tohoto přístupu v těchto případech:

• Tvůrci obsahu chtějí automatizovat publikování obsahu na portálu Fabric.
• Tvůrci obsahu nejsou obeznámeni s Azure DevOps ani Gitem.
• Tvůrci obsahu provádějí správu verzí obsahu pomocí OneDrivu nebo SharePointu.
• Tvůrci obsahu ukládají sémantické modely a sestavy jako soubory .pbix.
• Obsah obsahuje pouze sémantické modely nebo sestavy.

Publikování s využitím integrace Gitu s prostředky infrastruktury

Integrace Gitu s prostředky infrastruktury je funkce, která umožňuje tvůrcům obsahu synchronizovat větev ze vzdáleného úložiště Git s pracovním prostorem Fabric. Integraci Gitu můžete použít společně s Azure DevOps k synchronizaci obsahu z Azure Repos nebo můžete nasadit obsah pomocí Azure Pipelines (popsaný v další části).

Poznámka:

Azure DevOps je sada služeb, které se integrují s Power BI a Prostředky infrastruktury, které vám pomůžou plánovat a orchestrovat správu životního cyklu obsahu. Při použití Azure DevOps tímto způsobem obvykle využíváte následující služby:

• Azure Repos: Umožňuje vytvářet a používat vzdálené úložiště Git, což je vzdálené umístění úložiště, které používáte ke sledování a správě změn obsahu.
• Azure Pipelines: Umožňuje vytvářet a používat sadu automatizovaných úloh ke zpracování, testování a nasazování obsahu ze vzdáleného úložiště do pracovního prostoru.
• Azure Test Plans: Umožňuje navrhovat testy pro ověření řešení a automatizovat řízení kvality společně se službou Azure Pipelines.
• Azure Boards: Umožňuje používat panely ke sledování úkolů a plánů jako pracovních položek a k propojení nebo odkazování na pracovní položky z jiných služeb Azure DevOps.
• Azure Wiki: Umožňuje sdílet informace se svým týmem, abyste porozuměli obsahu a přispěli k nim.

Pokud chcete shrnout, obsah potvrzený a vložený do vzdáleného úložiště se automaticky publikuje do pracovního prostoru prostřednictvím tohoto procesu synchronizace. Klíčovou výhodou tohoto přístupu je, že umožňuje spojit procesy správy správy zdrojového kódu s publikováním obsahu. Umožňuje například snadnější vrácení změn nebo celých verzí řešení.

Tip

Další informace o použití integrace Gitu s prostředky infrastruktury k nasazení obsahu Power BI najdete ve scénáři použití publikování podnikového obsahu.

Další informace o tom, jak nastavit integraci Gitu, najdete v tématu Kurz: Správa životního cyklu v projektech Fabric a Power BI Desktop: Integrace Gitu.

Zvažte použití tohoto přístupu v těchto případech:

• Tvůrci obsahu jsou obeznámeni s Azure DevOps a Gitem.
• Tvůrci obsahu používají Azure DevOps ke spolupráci a správě zdrojového kódu.
• Tvůrci obsahu ukládají sémantické modely a sestavy jako soubory projektu Power BI (.pbip ).
• Obsah se publikuje do pracovního prostoru v kapacitě Fabric.
• Obsah se skládá z podporovaných typů položek pomocí funkce integrace Gitu.
• Obsah neobsahuje popisky citlivosti.

Poznámka:

Způsob použití integrace Gitu k nasazení a správě obsahu je silně závislý na strategiích větvení a slučování, které se rozhodnete ve dvou fázích správy životního cyklu.

Publikování s využitím 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. Azure Pipelines je složitější a vyžaduje více času a úsilí k nastavení v porovnání s jinými přístupy, ale umožňuje největší kontrolu a flexibilitu orchestrace procesu nasazení.

Tip

Obsah můžete nasadit pomocí azure Pipelines a rozhraní REST API Power BI do pracovních prostorů, které nejsou v kapacitě Fabric nebo Premium. Rozhraní REST API prostředků infrastruktury ale pracují pouze s prostředky infrastruktury a koncové body XMLA pracují pouze s kapacitou Fabric nebo Premium.

Další informace o použití Azure Pipelines k nasazení obsahu Power BI najdete ve scénáři použití publikování podnikového obsahu.

Další informace o tom, jak integrovat Azure DevOps s Power BI, najdete v tématu Integrace a kanály buildů Azure DevOps v projektech Power BI Desktopu.

Zvažte použití Azure Pipelines k orchestraci nasazení obsahu v následujících případech:

• Tvůrci obsahu jsou obeznámeni s Azure DevOps a rozhraními REST API fabric.
• Tvůrci obsahu používají Azure DevOps ke spolupráci a správě zdrojového kódu.
• Tvůrci obsahu nepoužívají integraci Gitu s prostředky infrastruktury.

Azure Pipelines a další nástroje založené na kódu můžou programově nasadit obsah pomocí jednoho nebo více následujících rozhraní API nebo koncových bodů:

• Rozhraní REST API Power BI: Existují různé koncové body rozhraní REST API Power BI, které můžete použít k nasazení obsahu. Rozhraní REST API Power BI podporují pouze typy položek Power BI.
  • Import: Podporované položky můžete publikovat pomocí rozhraní REST API Power BI k importu platného zdrojového souboru do pracovního prostoru (například souboru .pbix).
  • Nasazení: Pokud jsou fáze v kanálu nasazení, můžete je nasadit a propagovat je z jednoho pracovního prostoru do druhého.
• Rozhraní REST API prostředků infrastruktury: Existují různé koncové body rozhraní REST API prostředků infrastruktury, které můžete použít k nasazení obsahu. Rozhraní REST API prostředků infrastruktury podporují typy položek Power BI i Fabric.
  • Vytvoření: Podporované položky můžete vytvořit pomocí rozhraní REST API prostředků infrastruktury společně s platnou definicí položky.
  • Aktualizace z Gitu: Pracovní prostor můžete aktualizovat obsahem ze vzdáleného úložiště připojeného pomocí integrace Gitu.
• Koncové body XMLA pro čtení a zápis: Sémantické modely můžete vytvářet nebo měnit pomocí koncových bodů XMLA společně s platným souborem model.bim. Koncové body XMLA umožňují nasadit změny do konkrétních objektů modelu místo celého modelu. Azure Pipelines může využívat nástroje třetích stran (jako je rozhraní příkazového řádku tabulkového editoru) k nasazení sémantických modelů pomocí koncových bodů XMLA.

Tip

Pokud používáte rozhraní REST API prostředků infrastruktury nebo Power BI, musíte nejprve vytvořit registraci aplikace v Azure (tady je popsáno pro Power BI Embedded). To vyžaduje tenanta Microsoft Entra ID a uživatele organizace a může to být složitý proces pro nastavení příslušných oprávnění. Rozhraní REST API prostředků infrastruktury ale můžete spouštět v poznámkových blocích bez vytvoření registrace aplikace. Tím se zjednoduší nastavení a používání rozhraní API ve vašich řešeních, takže před použitím rozhraní API nemusíte spravovat přihlašovací údaje ani konfigurovat žádné nastavení.

Pokud chcete používat rozhraní REST API prostředků infrastruktury bez registrace aplikace, použijte sémantický odkaz v poznámkovém bloku Fabric s třídou FabricRestClientClass pro sempy k volání rozhraní API.

Díky automatizovanému testování vám integrace Azure Pipelines s Power BI pomůže dosáhnout kontinuální integrace a průběžného nasazování (CI/CD).

Při použití Azure Pipelines můžou vlastníci kanálů přizpůsobit 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í.

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

• Kanály ověření
• Kanály buildu
• Kanály vydaných verzí

Poznámka:

V řešení publikování není nutné mít všechny tři typy kanálu. 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í Fabric.

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 spuš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ý je později publikován kanálem verze. Kanál buildu může také provádět 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ů projektu Power BI (.pbip), 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í.

Rozhodněte se, jak budete propagovat obsah mezi pracovními prostory.

Pokud pro vývoj, testování a produkci používáte různá prostředí, musíte nasadit obsah do všech tří prostředí. Existují různé nástroje a přístupy, které můžete použít k propagaci obsahu mezi pracovními prostory v závislosti na konkrétním pracovním postupu a potřebách.

Následující části popisují přístupy, které můžete použít k propagaci obsahu mezi pracovními prostory.

Upozornění

Vyhněte se ručnímu publikování obsahu z místního počítače do testovacích a produkčních pracovních prostorů. Může vést k chybám nebo přerušením kvůli chybám. Obecně platí, že byste ho měli publikovat jenom do vývojového pracovního prostoru nebo do privátního pracovního prostoru, pokud ho používáte.

Nasazení s využitím kanálů nasazení Fabric

Kanály nasazení umožňují nastavit dvě nebo více fází (například vývoj, testování nebo produkční) a nasadit obsah prostředků infrastruktury mezi těmito fázemi. Správce kanálu přiřadí ke každé fázi kanálu nasazení jeden pracovní prostor Power BI. Způsob použití kanálů nasazení závisí na tom, jak jste se rozhodli nastavit a používat pracovní prostory.

Zvažte použití kanálů nasazení v následujících případech:

• Obsah se nasadí do pracovních prostorů s režimem licence PPU, kapacity Premium nebo kapacity Fabric.
• Kanály nasazení podporují typy a scénáře položek obsahu.

Zvažte jiný přístup než kanály nasazení, pokud:

• Dáváte přednost nasazení obsahu ze vzdáleného úložiště, například pomocí Azure Pipelines.
• Máte v úmyslu používat integraci Gitu k synchronizaci různých fází s různými větvemi vzdáleného úložiště místo nasazení obsahu.

Tip

Další informace o tom, jak pomocí kanálů nasazení propagovat obsah mezi pracovními prostory, najdete v scénářích použití samoobslužného publikování obsahu a publikování podnikového obsahu .

Další informace o kanálech nasazení najdete v tématu Kanály nasazení: Vysvětlení procesu nasazení.

Nejjednodušší způsob, jak použít kanál nasazení, je, když publikujete veškerý obsah do jednoho pracovního prostoru a upřednostníte ho do pozdějších fází v rámci jednoho kanálu nasazení. Následující diagram znázorňuje tento první přístup k nasazení obsahu pomocí kanálu nasazení.

V souhrnu autor obsahu obvykle publikuje obsah do počáteční fáze kanálu. Pokud pak chcete zvýšit úroveň obsahu do pozdějších fází, správce kanálu aktivuje nasazení. Když dojde k nasazení, kanál nasazení nasadí metadata obsahu z jednoho pracovního prostoru do dalšího.

Když obsah rozdělíte podle typu položky v různých pracovních prostorech, použijete k nasazení tohoto obsahu samostatné kanály nasazení. Obsah mezi pracovními prostory můžete propojit s několika kanály nasazení pomocí automatické vazby. Automatická vazba mezi kanály nasazení zajišťuje, že obsah zůstane propojený s příslušnou položkou v příslušné fázi. Například sestava ve fázi vývoje zůstane propojená s modelem ve fázi vývoje druhého kanálu nasazení. Pokud ale váš scénář vyžaduje propojení obsahu mezi pracovními prostory s jiným vzorem, můžete se vyhnout také chování automatické vazby .

Následující diagram znázorňuje tento druhý přístup k nasazení obsahu pomocí několika kanálů nasazení.

Stručně řečeno, nasazení obsahu pomocí více kanálů nasazení je podobné použití jednoho kanálu. Klíčovým rozdílem je, že můžete volitelně propojit obsah, který je propojený mezi pracovními prostory a kanály nasazení, pomocí automatické vazby. V opačném případě je stejný jako první přístup.

Kanály nasazení jsou flexibilní a jednoduchý nástroj vhodný ke zlepšení správy životního cyklu obsahu pro samoobslužné i podnikové scénáře.

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 správci kanálu mohli zobrazit historii nasazení a porovnat obsah. Při spolupráci s více tvůrci obsahu zvažte omezení přístupu kanálu na správce verzí nebo technické vlastníky, kteří jsou nejvhodnější pro dohled nad procesy nasazení a vydávání verzí.

Zvažte také použití pravidel nasazení k nastavení různých konfigurací položek v různých fázích. Můžete například chtít, aby sémantický model ve vývojovém pracovním prostoru mohl zdrojovat data z vývojové databáze, zatímco sémantický model v produkčním pracovním prostoru zdroje dat z produkční databáze.

Tip

Pokud k vašemu kanálu nasazení má přístup více lidí, doporučujeme pravidelně kontrolovat historii nasazení. Tyto kontroly vám můžou pomoct identifikovat neschválené nasazení nebo selhání nasazení.

Pokud k propojení položek mezi kanály nasazení používáte automatickou vazbu , zkontrolujte také rodokmeny položek a identifikujte konce automatických vazeb způsobených tím, že někdo publikuje propojený obsah do nesprávné fáze.

Nasazení můžete aktivovat ručně nebo programově pomocí rozhraní REST API Power BI. V oboupřípadechch

Ruční nasazení

Obsah můžete nasadit ručně pomocí kanálu nasazení Fabric. Můžete zvolit nasazení veškerého obsahu nebo výběr položek. Selektivní nasazení může být užitečné, když je nějaký obsah připravený k přechodu do další fáze, ale některé položky stále procházejí vývojem nebo ověřením. Kromě toho můžete provést zpětné nasazení , pokud v pozdější fázi existují změny obsahu, ale ne v dřívější fázi.

Upozornění

Při použití kanálů nasazení doporučujeme nasadit obsah jedním směrem, například z vývoje na testování do produkčních pracovních prostorů. Obvykle byste se měli vyhnout provádění změn obsahu v pozdějších fázích předtím, než tyto změny projdou odpovídajícím ověřením ve vývoji nebo testu.

Při provádění ručního nasazení můžete porovnat fáze s identifikací změn obsahu v okně kontroly změn. Tento přístup je užitečný hlavně v případě, že pro správu zdrojového kódu nepoužíváte vzdálené úložiště Git.

Použití rozhraní REST API Power BI k nasazení

Pomocí rozhraní REST API Power BI můžete nasadit obsah pomocí kanálu nasazení. Výhodou použití rozhraní REST API je, že můžete automatizovat nasazení a integrovat ho s dalšími nástroji, jako je Azure Pipelines v Azure DevOps.

Nasazení s využitím Azure Pipelines

Azure Pipelines umožňuje orchestraci nasazení mezi všemi fázemi. Díky tomuto přístupu použijete rozhraní REST API prostředků infrastruktury k nasazení a správě obsahu a využíváte různé kanály Azure Pipelines, jako je ověřování a kanály vydaných verzí.

Zvažte použití Azure Pipelines v následujících případech:

• Chcete centralizovat orchestraci nasazení z Azure DevOps.
• Tvůrci obsahu používají Azure DevOps ke spolupráci a správě zdrojového kódu.

Zvažte jiný přístup než Azure Pipelines, když:

• Tvůrci obsahu nejsou obeznámeni s nasazením Azure DevOps nebo na základě kódu.
• Obsah obsahuje typy položek, které nemají podporovanou definici nebo formát zdrojového souboru, jako jsou řídicí panely.

K nasazení obsahu pomocí Azure Pipelines existují dva různé přístupy. Buď orchestrují kanály nasazení, nebo nasazují obsah do pracovního prostoru bez kanálu nasazení.

Orchestrace kanálů nasazení Fabric pomocí Azure Pipelines

V tomto přístupu kanály verzí orchestrují nasazení obsahu do testovacích a produkčních pracovních prostorů pomocí kanálů nasazení. Obsah se propaguje prostřednictvím vývojových, testovacích a produkčních pracovních prostorů v prostředcích infrastruktury.

Následující diagram znázorňuje, jak orchestrujete kanály nasazení z Azure Pipelines.

Tvůrci obsahu v souhrnu publikují obsah do pracovního prostoru v první fázi kanálu nasazení. Pak správce verzí schválí nasazení, které aktivuje Azure Pipeline. Tento kanál používá rozhraní REST API Power BI k propagaci obsahu mezi fázemi, aby se metadata nasadila do jiného pracovního prostoru. Jednou z výhod tohoto přístupu je, že můžete orchestrovat nasazení více typů položek infrastruktury prostřednictvím kanálů nasazení, protože některé typy položek se vyvíjejí na portálu Fabric, a proto je azure Pipelines nemůže nasadit sám.

Nasazení obsahu pouze pomocí Azure Pipelines

Obsah můžete také nasadit do pracovního prostoru z Azure DevOps pomocí Azure Pipelines. Tento přístup nepoužívá kanály nasazení. Místo toho používá kanály verze k nasazení zdrojových souborů nebo souborů metadat pomocí rozhraní FABRIC nebo rozhraní REST API Power BI nebo koncových bodů čtení a zápisu XMLA. Tyto soubory se obvykle ukládají v úložišti Git Azure Repos.

Následující diagram znázorňuje, jak nasazujete obsah pouze pomocí Azure Pipelines.

V souhrnu tvůrci obsahu potvrdí a nasdílí změny obsahu do vzdáleného úložiště Git v Azure Repos. Tento obsah používá Azure Pipelines pro nasazení. Jakmile správce verzí schválí konkrétní nasazení, Azure Pipeline nasadí obsah do pracovního prostoru pomocí rozhraní REST API Power BI (to znamená pro soubory .pbix), rozhraní REST API prostředků infrastruktury (tj. pro definice položek) nebo koncových bodů XMLA (to znamená pro soubory model.bim). Pro každý pracovní prostor existuje samostatný kanál Azure.

Tento přístup nevyžaduje licencování prostředků infrastruktury ani Premium, když publikujete jenom soubory Power BI Desktopu pomocí rozhraní REST API Power BI. Zahrnuje ale 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 obeznámené. Vývojové týmy, které tento přístup používají, můžou konsolidovat nasazení datových řešení v Azure DevOps.

Nasazení s využitím integrace Gitu s prostředky infrastruktury

Při použití integrace Gitu můžete synchronizovat různé větve s různými pracovními prostory místo publikování nebo nasazování obsahu explicitně. Tímto způsobem můžete mít samostatné větve pro vývojové, testovací a produkční pracovní prostory. V tomto scénáři se hlavní větev synchronizuje s produkčním pracovním prostorem. Potom nasadíte obsah mezi pracovními prostory provedením žádosti o přijetí změn, která sloučí vývojovou větev do testovací větve (pro nasazení do testovacího pracovního prostoru) nebo sloučíte testovací větev do hlavní větve (pro nasazení do produkčního pracovního prostoru).

Následující diagram znázorňuje, jak nasadit obsah pomocí integrace Gitu s prostředky infrastruktury pro synchronizaci větví do různých pracovních prostorů. Pro zjednodušení diagram neobsahuje podrobnosti o větvení ani slučování obsahu.

V souhrnu tvůrci obsahu potvrdí a nasdílí změny obsahu do vzdáleného úložiště Git v Azure Repos. Tvůrci obsahu otevřou žádosti o přijetí změn ( ŽÁDOSTI O PŘIJETÍ ZMĚN), aby požádali o sloučení změn do konkrétní větve. V závislosti na strategii větvení jsou různé větve propojené s různými pracovními prostory. Jakmile se změny sloučí do větve, tvůrci obsahu synchronizují pracovní prostor se vzdáleným úložištěm Git a zobrazí nejnovější změny obsahu v daném pracovním prostoru.

Tento přístup zvažte v těchto případech:

• Nasazení mezi pracovními prostory chcete orchestrovat pomocí strategie větvení a sloučení.
• Nemáte v úmyslu používat kanály nasazení Azure Pipelines nebo Fabric k orchestraci nasazení k testování a produkci.
• Pracovní prostor neobsahuje nepodporované položky ani scénáře.
• Obsah neobsahuje popisky citlivosti.

Poznámka:

Existuje mnoho platných způsobů, jak nasadit obsah. Můžete například použít kombinaci různých přístupů probíraných v tomto článku.

Obsah můžete například nasadit do vývojového pracovního prostoru pomocí kanálu Azure, který vám umožní využívat funkce kontinuální integrace a provádět automatizované testování (například pomocí Analyzátoru osvědčených postupů). Pak můžete nasadit obsah mezi pracovními prostory pomocí integrace Gitu nebo kanálu nasazení Fabric.

Zvolte přístup, který nejlépe vyhovuje vašim potřebám a způsobu, jakým váš tým funguje.

Rozhodnutí o tom, jak zpracovat aktivity po nasazení

Po nasazení je potřeba zpracovat různé aktivity po nasazení. Mnohé z těchto aktivit se dají zpracovat programově, například pomocí Azure Pipeline nebo poznámkového bloku a rozhraní REST API Power BI a Fabric. Můžete například programově nastavit přihlašovací údaje ke zdroji dat, spravovat plánované aktualizace a aktivovat aktualizace po nasazení metadat. Některé úlohy ale vyžadují ruční zásah, například první nastavení nebo aktualizaci aplikace Power BI.

Ujistěte se, že identifikujete všechny relevantní aktivity po nasazení pro váš obsah a rozhodnete se, jak se budou zpracovávat.

Po naplánování nasazení obsahu byste měli zvážit, jak ho budete podporovat a monitorovat .

Kontrolní seznam – Při plánování nasazení obsahu, klíčových rozhodnutí a akcí patří:

• Určete dostupné možnosti nasazení: V závislosti na licencování a obsahu budete mít k dispozici různé možnosti pro publikování obsahu nebo jeho zvýšení úrovně mezi pracovními prostory. Určete, jestli můžete používat kanály nasazení, Azure DevOps, integraci Gitu, rozhraní REST API prostředků infrastruktury a koncové body pro čtení a zápis XMLA.
• Rozhodněte se, jak budete publikovat obsah: Zvolte přístup k publikování obsahu, který nejlépe vyhovuje vašemu pracovnímu postupu a potřebám. Zajistěte, aby tento přístup odpovídal vašim dalším strategiím, jako je sledování a správa změn.
• Rozhodněte se, jak budete propagovat obsah mezi pracovními prostory: Zvolte přístup k nasazení obsahu z vývoje do testovacích pracovních prostorů a z testování do produkčních pracovních prostorů. Ujistěte se, že tento přístup odpovídá vašim dalším strategiím, jako je způsob publikování obsahu.
• Naplánujte strategii vydání: Určete, jestli bude konkrétní jednotlivec zodpovědný za konečnou kontrolu obsahu před schválením verze nebo nasazení. Zajistěte, aby tento jednotlivec věděl o této úloze a o tom, co by měl udělat, aby chránil proces nasazení bez blokování průběhu.
• Plánování aktivit po nasazení: Ujistěte se, že jste se rozhodli o procesu provádění aktivit, jako je aktualizace aplikace Power BI nebo aktualizace datových položek po nasazení metadat. Zvažte automatizaci tohoto procesu pomocí rozhraní REST API prostředků infrastruktury.
• Proveďte první nastavení nástrojů a procesů nasazení: Ujistěte se, že jste nastavili odpovídající přístup a že oprávnění odpovídají způsobu nastavení přístupu k obsahu.
• Nasazení obsahu do produkčního prostředí: Při plánování a nastavení nasazení nasaďte obsah do produkčního prostředí.

Související obsah

V dalším článku v této sérii se dozvíte, jak podporovat a monitorovat obsah v rámci správy životního cyklu obsahu.