Plánování implementace Power BI: Vývoj obsahu a správa změn

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 vyvíjet obsah a spravovat změny v rámci správy životního cyklu obsahu. Primárně se zaměřuje na:

• 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 můžou také zahrnovat role, jako jsou správci verzí, kteří zpracovávají životní cyklus vydaných verzí obsahu, nebo 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 je procesy a postupy, které používáte ke zpracování obsahu od jeho vytvoření až po jeho případné vyřazení. V první fázi správy životního cyklu plánujete a navrhujete obsah, který zahrnuje plánování řešení a provádění klíčových rozhodnutí, která ovlivňují váš přístup ke správě životního cyklu. Ve druhé fázi vyvíjíte obsah a spravujete změny.

Správa změn obsahu během životního cyklu je důležitá k zajištění efektivní spolupráce mezi tvůrci obsahu a stabilním a konzistentním doručováním obsahu příjemcům.

Následující obrázek znázorňuje životní cyklus obsahu Power BI a zvýrazňuje fázi 2, kde vyvíjíte obsah a spravujete změny.

Poznámka:

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

Tip

Tento článek se zaměřuje na klíčová rozhodnutí a aspekty, které vám pomůžou vyvíjet obsah a spravovat změny v průběhu životního cyklu. Další pokyny k vývoji obsahu a správě změn najdete v tématech:

• Co je správa životního cyklu v Microsoft Fabric?: Tento článek obsahuje technický úvod a kurz integrace a kanálů nasazení Infrastruktury Git.
• Osvědčené postupy správy životního cyklu: Tento článek obsahuje praktické tipy a pokyny pro používání funkcí správy životního cyklu prostředků Fabric a Power BI k vývoji obsahu a správě změn.
• Integrace OneDrivu a SharePointu v Power BI Desktopu: Tento článek obsahuje přehled možností použití a ukládání souborů uložených na OneDrivu pro práci a školu nebo SharePointu při provádění správy verzí se soubory .pbix.
• Začínáme s Gitem v Azure Repos: Tato série článků obsahuje praktické tipy, kurzy a pokyny k provádění správy zdrojového kódu pomocí úložiště Git v Azure Repos.

Tvůrci obsahu a vlastníci by měli spravovat změny obsahu 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 usnadňuje efektivnější spolupráci a správu obsahu.

Mezi další výhody správy verzí patří možnost:

• Sloučení změn od několika tvůrců obsahu a zpracování konfliktů při slučování
• Určete, který obsah se změnil a co se v daném obsahu změnilo.
• Umožňuje propojit změny obsahu s konkrétními pracovními položkami.
• Seskupte změny do jedinečných verzí s historií verzí.
• Vrácení změn zpět nebo celých verzí obsahu

Tip

Pokud je to možné, doporučujeme používat správu verzí pro veškerý obsah, který vytvoříte. Použití správy verzí má významné výhody pro tvůrce obsahu i uživatele a snižuje riziko přerušení kvůli ztrátě souborů nebo nemožnosti vrátit zpět změny.

Prvním krokem k nastavení správy verzí je rozhodnout, jak budete vyvíjet obsah.

Rozhodnutí o tom, jak vyvíjet obsah

V závislosti na tom, jak obsah vytvoříte, se budete rozhodovat jinak. Například pro sestavy a sémantické modely Power BI má soubor Power BI Desktopu (.pbix) méně možností pro správu verzí ve srovnání s formátem projektu Power BI Desktopu (.pbip ). Je to proto, že soubor .pbix je binární formát, zatímco formát .pbip obsahuje textově čitelný obsah a metadata. Díky čitelnosti pro člověka a metadata můžete snadněji sledovat změny modelu a sestav pomocí správy zdrojového kódu. Správa zdrojového kódu spočívá v zobrazení a správě změn v obsahu jeho kódu a metadat.

Tip

Při vývoji sémantických modelů a sestav pomocí Power BI Desktopu doporučujeme místo souborů .pbix používat soubory .pbip. Při vývoji sémantických modelů pomocí nástrojů XMLA doporučujeme místo souborů .bim použít formát TMDL (Tabular Model Definition Language).

Formáty .pbip a TMDL podporují snadnější sledování a slučování změn na úrovni objektu. To znamená, že můžete zobrazit a spravovat změny jednotlivých objektů, jako jsou míry DAX nebo tabulky.

Power BI Desktop

Pomocí Power BI Desktopu můžete vytvářet sémantické modely nebo sestavy, které můžete uložit jako soubory .pbix nebo .pbip. Při používání Power BI Desktopu můžete použít i další vlastní soubory obsahu. Při vytváření obsahu pomocí Power BI Desktopu byste měli udělat některá klíčová rozhodnutí:

