Osvědčené postupy správy životního cyklu

Tento článek obsahuje pokyny pro tvůrce dat a analýz, kteří spravují svůj obsah v průběhu životního cyklu v Microsoft Fabric. Tento článek se zaměřuje na použití integrace Gitu pro kanály správy zdrojového kódu a nasazení jako nástroje pro vydávání verzí. Obecné pokyny k publikování podnikového obsahu najdete v publikování podnikového obsahu.

Důležité

Tato funkce je ve verzi Preview.

Článek je rozdělený do čtyř částí:

• Příprava obsahu – Příprava obsahu na správu životního cyklu

• Vývoj – Seznamte se s nejlepšími způsoby vytváření obsahu ve fázi vývoje kanálů nasazení.

• Test – Zjistěte, jak použít testovací fázi kanálů nasazení k otestování vašeho prostředí.

• Produkční – Pomocí produkční fáze kanálů nasazení zpřístupněte obsah ke spotřebě.

Příprava obsahu

Pokud chcete co nejlépe připravit obsah na probíhající správu v průběhu celého životního cyklu, přečtěte si informace v této části, než začnete:

• Uvolněte obsah do produkčního prostředí.

• Začněte používat kanál nasazení pro konkrétní pracovní prostor.

Oddělení vývoje mezi týmy

Různé týmy v organizaci mají obvykle různé odborné znalosti, vlastnictví a metody práce, i když pracují na stejném projektu. Je důležité nastavit hranice a zároveň dát každému týmu nezávislost, aby fungovala tak, jak se jim líbí. Zvažte použití samostatných pracovních prostorů pro různé týmy. V samostatných pracovních prostorech může mít každý tým různá oprávnění, pracovat s různými úložištěmi správy zdrojového kódu a dodávat obsah do produkčního prostředí v jiném tempu. Většina položek se může připojit a používat data napříč pracovními prostory, takže neblokuje spolupráci na stejných datech a projektu.

Plánování modelu oprávnění

Integrace Gitu i kanály nasazení vyžadují jiná oprávnění než jenom oprávnění pracovního prostoru. Přečtěte si o požadavcích na oprávnění pro kanály integrace a nasazení Gitu.

Pokud chcete implementovat zabezpečený a snadný pracovní postup, naplánujte, kdo získá přístup k jednotlivým částem používaných prostředí, a to jak úložiště Git, tak fáze vývoje/testování/prod v kanálu. Mezi aspekty, které je třeba vzít v úvahu, patří:

• Kdo by měl mít přístup ke zdrojovému kódu v úložišti Git?

• Které operace by měli uživatelé s přístupem ke kanálu provádět v každé fázi?

• Kdo kontrolovat obsah ve fázi testu?

• Mají mít revidoři testovací fáze přístup ke kanálu?

• Kdo by měl dohlížet na nasazení do produkční fáze?

• Který pracovní prostor přiřazujete ke kanálu nebo se připojujete k Gitu?

• Ke které větvi připojujete pracovní prostor? Jaké jsou zásady definované pro danou větev?

• Sdílí se pracovní prostor více členy týmu? Mají provádět změny přímo v pracovním prostoru nebo pouze prostřednictvím žádostí o přijetí změn?

• Ke které fázi přiřazujete pracovní prostor?

• Potřebujete změnit oprávnění pracovního prostoru, který přiřazujete?

Připojení různých fázích různých databází

Produkční databáze by měla být vždy stabilní a dostupná. Není nejlepší ho přetížit dotazy vygenerovanými tvůrci BI pro své vývojové nebo testovací sémantické modely. Sestavte samostatné databáze pro vývoj a testování, abyste ochránili produkční data a nepřetěžujte vývojovou databázi celým objemem produkčních dat.

Použití parametrů pro konfigurace, které se změní mezi fázemi

