Megosztás a következőn keresztül:


A Power BI Project (PBIP) és az Azure DevOps buildfolyamatai az ellenőrzéshez

A Fabric Git-integráció és az Azure DevOps kombinálásával munkaterületet csatlakoztathat egy Azure DevOps-adattár egy ágához, és automatikusan szinkronizálódik közöttük.

A PBIP formátum és az Azure DevOps integrálásával az Azure Pipelines használatával automatizálhatja a folyamatos integrációs/folyamatos üzembe helyezési (CI/CD) folyamatokat. Ezek a folyamatok feldolgozzák a PBIP metaadatfájljait, és minőségellenőrzések sorozatát alkalmazzák a fejlesztésre, mielőtt üzembe helyeznénk őket az éles rendszerben.

Ebben a cikkben a folyamatos integrációra összpontosítunk, és bemutatjuk, hogyan hozhat létre olyan Azure DevOps-folyamatot, amely a Fabric-munkaterületen belüli összes szemantikai modellhez és jelentéshez biztosít ajánlott eljárásokat. Az automatizált minőségi tesztek végrehajtásával megelőzheti a gyakori hibákat, és javíthatja a csapat hatékonyságát. Ez a megközelítés például biztosítja, hogy az új csapattagok betartsák a szemantikai modellek és jelentések fejlesztésére vonatkozó szabványokat.

További információ a PBIP-ről és a Fabric Git-integrációról a projekt áttekintésében és a Fabric Git-integráció áttekintésében.

Az alábbi ábra a végpontok közötti forgatókönyvet mutatja be két olyan fejlesztési munkafolyamattal, amelyek aktiválják az Azure DevOps-folyamatot a fejlesztési minőség ellenőrzéséhez. A folyamat végrehajtása a következő műveleteket hajtja végre:

A DevOps-folyamat munkafolyamatát bemutató ábra.

  1. Az 1 . felhasználó a Power BI Desktop használatával fejleszt.

    1. Ág létrehozása a főből a VS Code használatával (funkció/adatkészlet-váltás)
    2. Szemantikai modell módosítása a Power BI Desktop használatával
    3. Távoli adattárfiók módosításainak véglegesítése a VS Code használatával
    4. Lekéréses kérelem létrehozása a főághoz az Azure DevOps használatával
  2. A 2. felhasználó ugyanakkor egy másik Fabric-munkaterület használatával fejleszt.

    1. Ág létrehozása a főből a Fabric Git használatával (feature/reportchange)
    2. Jelentésmódosítások a Háló munkaterületen
    3. Távoli adattárág módosításainak véglegesítése a Fabric Git használatával
    4. Lekéréses kérelem létrehozása a főághoz az Azure DevOps használatával
  3. A csapatvezető áttekinti a lekéréses kérelmeket, és szinkronizálja a módosításokat a csapat munkaterületén a Fabric Git használatával.

  4. A Lekéréses kérelem aktiválja az Azure DevOps-folyamatot a szemantikai modell és a jelentésfejlesztési minőség vizsgálatához.

Feljegyzés

Ebben a példában a folyamat két nyílt forráskódú közösségi eszközt használ, amelyek lehetővé teszik a fejlesztők számára, hogy (testre szabható) ajánlott eljárásszabályokat alkalmazzanak a szemantikai modellek és jelentések metaadataira egy Power BI Project-mappában:

A jelen cikkben szereplő példához hasonló megközelítés más közösségi eszközökre is vonatkozik. Ez a cikk nem ássa bele a korábban említett közösségi eszközök sajátosságait, sem a szabályok létrehozását és szerkesztését. A témakörökre vonatkozó részletes információkért tekintse meg a megadott hivatkozásokat. A cikk középpontjában a forráskövetés és a Fabric Workspace közötti minőségi kapu létrehozása áll. Fontos megjegyezni, hogy a hivatkozott közösségi eszközöket külső közreműködők fejlesztik, és a Microsoft nem nyújt számukra támogatást vagy dokumentációt.

1. lépés – Fabric-munkaterület csatlakoztatása az Azure DevOpshoz

A Fabric-munkaterület csatlakoztatása az Azure DevOpshoz:

Képernyőkép a DevOpshoz való Git-kapcsolatról.

Amikor a Fabric Git-integráció befejezi a munkaterület elemeinek exportálását, az Azure DevOps-ág a munkaterület minden eleméhez tartalmaz egy mappát:

Képernyőkép az Azure DevOps-ágról különböző munkaterületelemek mappáival.

2. lépés – Azure DevOps-folyamat létrehozása és futtatása