• Který formát souboru použít: Obsah můžete uložit buď jako soubory .pbix, nebo .pbip. Integrace Gitu například vyžaduje, abyste používali soubory .pbip, samoobslužní tvůrci můžou najít soubory .pbix jednodušší pro správu a údržbu v Teams, SharePointu nebo OneDrivu.
• Správa vlastního obsahu: Do souborů Power BI Desktopu můžete přidávat motivy, vlastní vizuály nebo obrázky, které můžou vyžadovat různé aspekty správy životního cyklu. Když například tvůrci obsahu vytvoří vlastní vizuály, měli by definici vizuálu uložit a spravovat v samostatném souboru.
• Správa funkcí ve verzi Preview: V Power BI Desktopu se můžete přihlásit k funkcím nebo nastavením verze Preview, které mění obsah a způsob jeho použití. Můžete například provést další kroky k ověření obsahu, který používá funkce preview.

Vytváření webů

Určitý obsah, jako jsou toky dat, řídicí panely a přehledy výkonnostních metrik, je možné vytvořit jenom na portálu Fabric. Na portálu Fabric nebo pomocí místních nástrojů můžete také vytvořit nebo upravit nějaký obsah, jako jsou sémantické modely, sestavy a stránkované sestavy. Při vytváření obsahu pomocí vytváření obsahu na webu byste měli udělat některá klíčová rozhodnutí, která byste měli udělat:

• Správa změn: Pomocí vytváření webu můžete provádět změny v mnoha typech položek, ale tyto změny se můžou okamžitě uložit a přepsat předchozí verze. Pokud například spolupracujete s ostatními, můžete se vyhnout vytváření webů na sdílených položkách a místo toho pracovat na vlastní kopii.
• Jak načíst zálohy obsahu: Pomocí vytváření webů můžete vytvářet obsah, jako jsou sestavy nebo sémantické modely, ale tyto položky nelze stáhnout do místních souborů .pbix. Můžete se například rozhodnout zálohovat tento obsah načtením a uložením jeho metadat.

Tip

Při vývoji toků dat a přehledů výkonnostních metrik doporučujeme načíst definice položek pro správu změn a uložení zálohy. Načtení toku dat a přehledu výkonnostních metrik můžete automatizovat pomocí rozhraní REST API prostředků infrastruktury. Konkrétně můžete použít koncové body Get Dataflow (Získat tok dat) a Get Scorecards (Získat přehledy výkonnostních metrik).

Upozornění

Některé obsahy , jako jsou řídicí panely, nemají možnost načíst definici. U tohoto obsahu nemůžete snadno sledovat změny ani načítat zálohy.

Další nástroje

K vytváření nebo správě určitých typů obsahu můžete použít jiné nástroje. Tyto nástroje mohou poskytovat další výhody, lépe vyhovovat vašemu pracovnímu postupu nebo být nutné ke správě konkrétních funkcí nebo typů obsahu. K vytváření a správě obsahu můžete použít jak jiné nástroje Microsoftu, tak nástroje třetích stran. Další nástroje, které můžete použít k vytvoření nebo správě obsahu, jsou následující.

• Visual Studio nebo Visual Studio Code: Integrované vývojové prostředí pro vývojáře, které umožňuje vytvářet a spravovat sémantické modely nebo poznámkové bloky Prostředků infrastruktury. V sadě Visual Studio i Visual Studio Code můžou vývojáři také provádět správu správy zdrojového kódu (SCM) potvrzením a nasdílením místních změn do vzdáleného úložiště.
• Tabulkový editor: Nástroj třetí strany pro vývoj a správu sémantických modelů.
• Excel: Klientský nástroj pro kontingenční tabulky a živé propojené tabulky, které pracují s sémantickým modelem.
• Power BI Tvůrce sestav: Desktopová aplikace pro vytváření souborů stránkované sestavy (.rdl).

Při vytváření obsahu pomocí jiných nástrojů byste měli udělat některá klíčová rozhodnutí:

• Správa licencí: Další nástroje můžou vyžadovat další licence, které byste měli spravovat.
• Publikování obsahu: Další nástroje můžou vyžadovat další kroky k publikování obsahu, například pomocí koncových bodů XMLA nebo rozhraní REST API Power BI.

Jakmile se rozhodnete, jak budete vytvářet obsah, budete si muset při vývoji vybrat, kam budete obsah publikovat a testovat.

Rozhodněte se, jak budete pracovní prostory nastavovat a používat.

Při vývoji obsahu byste měli použít více pracovních prostorů (nebo fází) k oddělení produkčního obsahu používaného organizací od vývoje nebo ověření obsahu. Použití samostatných pracovních prostorů pro váš obsah má několik výhod:

• Můžete vyvíjet a testovat obsah, aniž by to mělo vliv na obsah, který se právě používá. Tím se zabrání změnám, které můžou způsobit neúmyslné přerušení obsahu v produkčním prostředí.
• K vývoji a testování obsahu můžete použít samostatné prostředky, jako je použití samostatných bran dat nebo kapacit Fabric. Tím se zabrání tomu, aby prostředky používané pro vývoj a testování narušovaly produkční úlohy, což způsobuje pomalé aktualizace dat nebo sestavy.
• Strukturovanější proces pro vývoj, testování a vydávání obsahu můžete vytvořit tak, že pro každou z těchto fází budete mít samostatná prostředí. To vám pomůže zlepšit produktivitu.