Kdykoli je to možné, přidejte do jakékoli definice parametry , které by se mohly změnit mezi fázemi vývoje, testování a prod. Použití parametrů vám pomůže snadno změnit definice, když přesunete změny do produkčního prostředí. I když v prostředcích infrastruktury stále neexistuje jednotný způsob správy parametrů, doporučujeme ho použít u položek, které podporují jakýkoli typ parametrizace. Parametry mají různá použití, například definování připojení ke zdrojům dat nebo interní položky v prostředcích infrastruktury. Dají se také použít k provádění změn dotazů, filtrů a textu zobrazených uživatelům.
V kanálech nasazení můžete nakonfigurovat pravidla parametrů tak, aby nastavily různé hodnoty pro každou fázi nasazení.

Vývoj

Tato část obsahuje pokyny pro práci s kanály nasazení a použití vhodné pro vaši fázi vývoje.

Zálohování práce do úložiště Git

S integrací Gitu může každý vývojář zálohovat svou práci tím, že ji potvrdí do Gitu. Pokud chcete správně zálohovat svoji práci v prostředcích infrastruktury, tady jsou některá základní pravidla:

• Ujistěte se, že máte izolované prostředí pro práci, aby ostatní nepřepsali vaši práci, než se potvrdí. To znamená, že pracujete v desktopovém nástroji (například VS Code, Power BI Desktopu nebo jiných) nebo v samostatném pracovním prostoru, ke kterému nemají přístup jiní uživatelé.

• Potvrďte větev, kterou jste vytvořili, a žádný jiný vývojář ji nepoužívá. Pokud pracovní prostor používáte jako prostředí pro vytváření obsahu, přečtěte si informace o práci s větvemi.

• Potvrďte společně změny, které musí být nasazeny společně. Toto doporučení platí pro jednu položku nebo více položek, které souvisejí se stejnou změnou. Potvrzení všech souvisejících změn vám může později pomoct při nasazování do jiných fází, vytváření žádostí o přijetí změn nebo vrácení změn zpět.

• Velké potvrzení můžou dosáhnout limitu maximální velikosti potvrzení. Mějte na paměti počet položek, které společně zapíšete, nebo celkovou velikost položky. Sestavy se například můžou při přidávání velkých obrázků zvětšit. V systémech správy zdrojového kódu je vhodné ukládat velké položky, i když to funguje. Zvažte způsoby, jak zmenšit velikost položek, pokud mají velké množství statických prostředků, jako jsou obrázky.

Vrácení změn zpět

Po zálohování práce může docházet k případům, kdy se chcete vrátit k předchozí verzi a obnovit ji v pracovním prostoru. Existuje několik způsobů, jak se vrátit k předchozí verzi:

• Tlačítko Zpět: Operace Zpět je snadným a rychlým způsobem, jak vrátit okamžité změny, které jste udělali, pokud ještě nejsou potvrzeny. Jednotlivé položky můžete také vrátit zpět samostatně. Přečtěte si další informace o operaci vrácení zpět .

• Návrat ke starším potvrzením: Neexistuje žádný přímý způsob, jak se vrátit k předchozímu potvrzení v uživatelském rozhraní. Nejlepší možností je zvýšit úroveň staršího potvrzení na HEAD pomocí příkazu git revert nebo resetování gitu. Když to uděláte, zobrazí se v podokně správy zdrojového kódu aktualizace a pracovní prostor můžete aktualizovat pomocí tohoto nového potvrzení.

Vzhledem k tomu, že data nejsou uložená v Gitu, mějte na paměti, že vrácení položky dat do starší verze může narušit stávající data a může vyžadovat, abyste data zahodili nebo operace mohla selhat. Před vrácením změn zpět to zkontrolujte předem.

Práce s privátním pracovním prostorem

Pokud chcete pracovat izolovaně, použijte samostatný pracovní prostor jako izolované prostředí. Přečtěte si další informace o izolování pracovního prostředí při práci s větvemi. Pro optimální pracovní postup pro vás a tým zvažte následující body:

