Správa prostředí: kapacita, pipelines, verzování

Vývojář opraví chybu přímo v produkčním reportu, přepne přepínač, a rozbije ho pro dvě stovky uživatelů — klasický scénář, kterému se dá předejít oddělením prostředí. Standardní vzor jsou tři workspace v roli DEV, TEST a PROD: v DEV vývojáři volně experimentují, TEST slouží k ověření uživateli nebo QA týmem (UAT), do PROD se dostává jen obsah, který prošel schválením, a koncoví uživatelé k němu přistupují přes app, ne přímo do workspace.

Shared capacity (Pro workspace) sdílí výpočetní zdroje s ostatními tenanty na pozadí — dostatečné pro menší týmy a základní scénáře, ale bez pokročilých funkcí. Dedikovaná kapacita — F-SKU nebo Premium P — vyhrazuje výpočetní výkon jen vaší organizaci a odemyká funkce, které shared kapacita nemá: deployment pipelines, XMLA endpoint, větší modely, vyšší frekvenci refreshe.

XMLA endpoint a export API mají u PPU další omezení oproti dedikované kapacitě (export jen pro paginated reporty, ne pro klasické Power BI reporty).

Deployment pipeline je nástroj pro řízený přesun obsahu mezi workspace — typicky DEV → TEST → PROD. Má 2 až 10 stages (výchozí jsou tři: Development, Test, Production), stages lze přidávat, mazat i přejmenovat podle potřeby. Vyžaduje Premium, PPU nebo F-SKU (Fabric) kapacitu; u PPU se workspace automaticky asociuje s PPU tenantem.

Compare a Deploy

Compare ukáže rozdíl mezi dvěma sousedními stages — co je nové, co se změnilo, co chybí. Deploy zkopíruje vybrané nebo všechny položky do následující stage. Deployment je vždy metadata-only — nekopírují se data, po deployi je potřeba spustit refresh a credentials/gateway připojení nastavit v cílovém workspace zvlášť.

Problém: report v DEV ukazuje na testovací databázi. Bez zásahu by po deployi do PROD ukazoval na tu samou testovací databázi i tam. Deployment rules řeší přesměrování po deployi — existují dva typy:

• Data source rules — přepíší connection string/server pro cílovou stage (v PROD se použije produkční databáze místo DEV).
• Parameter rules — přepíší hodnotu Power Query parametru pro cílovou stage.

Pravidlo se nastaví u cílové stage pomocí tlačítka Deployment rules u konkrétní položky a platí pro všechny další deploye — bez nich by bylo nutné přepojovat zdroj ručně po každém nasazení, což je zdroj chyb.

• Pravidlo může vytvořit jen vlastník (owner) položky, na kterou se vztahuje.
• Pravidla nejde vytvořit v development stage — jen v cílových stages za ní (typicky TEST, PROD).
• Nově vytvořené nebo změněné pravidlo se projeví až při dalším deployi do dané stage, ne zpětně na obsah, který už tam je.

Binární .pbix soubor neumožňuje smysluplný diff ani code review. Git integrace propojí workspace s repozitářem a exportuje obsah jako textové soubory — definice tabulek, DAX míry, vztahy, report layout, role. Data, credentials ani osobní bookmarky se do Gitu neexportují.

Podporovaní poskytovatelé jsou Azure DevOps, GitHub a GitHub Enterprise — všichni jen jako cloud-based služba. Git integrace pokrývá desítky typů položek (Lakehouse, Notebook, Pipeline, Dataflow Gen2, Warehouse, sémantický model, report, Variable library, org app a další) — ne všechny typy položek jsou podporované stejně.

POST https://api.fabric.microsoft.com/v1/workspaces/00000000-0000-0000-0000-000000000000/git/updateFromGit
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "workspaceHead": "eaa737b48cda41b37ffefac772ea48f6fed3eac4",
  "remoteCommitHash": "7d03b2918bf6aa62f96d0a4307293f3853201705",
  "conflictResolution": {
    "conflictResolutionType": "Workspace",
    "conflictResolutionPolicy": "PreferRemote"
  }
}