V prostředcích infrastruktury a Power BI doporučujeme používat samostatné pracovní prostory prostředků infrastruktury, jak je popsáno v článcích o plánování na úrovni tenanta a na úrovni pracovního prostoru.

Důležité

Použití samostatných prostředí je základním krokem k zajištění úspěchu přístupu správy životního cyklu obsahu.

K oddělení prostředí existuje několik způsobů použití pracovních prostorů Fabric. Kromě místního prostředí obvykle ke správě obsahu během životního cyklu používáte dva nebo více pracovních prostorů.

Při plánování používání samostatných pracovních prostorů v průběhu životního cyklu tohoto obsahu odpovězte na následující otázky:

• Kolik pracovních prostorů potřebujete?
• Rozdělíte pracovní prostory podle typu položky?
• Kdo bude mít přístup ke každému pracovnímu prostoru?
• Budou pracovní prostory patřit do kanálu nasazení Fabric, nebo orchestrujete nasazení pomocí jiných přístupů, jako je použití Azure Pipelines?
• Jak budete spravovat publikování mezi pracovními prostory? Potřebujete například zajistit, aby se sestavy v testovacím pracovním prostoru připojily k sémantickým modelům v samostatném testovacím pracovním prostoru pro datové položky?
• Potřebujete také použít samostatné podpůrné prostředky pro položky v produkčních pracovních prostorech, jako je samostatný místní cluster brány dat?

Následující části obsahují základní přehled různých přístupů, které můžete použít k oddělení pracovních prostorů, abyste usnadnili správu životního cyklu.

Poznámka:

Následující části se zaměřují na to, jak můžete nastavit a používat samostatné pracovní prostory. Obsah můžete do těchto pracovních prostorů nasadit pomocí jednoho z následujících čtyř přístupů:

• Publikování z Power BI Desktopu
• Nasazení obsahu z jiného pracovního prostoru pomocí kanálů nasazení Fabric
• Synchronizace obsahu ze vzdáleného úložiště Git pomocí integrace Gitu
• Nasazování obsahu prostřednictvím kódu programu pomocí rozhraní REST API prostředků infrastruktury, rozhraní REST API Power BI nebo koncových bodů XMLA.

Další informace o těchto přístupech k nasazení obsahu najdete v části Fáze 4: Nasazení obsahu dále v této sérii.

Testovací a produkční pracovní prostory

Když doručíte jednodušší obsah, který není pro organizaci kritický, můžou často stačit dva pracovní prostory. V tomto scénáři mají tvůrci obsahu obvykle omezenou spolupráci na stejných položkách a místně vyvíjet obsah.

Následující diagram znázorňuje základní příklad použití samostatných prostředí pouze s testovacím a produkčním pracovním prostorem.

Diagram znázorňuje následující procesy a komponenty pro oddělení pracovních prostorů v tomto přístupu.

Položka	Popis
	Tvůrci obsahu vyvíjejí obsah ve svém místním prostředí.
	Jakmile je obsah připravený, tvůrci obsahu publikují obsah do testovacího pracovního prostoru. Tvůrci obsahu můžou vyvíjet obsah, který lze vytvářet pouze pomocí vytváření webu a provádět ověření obsahu v testovacím pracovním prostoru.
	Jakmile je obsah připravený, tvůrci obsahu nasadí obsah do produkčního pracovního prostoru. V produkčním pracovním prostoru tvůrci obsahu distribuují obsah publikováním aplikace Power BI nebo sdílením obsahu z pracovního prostoru.

Poznámka:

Existuje mnoho různých způsobů nastavení a používání samostatných pracovních prostorů a nasazení obsahu mezi těmito pracovními prostory. Doporučujeme ale neprovádět místní vývoj a publikovat obsah přímo do produkčního pracovního prostoru. To může vést k zabránění přerušení a chybám.

Vývojové, testovací a produkční pracovní prostory

Při doručování důležitého obchodního obsahu obvykle používáte tři nebo více samostatných pracovních prostorů. V tomto scénáři tvůrci obsahu často spolupracují v dalším vývojovém pracovním prostoru, který obsahuje nejnovější verzi řešení.

Následující diagram znázorňuje základní příklad použití samostatných prostředí s vývojovým, testovacím a produkčním pracovním prostorem.

Diagram znázorňuje následující procesy a komponenty pro oddělení pracovních prostorů v tomto přístupu.

Položka	Popis
	Tvůrci obsahu vyvíjejí obsah ve svém místním prostředí.
	Jakmile je obsah připravený, tvůrci obsahu publikují obsah do vývojového pracovního prostoru. V pracovním prostoru pro vývoj můžou tvůrci obsahu vyvíjet obsah, který lze vytvářet pouze pomocí vytváření webů. Tvůrci obsahu můžou také ověřit obsah ve vývojovém pracovním prostoru.
	Jakmile je obsah připravený, tvůrci obsahu nasadí obsah do testovacího pracovního prostoru. V testovacím pracovním prostoru uživatelé ověřují obsah buď v pracovním prostoru, nebo v aplikaci.
	Jakmile je obsah připravený, tvůrci obsahu nasadí obsah do produkčního pracovního prostoru. V produkčním pracovním prostoru tvůrci obsahu distribuují obsah publikováním aplikace Power BI nebo sdílením obsahu z pracovního prostoru.