• Nastavení pracovního prostoru: Než začnete, ujistěte se, že můžete vytvořit nový pracovní prostor (pokud ho ještě nemáte), že ho můžete přiřadit ke kapacitě Fabric a že máte přístup k datům pro práci v pracovním prostoru.

• Vytvoření nové větve: Vytvořte novou větev z hlavní větve, takže máte nejaktuálnější verzi obsahu. Také se ujistěte, že se připojujete ke správné složce ve větvi, abyste mohli do pracovního prostoru načíst správný obsah.

• Malé, časté změny: Osvědčeným postupem Gitu je provést malé přírůstkové změny, které se dají snadno sloučit a méně pravděpodobné, že se dostanou do konfliktů. Pokud to není možné, nezapomeňte nejprve aktualizovat větev z hlavní větve, abyste mohli konflikty vyřešit sami.

• Změny konfigurace: V případě potřeby změňte konfigurace v pracovním prostoru, abyste mohli pracovat efektivněji. Některé změny můžou zahrnovat propojení mezi položkami nebo různé zdroje dat nebo změny parametrů u dané položky. Nezapomeňte, že cokoli, co potvrdíte, se stane součástí potvrzení a může se omylem sloučit do hlavní větve.

Úprava práce pomocí klientských nástrojů

U položek a nástrojů, které ji podporují, může být snazší pracovat s klientskými nástroji pro vytváření, jako je Power BI Desktop pro sémantické modely a sestavy, VSCode pro poznámkové bloky atd. Tyto nástroje můžou být vaším místním vývojovými prostředími. Po dokončení práce nasdílejte změny do vzdáleného úložiště a synchronizujte pracovní prostor, aby se změny nahrály. Jen se ujistěte, že pracujete s podporovanou strukturou položky, kterou autorujete. Pokud si nejste jistí, nejprve naklonujte úložiště s obsahem, který je už synchronizovaný do pracovního prostoru, a začněte vytvářet obsah odsud, kde už je struktura na místě.

Správa pracovních prostorů a větví

Vzhledem k tomu, že pracovní prostor je možné připojit pouze k jedné větvi najednou, doporučuje se s tímto mapováním považovat 1:1. Pokud ale chcete snížit objem pracovního prostoru, který zahrnuje, zvažte tyto možnosti:

• Pokud vývojář nastaví soukromý pracovní prostor se všemi požadovanými konfiguracemi, může tento pracovní prostor dál používat pro jakoukoli budoucí větev, kterou vytvoří. Když sprint skončí, vaše změny se sloučí a spustíte nový úkol, stačí přepnout připojení k nové větvi ve stejném pracovním prostoru. Můžete to udělat také v případě, že najednou potřebujete opravit chybu uprostřed sprintu. Představte si ho jako pracovní adresář na webu.

• Vývojáři, kteří používají klientský nástroj (například VS Code, Power BI Desktop nebo jiné), nemusí nutně potřebovat pracovní prostor. Můžou vytvořit větve a potvrdit změny v této větvi místně, odeslat je do vzdáleného úložiště a vytvořit žádost o přijetí změn do hlavní větve, a to vše bez pracovního prostoru. Pracovní prostor je potřeba jenom jako testovací prostředí, které kontroluje, jestli všechno funguje v reálném scénáři. Je na vás, abyste se rozhodli, kdy se to má stát.

Duplikování položky v úložišti Git

Duplikování položky v úložišti Git:

1. Zkopírujte celý adresář položek.
2. Změňte logické ID na něco jedinečného pro tento připojený pracovní prostor.
3. Změňte zobrazovaný název tak, aby se odlišil od původní položky a aby nedocházelo k chybě duplicitního zobrazovaného názvu.
4. V případě potřeby aktualizujte logické ID a/nebo zobrazované názvy v jakýchkoli závislostech.

Test