PBIP (Power BI Project) je složková struktura — místo jednoho binárního .pbix souboru dostanete sadu textových souborů rozdělených do podsložek .Report a .SemanticModel. PBIP zvolíte v Power BI Desktop přes File → Save as → Power BI Project (*.pbip). PBIP i PBIR jsou dle dokumentace GA a PBIR je výchozí formát reportu.

MujReport.pbip
MujReport.Report/
  ├─ definition.pbir
  ├─ definition/
  │   ├─ report.json
  │   ├─ version.json
  │   ├─ pages/
  │   │   └─ <page>/
  │   │       ├─ page.json
  │   │       └─ visuals/<visual>/visual.json
  │   └─ bookmarks/
  └─ StaticResources/
MujReport.SemanticModel/
  ├─ definition.pbism
  └─ definition/
      ├─ database.tmdl
      ├─ model.tmdl
      ├─ tables/
      │   ├─ Prodej.tmdl
      │   └─ Datum.tmdl
      ├─ relationships.tmdl
      ├─ roles/
      │   └─ Kraj_PHA.tmdl
      └─ cultures/
          └─ cs-CZ.tmdl

TMDL (Tabular Model Definition Language) je textový formát sémantického modelu. Dělí model po objektech — tabulka, perspektiva, role, kultura — každý má vlastní soubor. Není to „jedna DAX míra = jeden soubor": míry konkrétní tabulky žijí společně uvnitř souboru té tabulky, pod sekcí measure.

table Prodej

  measure 'Celkem trzby' = SUM(Prodej[Castka])
    formatString: #,0

  measure 'Trzby predchozi rok' =
      CALCULATE(
        [Celkem trzby],
        SAMEPERIODLASTYEAR('Datum'[Datum])
      )

  column Castka
    dataType: decimal
    summarizeBy: sum

  partition Prodej = m
    mode: import
    source =
        let
          Zdroj = Sql.Database("server.database.windows.net", "ProdejDB")
        in
          Zdroj

PBIR jde u reportu dál a dělí ho po jednotlivých stránkách a vizuálech (soubor page.json a visual.json pro každý) — granularita reportu je tedy jemnější než u sémantického modelu. Formát PBIP/PBIR/TMDL je dle dokumentace obecně dostupný (GA) a PBIR je dnes výchozí formát reportu v Power BI Desktop.

Ideální stav je obojí zároveň — Git pro historii a code review, pipeline pro řízené nasazení mezi prostředími.

Variable library je Fabric položka pro centrální správu konfiguračních hodnot napříč prostředími — typicky jiná hodnota pro dev, jiná pro test a jiná pro prod, spravovaná na jednom místě místo rozházených parametrů v jednotlivých položkách. Podporuje value-sets (sady hodnot per prostředí), proměnné typu item-reference (preview) a integraci s Gitem i deployment pipelines. Limit je 1000 proměnných a 1000 value-sets na knihovnu (max 10 000 buněk, 1 MB).

1. Vývojář pracuje lokálně v PBIP formátu, commituje do feature branch.
2. Otevře Pull Request — code review DAX měr a struktury modelu podle diffu v TMDL souborech.
3. Po schválení merge do main branch → admin nebo vlastník DEV workspace spustí v Source control panelu Update all (nebo zavolá stejnou akci přes Fabric REST API) — změna se do workspace nepromítne automaticky.
4. Deployment pipeline: Compare a Deploy z DEV do TEST → proběhne UAT.
5. Po schválení: Deploy z TEST do PROD, s deployment rules pro produkční zdroj dat.
6. Po deployi do PROD aktualizujte workspace app (Update app) — teprve pak produkční uživatelé vidí změny, bez výpadku a bez přímého přístupu do PROD workspace.

• Deployment pipelines — začínáme (EN)
• Proces nasazení, kapacitní požadavky a omezení (vč. PBIR) (EN)
• Retirement of semantic model support for deployment pipelines (EN)
• Deployment rules (EN)
• Git integrace — přehled a podporovaní poskytovatelé (EN)
• PBIP a TMDL formát sémantického modelu (EN)
• PBIR formát reportu (EN)
• Variable library — přehled (EN)
• Pozastavení kapacity a dopad na workspace (EN)