Poznámka:

S kanály nasazení můžete použít až deset různých prostředí. Můžete například chtít mít předprodukční prostředí mezi testováním a produkčním prostředím, které je určené speciálně pro speciální typy ověřování, jako je testování výkonu.

Privátní pracovní prostor s integrací Gitu

Při doručování důležitého obchodního obsahu může každý vývojář pro vývoj používat také svůj vlastní soukromý pracovní prostor. V tomto scénáři soukromý pracovní prostor umožňuje tvůrcům obsahu testovat obsah na portálu Fabric nebo používat funkce, jako je plánovaná aktualizace, aniž by riskovali přerušení práce ostatních ve vývojovém týmu. Tvůrci obsahu můžou také vyvíjet obsah na portálu Fabric, například na tocích dat. Soukromé pracovní prostory můžou být dobrou volbou při správě změn obsahu pomocí integrace Gitu spolu s Azure DevOps.

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.

Následující diagram znázorňuje obecný příklad použití samostatných prostředí pomocí privátního pracovního prostoru s integrací Gitu.

Poznámka:

Diagram znázorňuje samostatné vývojáře pracující na samostatných větvích řešení (větev jedna a druhá) před sloučením změn do hlavní větve. Toto je zjednodušené znázornění strategie větvení Gitu, která ilustruje, jak můžou vývojáři integrovat své změny se vzdáleným úložištěm Git a těžit z integrace Gitu v prostředcích infrastruktury.

Diagram znázorňuje následující procesy a komponenty pro oddělení pracovních prostorů v tomto přístupu.

Položka	Popis
	Každý tvůrce obsahu vyvíjí obsah ve vlastním místním prostředí.
	Až budete připravení, tvůrci obsahu potvrdí a nasdílí změny do vzdáleného úložiště, jako je úložiště Git v Azure Repos.
	Ve vzdáleném úložišti Git tvůrci obsahu sledují a spravují změny obsahu pomocí správy zdrojového kódu a větvení a slučují obsah, aby usnadnili spolupráci.
	Tvůrci obsahu synchronizují větev vzdáleného úložiště s privátním pracovním prostorem. Po synchronizaci se v privátním pracovním prostoru zobrazí nejnovější změny, které autor potvrdí a nasdílí do větve. Různí tvůrci obsahu pracují samostatně, oddělují větve při provádění změn.
	V soukromých pracovních prostorech můžou tvůrci obsahu vyvíjet obsah pomocí vytváření webu a ověřovat vlastní změny. Změny obsahu vytvořeného webem se můžou synchronizovat s větví v úložišti Git, když tvůrce obsahu potvrdí a nasdílí tyto změny z pracovního prostoru. Různí tvůrci obsahu pracují ve svých vlastních samostatných soukromých pracovních prostorech.
	Jakmile jsou tvůrci obsahu připravení, vytvoří žádost o přijetí změn, aby své změny sloučili do hlavní větve řešení.
	Po sloučení změn se hlavní větev synchronizuje s pracovním prostorem pro vývoj.
	V pracovním prostoru pro vývoj můžou tvůrci obsahu vyvíjet obsah, který integrace Infrastruktury Git nepodporuje, například řídicí panely. Tvůrci obsahu také ověřují integrované řešení, které obsahuje všechny nejnovější změny.
	Jakmile je obsah připravený, tvůrci obsahu nasadí obsah do testovacího pracovního prostoru. V testovacím pracovním prostoru uživatelé provádějí testování obsahu pro přijetí uživatele.
	Jakmile je obsah připravený, tvůrci obsahu nasadí obsah do produkčního pracovního prostoru. V produkčním pracovním prostoru tvůrci obsahu distribuují obsah publikováním aplikace Power BI nebo sdílením obsahu z pracovního prostoru.

Podpůrné prostředky pro pracovní prostory

Pokud používáte samostatná prostředí, měli byste také zvážit, jak to ovlivní různé podpůrné prostředky, které v těchto prostředích používáte. U těchto podpůrných prostředků zvažte, jestli je také potřebujete oddělit do stejného počtu fází nebo jak budete koordinovat jejich použití v těchto prostředích.

• Brány: Zvažte použití samostatných clusterů místních bran dat a bran virtuálních sítí pro produkční úlohy. To je užitečné, pokud chcete zabránit přerušení, ale také zajistit dobu provozu, když potřebujete tyto brány aktualizovat.
• Aplikace: Zvažte použití samostatných aplikací pro testovací a produkční pracovní prostory. Mezi fázemi není možné nasazovat ani kopírovat aplikace. Aplikace v testovacím pracovním prostoru vám pomůžou otestovat obsah a prostředí aplikace před nasazením změn do produkčního pracovního prostoru. Aplikace v produkčním pracovním prostoru jsou určené k doručování obsahu koncovým uživatelům ve strukturovaném prostředí a prostředí.
• Azure DevOps: Pokud máte v úmyslu používat Azure DevOps ke spolupráci a orchestraci správy zdrojového kódu a nasazení, zvažte, jak budete používat větve a Azure Pipelines k nasazení obsahu mezi těmito prostředími. Další informace o použití Služby Azure Pipelines k nasazení obsahu najdete v tématu Fáze 4: Nasazení obsahu.