Új folyamat létrehozása:

  1. A bal oldali navigációs menü Folyamatok lapján válassza a Folyamat létrehozása lehetőséget:

    Folyamat létrehozását bemutató képernyőkép.

  2. Válassza ki az Azure Repos Gitet , és válassza ki az első adattárat (ugyanazt az adattárat, amely a Fabric-munkaterülethez csatlakozik):

    Képernyőkép a folyamat kódforrásaként kiválasztott Azure-adattár Gitről.

    Képernyőkép a demo-ADObuild repo kiválasztva.

  3. Válassza a Starter-folyamatot.

    Képernyőkép a kiválasztott kezdőfolyamat ikonról.

    A szerkesztőben a következő YAML-kód jelenik meg:

    Képernyőkép az alapértelmezett YAML-kódról.

  4. Másolja és illessze be a YAML-kódot a Power BI fejlesztői módú folyamatából a létrehozott folyamatba:

    Képernyőkép a hozzáadni kívánt YAML-kódról.

    Képernyőkép a YAML-kód második részéről.

  5. A Mentés és futtatás lehetőséget választva véglegesítse az új folyamatot az adattárban.

    Képernyőkép a YAML-kód áttekintéséről.

    Képernyőkép a mentési és futtatási kijelölésről.

Az Azure DevOps futtatja a folyamatot, és két buildelési feladatot indít el párhuzamosan:

Folyamatokat futtató Azure DevOps képernyőképe.

  • Build_Datasets
    • Letölti a táblázatos szerkesztő bináris fájljait.
    • Töltse le az ajánlott eljáráselemző alapértelmezett szabályait. A szabályok testreszabásához adjon hozzá egy Rules-Dataset.json az adattár gyökeréhez.
    • Váltsa végig az összes szemantikai modellelemmappát, és futtassa a Táblázatszerkesztő BPA-szabályait.
  • Build_Reports
    • Töltse le a PBI Inspector bináris fájljait.
    • Töltse le a PBI Inspector alapértelmezett szabályait. A szabályok testreszabásához adjon hozzá egy Rules-Report.json az adattár gyökeréhez.
    • Váltsa végig az összes jelentéselemmappát, és futtassa a Power BI Inspector-szabályokat.

Amikor befejeződik, az Azure DevOps létrehoz egy jelentést az összes észlelt figyelmeztetésről és hibáról:

Képernyőkép a hibajelentésről.

A hivatkozásra kattintva részletesebb nézetet nyithat meg a két feladatról:

Képernyőkép a megtekintési napló gombról.

A kibontott hibanapló képernyőképe.

Ha a jelentés vagy szemantikai modell egy magasabb súlyossági szintű szabályt meghiúsul, a build meghiúsul, és a hiba ki van emelve:

Képernyőkép a kiemelőhibákról.

3. lépés – Ágszabályzatok definiálása

A folyamat üzembe helyezése után engedélyezze a fő ág ágszabályzatainak használatát. Ez a lépés biztosítja, hogy ne lehessen véglegesítéseket közvetlenül a főbe tenni. A módosítások fő részre való visszaegyesítéséhez mindig szükség van egy "lekéréses kérelemre", és konfigurálhatja a folyamatot úgy, hogy minden lekéréses kérelemmel fusson.

  1. Válassza ki az Ágak fő ágszabályzatait>>:

    Az ágszabályzatokat bemutató képernyőkép.

  2. Konfigurálja a létrehozott folyamatot buildszabályzatként az ághoz:

    Képernyőkép a buildelési szabályzat felhasználói felületével.

    Képernyőkép a buildelési szabályzat felhasználói felületének második részéről.

4. lépés – Lekéréses kérelem létrehozása

Ha visszatér a Háló munkaterületre, módosítja az egyik jelentést vagy szemantikai modellt, és megpróbálja véglegesíteni a módosítást, a következő hibaüzenet jelenik meg:

Képernyőkép a módosítás véglegesítésének sikertelenségével kapcsolatos hibáról.

A fő ágat csak lekéréses kérelemmel módosíthatja. Lekéréses kérelem létrehozásához válasszon ki egy új ágat a módosítások elvégzéséhez:

Hozzon létre egy ágat közvetlenül a Háló munkaterületről:

  1. A Forrásvezérlő panelen válassza a Kivétel új ág lehetőséget , és adja meg az ág nevét.

    Képernyőkép egy új ág kivételéhez a forrásvezérlő képernyőről.

    Képernyőkép egy új ág kivételéről.

    Másik lehetőségként dönthet úgy is, hogy egy különálló, elkülönített munkaterületen vagy a Power BI Desktopban fejleszt. További információ: fejlesztés másik munkaterület használatával

  2. Véglegesítse a módosításokat az új ágban.

    Az ág módosításainak véglegesítését bemutató képernyőkép.

  3. A véglegesítést követően hozzon létre egy lekéréses kérést a ágba az Azure DevOps portálról.

    Képernyőkép egy új lekéréses kérelemről.

    Képernyőkép a létrehozott lekéréses kérelemről.

A lekéréses kérelem munkafolyamata nem csak a módosítások érvényesítését és áttekintését teszi lehetővé, hanem automatikusan aktiválja a folyamatot.

Képernyőkép a jelentés módosításáról.

Ha az egyik szabályban nagy súlyossági hiba lép fel, nem véglegesítheti a lekéréses kérelmet, és nem egyesítheti újra a módosításokat a főágban.

Képernyőkép a lekéréses kérelem befejezéséről.

További információ a PBIP-ről és a Fabric Git-integrációról blogbejegyzésben.