Kanály buildu Power BI Project (PBIP) a Azure DevOps pro kontinuální integraci

Kombinace integrace Gitu s Prostředky infrastruktury s Azure DevOps umožňuje připojit pracovní prostor k větvi v úložišti Azure DevOps a automaticky se mezi nimi synchronizuje.

Integrace formátu PBIP s Azure DevOps umožňuje používat Azure Pipelines k automatizaci kanálů kontinuální integrace/průběžného nasazování (CI/CD). Tyto kanály zpracovávají soubory metadat PBIP a před nasazením do produkčního systému na vývoj používají řadu kontrol kvality.

V tomto článku se zaměříme na kontinuální integraci a popisujeme, jak vytvořit kanál buildu Azure DevOps, který zaručuje osvědčené postupy pro všechny sémantické modely a sestavy v pracovním prostoru Fabric. Implementací automatizovaných testů kvality můžete zabránit běžným chybám a zvýšit efektivitu týmu. Tento přístup například zajišťuje, aby noví členové týmu dodržovali zavedené standardy pro sémantický model a vývoj sestav.

Přečtěte si další informace o integraci PBIP a Prostředků infrastruktury Git v přehledu projektů a přehledu integrace Gitu s prostředky infrastruktury.

Následující diagram znázorňuje kompletní scénář se dvěma vývojovými pracovními postupy, které aktivují kanál buildu Azure DevOps k ověření kvality vývoje. Sestavení provede následující akce:

1. Uživatel 1 vyvíjí pomocí Power BI Desktopu.

   1. Vytvoření větve z hlavní větve pomocí VS Code (feature/datasetchange)
   2. Provádění změn sémantického modelu pomocí Power BI Desktopu
   3. Potvrzení změn do větve vzdáleného úložiště pomocí nástroje VS Code
   4. Vytvoření žádosti o přijetí změn do hlavní větve pomocí Azure DevOps

2. Současně se uživatel 2 vyvíjí pomocí jiného pracovního prostoru Infrastruktury.

   1. Vytvoření větve z hlavní větve pomocí Gitu infrastruktury (funkce/reportchange)
   2. Provádění změn sestav v pracovním prostoru Fabric
   3. Potvrzení změn do větve vzdáleného úložiště pomocí Gitu infrastruktury
   4. Vytvoření žádosti o přijetí změn do hlavní větve pomocí Azure DevOps

3. Vedoucí týmu zkontroluje žádosti o přijetí změn a synchronizuje změny v pracovním prostoru týmu pomocí Gitu infrastruktury.

4. Žádost o přijetí změn aktivuje kanál buildu Azure DevOps, který zkontroluje sémantický model a kvalitu vývoje sestav.

Poznámka:

V tomto příkladu kanál buildu používá dva opensourcové komunitní nástroje, které vývojářům umožňují aplikovat (přizpůsobitelné) pravidla osvědčených postupů na metadata sémantických modelů a sestav v rámci složky Projektu Power BI:

• Tabulkový editor a pravidla osvědčených postupů
• PBI Inspector

Podobný přístup jako v příkladu v tomto článku by se použil u jiných komunitních nástrojů. Tento článek se nezabývá do specifik nástrojů komunity zmíněných dříve ani k vytváření a úpravám pravidel. Podrobné informace o těchtotématech Tento článek se zaměřuje na proces vytvoření brány kvality mezi správou zdrojového kódu a pracovním prostorem Fabric. Je důležité si uvědomit, že odkazované komunitní nástroje jsou vyvíjeny přispěvateli třetích stran a Microsoft pro ně nenabízí podporu ani dokumentaci.

Krok 1 – Připojení pracovním prostoru Fabric do Azure DevOps

Připojení pracovního prostoru Fabric do Azure DevOps:

Po dokončení integrace Gitu s prostředky infrastruktury pro export položek pracovního prostoru bude vaše větev Azure DevOps obsahovat složku pro každou položku v pracovním prostoru:

Krok 2 – Vytvoření a spuštění kanálu buildu Azure DevOps

Vytvoření nového kanálu buildu:

1. Na kartě Kanály v levé navigační nabídce vyberte Vytvořit kanál:

   

2. Vyberte Git Azure Repos a vyberte první úložiště (stejné úložiště, které je připojené k pracovnímu prostoru Fabric):

   

   

3. Vyberte počáteční kanál.

   

   V editoru se zobrazí následující kód YAML:

   

4. Zkopírujte a vložte kód YAML z kanálu režimu vývojáře Power BI do kanálu, který jste vytvořili:

   

   

5. Vyberte Uložit a Spustit a potvrďte nový kanál do úložiště.

   

   

Azure DevOps spustí kanál a spustí dvě paralelní úlohy sestavení:

• Build_Datasets
  • Stahuje binární soubory tabulkového editoru.
  • Stáhněte výchozí pravidla Analyzátoru osvědčených postupů. Pokud chcete pravidla přizpůsobit, přidejte do kořenového adresáře úložiště soubor Rules-Dataset.json .
  • Projděte všechny složky sémantických položek modelu a spusťte pravidla analyzátoru osvědčených údajů v tabulkovém editoru.
• Build_Reports
  • Stáhněte si binární soubory PBI Inspectoru.
  • Stáhněte výchozí pravidla kontroly PBI. Pokud chcete pravidla přizpůsobit, přidejte do kořenového adresáře úložiště soubor Rules-Report.json .
  • Cyklicky projděte všechny složky položek sestavy a spusťte pravidla Kontroly Power BI.

Po dokončení Azure DevOps vytvoří sestavu všech upozornění a chyb, ke kterým došlo:

Výběrem odkazu otevřete podrobnější zobrazení těchto dvou úloh sestavení:

Pokud sestava nebo sémantický model selže s pravidlem s vyšší úrovní závažnosti, sestavení selže a chyba se zvýrazní:

Krok 3 – Definování zásad větve

Po zprovoznění kanálu povolte zásady větve v hlavní větvi. Tento krok zajistí, že se žádná potvrzení nedají provést přímo do hlavního. " Žádost o přijetí změn" se vždy vyžaduje ke sloučení změn zpět do hlavního a kanál buildu můžete nakonfigurovat tak, aby běžel s každou žádostí o přijetí změn.

1. Vyberte hlavní zásady větve větví>:>

   

2. Nakonfigurujte vytvořený kanál jako zásadu sestavení pro větev:

   

   

Krok 4 – Vytvoření žádosti o přijetí změn

Pokud se vrátíte do pracovního prostoru Prostředků infrastruktury, proveďte změny některé ze sestav nebo sémantických modelů a pokusíte se změnu potvrdit, zobrazí se následující chyba:

V hlavní větvi můžete provádět změny jenom prostřednictvím žádosti o přijetí změn. Pokud chcete vytvořit žádost o přijetí změn, vytvořte novou větev, ve které provedete změny:

Vytvořte větev přímo z pracovního prostoru Fabric:

1. V podokně Správa zdrojového kódu vyberte možnost Rezervovat novou větev a zadejte název větve.

   

   

   Alternativně se můžete rozhodnout vyvíjet v samostatném izolovaném pracovním prostoru nebo v Power BI Desktopu. Další informace najdete v tématu Vývoj s využitím jiného pracovního prostoru.

2. Potvrďte změny v této nové větvi.

   

3. Po potvrzení vytvořte žádost o přijetí změn do hlavní větve z portálu Azure DevOps.

   

   

Pracovní postup žádosti o přijetí změn umožňuje nejen ověřit a zkontrolovat změny, ale také automaticky aktivovat kanál buildu.

Pokud je v některém z pravidel chyba sestavení s vysokou závažností, nemůžete dokončit žádost o přijetí změn a sloučit změny zpět do hlavní větve.

Další informace o integraci PBIP a Fabric s Gitem najdete v blogovém příspěvku.