Jakmile se rozhodnete, jak budete pracovní prostory nastavovat a používat, je dalším krokem rozhodnutí, jak budete provádět správu verzí ke sledování a správě změn obsahu.

Rozhodněte se, jak budete používat správu verzí.

V Power BI můžete provádět správu verzí buď pomocí SharePointu nebo OneDrivu, nebo pomocí vzdáleného úložiště Git, jako je Azure Repos, což je součást Azure DevOps. V obou přístupech přidáte místní soubory obsahu do vzdáleného umístění úložiště, abyste mohli sledovat a spravovat změny. Doporučujeme používat SharePoint nebo OneDrive jenom pro menší a jednodušší projekty, protože nemá funkce a robustnost pro podporu větších nebo složitějších scénářů.

Tady je několik obecných aspektů, které vám pomůžou nastavit a používat správu verzí.

• Upozornění: Měli byste nastavit výstrahy pro, když ostatní přidávají, odebírat nebo upravovat důležité soubory.
• Rozsah: Jasně definujte rozsah umístění vzdáleného úložiště. V ideálním případě je rozsah umístění vzdáleného úložiště stejný jako obor 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 ke vzdálenému umístění úložiště 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 umístění vzdáleného úložiště.
• Dokumentace: Přidejte do vzdáleného umístění úložiště textové soubory, které popisují umístění vzdáleného úložiště a jeho účel, vlastnictví, přístup a definované procesy.

Následující části popisují jednotlivé přístupy a klíčové aspekty rozhodování, které z nich byste měli použít.

Správa verzí pomocí SharePointu nebo OneDrivu pro práci a školu

SharePoint má integrovanou správu verzí pro soubory. Tvůrci obsahu můžou vyvíjet sémantické modely nebo sestavy místně a jejich změny se synchronizují do knihovny dokumentů SharePointu nebo OneDrivu pro práci a školu.

Tip

SharePoint nebo OneDrive používejte jenom pro správu verzí v jednodušších a menších scénářích, jako je samoobslužné publikování obsahu. V případě větších nebo složitějších scénářů byste měli zvážit provedení správy zdrojového kódu pomocí vzdáleného úložiště Git.

Následující diagram znázorňuje základní přehled o tom, jak provádět správu verzí pomocí SharePointu nebo OneDrivu.

Diagram popisuje následující procesy a komponenty.

Položka	Popis
	Tvůrci obsahu vyvíjejí sémantické modely a sestavy v místním prostředí a ukládají tyto modely a sestavy jako soubory .pbix.
	Až budou připravení, tvůrci obsahu uloží změny, které synchronizují se vzdáleným SharePointem nebo OneDrivem pro práci a školní knihovnu.
	Tvůrci obsahu ve vzdálené knihovně sledují změny na úrovni souborů, které usnadňují správu verzí.
	Tvůrci obsahu můžou propojit publikovaný sémantický model nebo sestavu se souborem .pbix, aby usnadnili aktualizaci OneDrivu. Aktualizace OneDrivu automaticky publikuje změny obsahu každou hodinu.
	V pracovním prostoru Prostředky infrastruktury uvidí tvůrci obsahu změny obsahu Power BI po dokončení aktualizace OneDrivu.

Důležité

Správu verzí můžete provádět jenom pomocí SharePointu nebo OneDrivu pro soubory Power BI Desktopu, které obsahují sémantické modely nebo sestavy. Správu verzí nemůžete snadno provádět pomocí SharePointu nebo OneDrivu pro jiné typy položek Power BI, jako jsou toky dat, nebo pro typy položek infrastruktury, jako jsou poznámkové bloky. U těchto dalších typů položek byste měli provádět správu verzí pomocí vzdáleného úložiště Git, jako je Azure Repos.

Tvůrci obsahu můžou shrnout publikovaný sémantický model nebo sestavu se souborem .pbix uloženým v SharePointu nebo OneDrivu pro práci a školní knihovně. Díky tomuto přístupu už tvůrci obsahu nemusí publikovat sémantický model, aby viděli změny. Místo toho se změny zobrazí po automatické aktualizaci OneDrivu, ke které dochází každou hodinu. I když je tento přístup pohodlný, má určité aspekty a nedá se snadno vrátit zpět.

Správa verzí s SharePointem nebo OneDrivem je sice snadná, ale správa verzí má víc omezení. Například není možné zobrazit změny v obsahu a není také možné porovnávat verze. Kromě toho není možné nastavit sofistikovanější procesy pro správu těchto změn (například větvení nebo žádosti o přijetí změn popsané dále v tomto článku).

Zvažte použití SharePointu nebo OneDrivu ke sledování a správě změn v následujících scénářích:

• Obsah se skládá jenom ze sémantických modelů nebo sestav uložených jako soubory .pbix.
• Uživatelé samoobslužných služeb vytvářejí a spravují obsah.
• Tvůrci obsahu spolupracují pomocí Microsoft Teams.
• Tvůrci obsahu jsou nezkušení pomocí Gitu a správy správy správy zdrojového kódu.
• Tvůrci obsahu spravují jednu položku s omezenou složitostí a spolupráci.
• Soubory .pbix mají použitý popisek citlivosti, který šifruje jejich obsah.

Poznámka:

OneDrive a SharePoint podporují obsah s použitými popisky citlivosti s výjimkou některých omezených scénářů. Integrace Infrastruktury Git naproti tomu nepodporuje popisky citlivosti.

Nepoužívejte SharePoint nebo OneDrive ke sledování a správě změn v následujících scénářích:

• Obsah se skládá z jiných typů položek než sémantických modelů a sestav.
• Obsah je složitý nebo velký v oboru.
• Tvůrci obsahu musí spolupracovat na stejné položce najednou.

Následující části popisují další aspekty efektivního používání správy verzí pomocí SharePointu nebo OneDrivu s Power BI.

Integrace s Microsoft Teams

Knihovny dokumentů z Microsoft Teams můžete použít, pokud ho tvůrci obsahu používají pro spolupráci. Knihovny dokumentů jsou sharepointové weby a použití knihoven dokumentů (místo samostatného sharepointového webu nebo složky OneDrivu) zajišťuje centralizaci obsahu, souborů a spolupráce.

Vrácení se změnami a rezervace souborů

Měli byste rezervovat soubory, na kterých pracujete, abyste se vyhnuli možným konfliktům změn. Po dokončení změn se přihlaste se změnami soubory s komentáři, které popisují změnu. Vrácení souborů se žádostí o vrácení se se žádostí o rezervaci vám pomůže zlepšit spolupráci mezi tvůrci obsahu, když používáte SharePoint nebo OneDrive pro práci a školu pro správu verzí. Pokud soubory vrátit se změnami a rezervovat s více tvůrci obsahu, můžete knihovnu sharepointového webu upravit tak, aby se zobrazila poslední aktualizace a komentáře posledního vrácení se změnami.

Historie verzí

V případě neočekávaných přerušení knihovny dokumentů sharepointového webu se ujistěte, že zálohujete obsah do samostatného umístění. Měli byste také nastavit omezení počtu verzí uložených na sharepointovém webu a odstranit staré verze. Tím zajistíte, že historie verzí zůstane smysluplná a nezabírají příliš mnoho místa.

Pro sofistikovanější správu verzí můžete ukládat soubory ve vzdáleném úložišti, jako je Azure Repos, a spravovat změny pomocí správy zdrojového kódu.

Správa zdrojového kódu pomocí vzdáleného úložiště Git

Vzdálené úložiště Git usnadňuje správu zdrojového kódu souborů, což umožňuje tvůrcům obsahu více možností sledovat a spravovat změny. Stručně řečeno, tvůrci obsahu můžou vyvíjet obsah místně nebo v služba Power BI a pak tyto změny potvrdit a odeslat do vzdáleného úložiště Git, jako je Azure Repos.

Poznámka:

Můžete také provádět správu zdrojového kódu obsahu bez použití integrace Gitu. V tomto scénáři stále sledujete a spravujete změny obsahu ve vzdáleném úložišti Git, ale obsah nasazujete pomocí rozhraní REST API nebo koncových bodů čtení a zápisu XMLA. Další informace o těchto metodách nasazení obsahu najdete ve fázi 4: Nasazení obsahu.

Následující diagram znázorňuje základní přehled toho, jak provádíte správu zdrojového kódu.

Diagram popisuje následující procesy a komponenty.

Položka	Popis
	Tvůrci obsahu vyvíjejí sémantické modely a sestavy v místním prostředí a ukládají tyto modely a sestavy jako soubory .pbip. Tvůrci obsahu mohou také vyvíjet sémantické modely a ukládat metadata modelu.
	Až budou připravení, tvůrci obsahu uloží změny, které potvrdí a nasdílí do vzdáleného úložiště Git v pravidelných intervalech.
	Ve vzdáleném úložišti Git tvůrci obsahu sledují změny na úrovni objektů, což usnadňuje správu verzí. Tvůrci obsahu můžou také vytvářet větve pro práci s obsahem a sloučit změny do jedné větve pomocí žádostí o přijetí změn.
	Tvůrci obsahu můžou synchronizovat obsah ze vzdáleného úložiště pomocí integrace Gitu. Můžou také nasadit obsah pomocí jiných přístupů, jako je Azure Pipelines, společně s rozhraními REST API.
	V pracovním prostoru Prostředky infrastruktury uvidí tvůrci obsahu změny obsahu Power BI po dokončení synchronizace nebo nasazení. Tvůrci obsahu můžou vytvářet obsah, jako jsou toky dat nebo poznámkové bloky v pracovním prostoru. Pokud používají integraci Gitu, tvůrci obsahu propojí tento pracovní prostor s konkrétní větví vzdáleného úložiště.
	Tvůrci obsahu můžou potvrdit a odeslat změny z pracovního prostoru do vzdáleného úložiště pomocí integrace Gitu. Tyto změny můžou importovat definice položek pro podporovaný obsah vytvořený v pracovním prostoru, jako jsou toky dat a poznámkové bloky.