Tato část obsahuje pokyny pro práci s testovací fází kanálů nasazení.

Simulace produkčního prostředí

Je důležité vidět, jak bude navržená změna mít vliv na produkční fázi. Testovací fáze kanálů nasazení umožňuje simulovat skutečné produkční prostředí pro účely testování. Alternativně to můžete simulovat připojením Gitu k jinému pracovnímu prostoru.

Ujistěte se, že se ve vašem testovacím prostředí řeší tyto tři faktory:

• Objem dat

• Objem využití

• Podobná kapacita jako v produkčním prostředí

Při testování můžete použít stejnou kapacitu jako produkční fáze. Použití stejné kapacity ale může během zátěžového testování vyžadovat nestabilní produkční prostředí. Pokud chcete zabránit nestabilnímu produkčnímu prostředí, otestujte použití jiné kapacity podobné v prostředcích jako v produkční kapacitě. Pokud se chcete vyhnout dodatečným nákladům, použijte kapacitu, kde můžete platit jenom za testovací dobu.

Použití pravidel nasazení se zdrojem dat v reálném životě

Pokud k simulaci skutečného využití dat používáte testovací fázi, je nejlepší oddělit zdroje dat pro vývoj a testování. Vývojová databáze by měla být relativně malá a testovací databáze by měla být co nejblíže produkční databázi. Pomocí pravidel zdroje dat můžete přepínat zdroje dat v testovací fázi nebo parametrizovat připojení, pokud neprocházejí kanály nasazení.

Kontrola souvisejících položek

Změny, které provedete, můžou také ovlivnit závislé položky. Během testování ověřte, že vaše změny nemají vliv na výkon stávajících položek, které můžou záviset na aktualizovaných položkách, ani jejich výkon.

Související položky můžete snadno najít pomocí analýzy dopadu.

Aktualizace datových položek

Datové položky jsou položky, které ukládají data. Definice položky v Gitu definuje způsob ukládání dat. Při aktualizaci položky v pracovním prostoru importujeme její definici do pracovního prostoru a použijeme ji u existujících dat. Operace aktualizace datových položek je stejná pro kanály Gitu a nasazení.

Protože různé položky mají různé možnosti, pokud jde o uchovávání dat při změně definice, mějte na paměti při použití změn. Některé postupy, které vám můžou pomoct použít změny nejbezpečnějším způsobem:

• Předem se dozvíte, co jsou změny a jaký je jejich dopad na stávající data. K popisu provedených změn použijte potvrzovací zprávy.

• Pokud chcete zjistit, jak tato položka zpracovává změnu pomocí testovacích dat, nahrajte změny nejprve do vývojového nebo testovacího prostředí.

• Pokud všechno půjde dobře, doporučujeme ho také zkontrolovat v přípravném prostředí s daty v reálném životě (nebo co nejblíže) a minimalizovat neočekávané chování v produkčním prostředí.

• Zvažte nejlepší načasování při aktualizaci prostředí Prod, abyste minimalizovali poškození, které by mohly způsobit případné chyby vašim firemním uživatelům, kteří data spotřebovávají.

• Po nasazení testy po nasazení v nástroji Prod ověřte, že všechno funguje podle očekávání.

• Některé změny se vždy považují za zásadní změny. Doufejme, že předchozí kroky vám pomůžou sledovat je před výrobou. Vytvořte plán, jak použít změny v nástroji Prod a obnovit data, abyste se vrátili do normálního stavu a minimalizovali výpadky pro firemní uživatele.

Testování aplikace

Pokud distribuujete obsah zákazníkům prostřednictvím aplikace, přečtěte si novou verzi aplikace, než bude v produkčním prostředí. Vzhledem k tomu, že každá fáze kanálu nasazení má svůj vlastní pracovní prostor, můžete snadno publikovat a aktualizovat aplikace pro fáze vývoje a testování. Publikování a aktualizace aplikací umožňuje otestovat aplikaci z pohledu koncového uživatele.