V souhrnu tvůrci obsahu ukládají soubory .pbip, soubory metadat a dokumentaci do centrálního vzdáleného úložiště 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ější možnosti pro sledování a správu změn v porovnání se SharePointem a OneDrivem. 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.

Zvažte použití správy zdrojového kódu ke sledování a správě změn v následujících scénářích:

• Centralizované nebo decentralizované týmy vytvářejí a spravují obsah.
• Tvůrci obsahu spolupracují pomocí Azure DevOps.
• Tvůrci obsahu znají principy Gitu, správy správy zdrojového kódu nebo DataOps.
• Tvůrci obsahu spravují složitý nebo důležitý obsah nebo očekávají, že se obsah škáluje a zvýší složitost a důležitost.

Tady jsou některé požadavky a důležité informace, které vám pomůžou efektivně používat správu zdrojového kódu s Azure DevOps.

• Git: Pokud chcete potvrdit a odeslat změny do vzdáleného úložiště, musí tvůrci obsahu stáhnout a nainstalovat Git. 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?.
• Nástroje: Aby mohli tvůrci obsahu používat Git, musí buď použít rozhraní příkazového řádku (CLI), nebo grafického uživatelského rozhraní (GUI) pro SCM, jako je Visual Studio nebo Visual Studio Code.
• Licence a oprávnění: Pokud chcete vytvořit a používat úložiště Git Azure Repos, musí mít tvůrci obsahu následující:
  • Úroveň přístupu nastavená na úroveň Basic (na rozdíl od účastníka).
  • Patří do organizace a projektu.
  • Příslušná oprávnění úložiště.
• Integrace Gitu s prostředky infrastruktury: K synchronizaci obsahu ve vzdáleném úložišti s pracovním prostorem Microsoft Fabric používají tvůrci obsahu integraci s Gitem infrastruktury. To je důležité ke sledování a správě změn obsahu vytvořeného na portálu Fabric, jako jsou toky dat.

Tip

Pro usnadnění správy zdrojového kódu s místním vývojem doporučujeme použít klientskou aplikaci, jako je Visual Studio Code. Pomocí Power BI Desktopu můžete vyvíjet obsah a pak pomocí editoru Visual Studio Code provádět správu správy zdrojového kódu tohoto obsahu přípravou, potvrzením a nasdílením změn do vzdáleného úložiště.

Upozorňující

Integrace Gitu s prostředky infrastruktury má určitá omezení podporovaných položek a scénářů. Nejprve ověřte, jestli integrace Infrastruktury Git nejlépe vyhovuje vašemu konkrétnímu scénáři, nebo jestli byste měli použít jiný přístup k implementaci správy zdrojového kódu.

Kromě toho se popisky citlivosti v integraci Gitu s prostředky infrastruktury nepodporují a export položek s popisky citlivosti může být zakázaný. Pokud má váš obsah popisky citlivosti, měli byste naplánovat, jak můžete dosáhnout správy verzí a zároveň dodržovat zásady ochrany před únikem informací.

Klíčovou výhodou používání správy zdrojového kódu se službou Azure Repos je vylepšená spolupráce mezi tvůrci obsahu a lepším přizpůsobením a dohledem nad změnami obsahu a nasazením.

Následující diagram znázorňuje základní přehled toho, jak Azure DevOps umožňuje spolupráci se správou zdrojového kódu.

Poznámka:

Předchozí diagram znázorňuje jeden příklad spolupráce pomocí Azure DevOps. Zvolte přístup, který nejlépe vyhovuje potřebám a způsobu práce vašeho týmu.

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

Položka	Popis
	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.
	Tvůrce obsahu potvrdí své změny do místního úložiště během vývoje.
	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.
	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ě.
	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.
	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.
	Jakmile je tvůrce obsahu připravený, otevře žádost o přijetí změn, která větev funkce sloučí do hlavní větve.
	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.
	Ú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.
	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.
	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.
	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í.
	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.
	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í.

Následující části popisují další aspekty efektivního používání správy zdrojového kódu pomocí Azure DevOps a Power BI.

Důležité

Efektivní použití větvení, potvrzení, žádostí o přijetí změn a slučování je nezbytné pro většinu výhod správy zdrojového kódu při správě životního cyklu obsahu Power BI.

Použití větví

Tvůrci obsahu dosáhnou spolupráce pomocí strategie větvení. Strategie větvení umožňuje jednotlivým tvůrcům obsahu pracovat 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 s popisnou zprávou potvrzení. Zpráva potvrzení popisuje změny provedené v tomto potvrzení.

Pokud ke správě obsahu infrastruktury používáte strategii větvení, zvažte následující faktory.

• Kteří tvůrci obsahu větve by měli klonovat pro svou vlastní práci. Pokud jsou například tyto větve klonem hlavní větve (označované jako vývoj založený na kmeni) nebo pokud se jedná o jiné větve, jako jsou větve vydaných verzí pro konkrétní plánované verze obsahu.
• Určení rozsahu konkrétní práce na různé verze obsahu pomocí větví vydané verze.
• Které větve se připojují k jakému pracovnímu prostoru při použití integrace Gitu s prostředky infrastruktury.

Tip

Informace o tom, jak efektivně usnadnit spolupráci, najdete v tématu Přijetí strategie větvení gitu pro konkrétní pokyny a doporučení k tomu, jak nejlépe využít strategii větvení.

Dávkové změny v potvrzeních

Při vývoji obsahu by tvůrci měli pravidelně provádět změny v dávkách (nebo skupinách). Tyto změny by měly řešit konkrétní pracovní položku řešení (například funkce nebo problém). Až budete připravení, tvůrci obsahu potvrdí tyto fázované změny.

Dávkování změn tímto způsobem má několik výhod.

• Pomáhá strukturovat vývoj a dává tvůrcům obsahu šanci zkontrolovat a zdokumentovat změny, které seskupili.
• Zlepšuje soulad mezi plánováním a vývojem, což usnadňuje propojení funkcí a problémů a zajištění transparentnosti o tom, jak práce pokračuje.
• Technické vlastníky můžou snadněji kontrolovat žádosti o přijetí změn od tvůrců obsahu, pokud jsou změny dávkové a mají jasné zprávy o potvrzení.

Při fázi a potvrzení změn obsahu Power BI zvažte následující faktory.

• Bez ohledu na to, jestli připravíte a potvrdíte změny z místního úložiště nebo z pracovního prostoru Fabric.
• Soubory .pbip umístěte do složek nejvyšší úrovně při ukládání více modelů nebo sestav do jednoho úložiště. To vám usnadní identifikaci a seskupení změn, které uděláte.
• Pomocí souboru gitignore nebo souboru .gitattributes ignorujte neužitečné nebo neužitečné změny metadat. Tím zajistíte, že všechny změny, které potvrdíte, budou smysluplné.

Tip

Konkrétní pokyny a doporučení týkající se fáze a potvrzení práce do úložiště Git najdete v tématu Uložení práce s potvrzeními .

Vytvoření žádostí o přijetí změn pro sloučení změn

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ů.

Pokud ke sloučení změn v obsahu Power BI používáte žádosti o přijetí změn, zvažte následující faktory.

• Jaké standardy a postupy použijete k provedení kontroly, pokud existuje. Můžete například použít pravidla z Analyzátoru osvědčených postupů pro sémantické modely.
• Jak zkontrolujete změny metadat sestavy, což není snadné číst a pochopit bez použití nástrojů třetích stran.
• Jak vyřešíte konflikty při slučování a vyřešíte je.

Tip

Informace o žádostech o přijetí změn a strategiích sloučení a squash sloučení najdete v konkrétních doprovodných materiálech a doporučeních k tomu, jak nejlépe využít žádosti o přijetí změn k usnadnění spolupráce sloučením změn s obsahem.

Kontrolní seznam – Při plánování, kam budete ukládat soubory, klíčová rozhodnutí a akce, patří:

• Vyberte si vývojové nástroje: Zajistěte, aby přístup k vývoji obsahu odpovídal způsobu spolupráce s ostatními tvůrci obsahu a používání správy verzí.
• Volba mezi formáty .pbip a .pbix pro modely a sestavy: Formát .pbip je obvykle vhodnější pro správu zdrojového kódu, ale uživatelé samoobslužných služeb můžou soubory .pbix snadněji používat.
• Samostatný sémantický model a vývoj sestav: Správa verzí je nejúčinnější při správě změn pro různé typy položek samostatně. Oddělení vývoje modelů a sestav se považuje za osvědčený postup.
• Rozhodněte se, kolik pracovních prostorů potřebujete: Použití samostatných prostředí je důležité pro úspěch správy životního cyklu obsahu. Ujistěte se, že jste si vysvětlili, kolik pracovních prostorů potřebujete, a proveďte odpovídající plánování na úrovni pracovního prostoru.
• Rozhodněte se, jak budete implementovat správu verzí: Rozhodněte se mezi jednodušším přístupem pomocí SharePointu nebo OneDrive pro firmy nebo pomocí Azure DevOps, abyste usnadnili správu zdrojového kódu.
• Nastavení vzdáleného úložiště: Vytvořte strukturovaný prostor ve složce OneDrivu nebo v úložišti Git, kam budete ukládat obsah pro sledování a správu změn.
• Pokud používáte správu zdrojového kódu, nastavte soubory .gitignore a .gitattributes: Ujistěte se, že jste nastavili úložiště, abyste sledovali jenom smysluplné změny.
• Pokud používáte správu zdrojového kódu, definujte strategie větvení a slučování: Ujistěte se, že definujete jasné procesy pro nastavení a použití správy zdrojového kódu k zajištění nejlepší podpory vývoje. Vyhněte se překomplikování vašeho procesu. Místo toho se pokuste doplnit aktuální způsob práce ve vývojových týmech.

Související obsah

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