Důležité

Proces nasazení nezahrnuje aktualizaci obsahu nebo nastavení aplikace. Pokud chcete použít změny obsahu nebo nastavení, aktualizujte aplikaci ručně v požadované fázi kanálu.

Výroba

Tato část obsahuje pokyny pro produkční fázi kanálů nasazení.

Správa, kdo může nasadit do produkčního prostředí

Vzhledem k tomu, že nasazení do produkčního prostředí by mělo být pečlivě zpracováno, je vhodné povolit, aby tuto citlivou operaci spravovali jenom konkrétní lidé. Pravděpodobně ale chcete, aby všichni tvůrci BI pro konkrétní pracovní prostor měli přístup ke kanálu. Ke správě přístupových oprávnění použijte oprávnění k produkčnímu pracovnímu prostoru. Ostatní uživatelé můžou mít roli prohlížeče produkčních pracovních prostorů, aby viděli obsah v pracovním prostoru, ale nedělaly změny z kanálů Gitu nebo nasazení.

Kromě toho omezte přístup k úložišti nebo kanálu tím, že povolíte oprávnění jenom uživatelům, kteří jsou součástí procesu vytváření obsahu.

Nastavení pravidel pro zajištění dostupnosti produkční fáze

Pravidla nasazení představují účinný způsob, jak zajistit, aby data v produkčním prostředí byla vždy připojená a dostupná uživatelům. Když se použijí pravidla nasazení, nasazení se můžou spouštět, i když máte jistotu, že zákazníci uvidí relevantní informace bez narušení.

Ujistěte se, že jste nastavili pravidla produkčního nasazení pro zdroje dat a parametry definované v sémantickém modelu.

Aktualizace produkční aplikace

Nasazení v kanálu prostřednictvím uživatelského rozhraní aktualizuje obsah pracovního prostoru. Pokud chcete aktualizovat přidruženou aplikaci, použijte rozhraní API kanálů nasazení. Aplikaci není možné aktualizovat prostřednictvím uživatelského rozhraní. Pokud používáte aplikaci pro distribuci obsahu, nezapomeňte aplikaci po nasazení do produkčního prostředí aktualizovat, aby koncoví uživatelé mohli okamžitě používat nejnovější verzi.

Nasazení do produkčního prostředí pomocí větví Gitu

Vzhledem k tomu, že úložiště slouží jako "jeden zdroj pravdy", můžou některé týmy chtít nasadit aktualizace do různých fází přímo z Gitu. S integrací Gitu je to možné s několika důležitými informacemi:

• Doporučujeme používat větve vydaných verzí. Před každým nasazením je potřeba nepřetržitě měnit připojení pracovního prostoru k novým větvím vydané verze.

• Pokud kanál buildu nebo verze vyžaduje, abyste před nasazením do pracovního prostoru změnili zdrojový kód nebo spustili skripty v prostředí sestavení, pak vám připojení pracovního prostoru k Gitu nepomůže.

• Po nasazení do každé fáze nezapomeňte změnit veškerou konfiguraci specifickou pro danou fázi.

Rychlé opravy obsahu

Někdy dochází k problémům v produkčním prostředí, které vyžadují rychlou opravu. Nasazení opravy bez prvního testování je chybný postup. Proto vždy implementujte opravu ve fázi vývoje a nasdílejte ji do zbývajících fází kanálu nasazení. Nasazení do fáze vývoje umožňuje zkontrolovat, jestli oprava funguje, než ji nasadíte do produkčního prostředí. Nasazení v rámci kanálu trvá jenom několik minut.

Pokud používáte nasazení z Gitu, doporučujeme postupovat podle postupů popsaných v tématu Přijetí strategie větvení Gitu.

Související obsah

• Kurz kompletní správy životního cyklu
• Začínáme s integrací Gitu
• Začínáme s kanály nasazení