Power BI használati forgatókönyvek: Vállalati tartalom-közzététel

  • Cikk

Feljegyzés

Ez a cikk a Power BI implementációtervezési cikksorozatának része. Ez a sorozat elsősorban a Microsoft Fabricen belüli Power BI-számítási feladatokra összpontosít. A sorozat bemutatása: Power BI implementációtervezés.

Amikor a tartalomkészítők együttműködnek a szervezet számára fontos elemzési megoldások biztosításában, biztosítaniuk kell a tartalom időben és megbízhatóan történő továbbítását a fogyasztók számára. A technikai csapatok a DevOps nevű folyamattal oldják meg ezt a kihívást. A DevOps lehetővé teszi a csapatok számára a folyamatok automatizálását és skálázását olyan eljárások alkalmazásával, amelyek javítják és felgyorsítják a teljesítést.

Feljegyzés

Az ugyanezekkel a kihívásokkal foglalkozó adatcsoportok a DataOpsot is gyakorolhatják. A DataOps a DevOps alapelveire épül, de a DataOps további adatkezelési gyakorlatokat is tartalmaz, például az adatminőség-biztosítást és a szabályozást. Ebben a cikkben a DevOpsra hivatkozunk, de vegye figyelembe, hogy az alapelvek a DataOpsra is alkalmazhatók.

A tartalomkészítők és a felhasználók számos előnyt élveznek a Power BI-tartalmak közzétételére vonatkozó DevOps-eljárások bevezetésekor. Az alábbi pontok magas szintű áttekintést adnak a folyamat működéséről.

  1. Tartalom fejlesztése és munka véglegesítése egy távoli adattárban: A tartalomkészítők saját gépükön fejlesztik a megoldásukat. A fejlesztés során rendszeres időközönként véglegesítik és mentik a munkájukat egy távoli adattárba . A távoli adattár a megoldás legújabb verzióját tartalmazza, és a teljes fejlesztői csapat számára elérhető.
  2. Tartalommódosítások együttműködése és kezelése verziókövetéssel: Más tartalomkészítők egy ág létrehozásával módosíthatják a megoldást. Az ág egy távoli adattár másolata. Ha ezek a változatok elkészültek és jóváhagyva lettek, a rendszer egyesíti az ágat a megoldás legújabb verziójával. A rendszer nyomon követi a megoldás összes változatát. Ezt a folyamatot verziókövetésnek (vagy forrásvezérlőnek) nevezzük.
  3. Tartalom üzembe helyezése és előléptetése folyamatok használatával: Az önkiszolgáló tartalom-közzétételi használati forgatókönyvben a tartalom előléptetése (vagy üzembe helyezése) fejlesztési, tesztelési és éles munkaterületeken keresztül történik a Power BI üzembehelyezési folyamataival. A Power BI üzembehelyezési folyamatai manuálisan, a felhasználói felületen vagy a REST API-k használatával előléptethetik a tartalmakat a Power BI Premium-munkaterületeken. Ezzel szemben a vállalati tartalom-közzététel (ennek a használati forgatókönyvnek a fókusza) az Azure Pipelines használatával előlépteti a tartalmakat. Az Azure Pipelines egy Azure DevOps-szolgáltatás, amely testre szabott, programozott lépések sorozatával automatizálja a tartalmak tesztelését, kezelését és üzembe helyezését. A vállalati tartalom-közzétételi használati forgatókönyvben ezeket a folyamatokat folyamatos integrációs és üzembehelyezési (vagy CI/CD-) folyamatoknak is nevezhetjük. Ezek a folyamatok gyakran és automatikusan integrálják a módosításokat, és egyszerűsítik a tartalom-közzétételt.

Fontos

Ez a cikk időnként a Power BI Premiumra vagy annak kapacitás-előfizetésére (P termékváltozatokra) hivatkozik. Vegye figyelembe, hogy a Microsoft jelenleg összevonja a vásárlási lehetőségeket, és visszavonul a Power BI Premium kapacitásonkénti termékváltozataitól. Az új és a meglévő ügyfeleknek érdemes megfontolni a Fabric-kapacitás-előfizetések (F SKU-k) megvásárlását.

További információ: Fontos frissítés a Power BI Premium licenceléséhez és a Power BI Premiumhoz – gyakori kérdések.

A DevOps támogatja a tartalomkezelés és -közzététel kiforrott, szisztematikus megközelítését. Lehetővé teszi, hogy a tartalomkészítők együttműködjenek a megoldásokon, és biztosítja a tartalom gyors és megbízható továbbítását a fogyasztók számára. Ha betartja a DevOps-eljárásokat, egyszerűbb munkafolyamatokat, kevesebb hibát és továbbfejlesztett élményt érhet el a tartalomkészítők és tartalomfogyasztók számára.

A Power BI-megoldás devOps-eljárásait az Azure DevOps használatával állíthatja be és kezelheti. Vállalati forgatókönyvekben három különböző módon automatizálhatja a tartalom-közzétételt az Azure DevOps és a Power BI REST API-k használatával.

  • Power BI REST API-k Power BI üzembehelyezési folyamatokkal: Tartalmat importálhat fejlesztési munkaterületekre, és üzembe helyezési folyamatokkal helyezhet üzembe tartalmakat teszt- és éles munkaterületeken keresztül. Továbbra is szabályozhatja az Üzembe helyezést az Azure DevOpsból, és a Power BI REST API-kkal kezelheti az üzembehelyezési folyamatokat az egyes tartalomelemek helyett. Emellett az XMLA-végponttal az adatmodell metaadatait is üzembe helyezheti Power BI Desktop-fájl (.pbix) helyett az Azure DevOps használatával. Ez a metaadatok lehetővé teszik az objektumszintű változások követését a verziókövetés használatával. Bár robusztusabb és könnyebben karbantartható, ez a megközelítés prémium szintű licencelést és mérsékelt szkriptelési erőfeszítést igényel a tartalomimportálás és -üzembe helyezés Power BI REST API-kkal való beállításához. Ezt a módszert akkor használja, ha egyszerűbbé szeretné tenni a tartalom életciklusának kezelését az üzembe helyezési folyamatokkal, és prémium szintű licenccel rendelkezik. Az XMLA-végpont és a Power BI üzembehelyezési folyamatai prémium szintű funkciók.
  • Power BI REST API-k: Tartalmakat is importálhat fejlesztési, tesztelési és éles munkaterületekre az Azure DevOps és csak a Power BI REST API-k használatával. Ez a megközelítés nem igényel prémium szintű licencelést, de nagy szkriptelési erőfeszítést és beállítást igényel, mivel az üzembe helyezést a Power BI-n kívül kezelik. Ezt a módszert akkor használja, ha központilag szeretné üzembe helyezni a Power BI-tartalmakat az Azure DevOpsból, vagy ha nem rendelkezik Prémium licenccel. Az első két megközelítés vizuális összehasonlítását a kiadási folyamat folyamatábra szemlélteti.
  • Power BI-automatizálási eszközök Power BI üzembehelyezési folyamatokkal: A Power BI automation tools Azure DevOps bővítményével a Power BI REST API-k helyett az üzembehelyezési folyamatokat kezelheti. Ez a megközelítés az első lehetőség alternatíva, amely a Power BI REST API-kat használja a Power BI üzembehelyezési folyamataival. A Power BI automation tools bővítmény egy nyílt forráskód eszköz. Segítségével PowerShell-szkriptek írása nélkül kezelheti és közzéteheti az Azure DevOpsból származó tartalmakat. Ezt a módszert akkor használja, ha minimális szkriptelési munkával szeretné kezelni az Azure DevOps üzembehelyezési folyamatait, és prémium szintű kapacitással rendelkezik.

Ez a cikk az első lehetőséggel foglalkozik, amely a Power BI REST API-kat használja a Power BI üzembehelyezési folyamataival. Ismerteti, hogyan állíthatja be a DevOps-eljárásokat az Azure DevOps használatával. Azt is ismerteti, hogyan használhatja az Azure-adattárakat a távoli adattárakhoz, és hogyan automatizálhatja a tartalomtesztelést, az integrációt és a teljesítést az Azure Pipelinessal. Nem az Azure DevOps az egyetlen módja a vállalati tartalom-közzététel beállításának, de a Power BI egyszerű integrációja jó választás.

Feljegyzés

Ez a használati forgatókönyv a tartalomkezelési és üzembe helyezési forgatókönyvek egyike. A rövidség kedvéért a jelen cikk nem foglalkozik a tartalom-együttműködési és kézbesítési forgatókönyvek témakörében ismertetett néhány szempontmal. A teljes lefedettség érdekében először olvassa el ezeket a cikkeket.

Tipp.

A Microsoft Fabric más lehetőségeket is kínál a nagyvállalati tartalom-közzétételhez a Fabric Git-integrációval. A Git-integráció lehetővé teszi, hogy egy Fabric-munkaterületet egy ághoz csatoljon az Azure Repos távoli adattárában. Az ágba mentett tartalom automatikusan szinkronizálódik a munkaterületre, mintha a tartalmat közzétették volna a munkaterületen. Ezzel szemben a tartalomkészítők véglegesíthetik és leküldhetik a módosításokat a Háló munkaterületről a távoli adattárba.

A Git-integráció egyszerűsítheti az együttműködést és a tartalom-közzétételt, de nagyobb tervezést igényel a Fabric-munkaterületek használatának és az elágaztatási stratégiának a használatára vonatkozóan. A Fabric Git-integráció beállításával és használatával kapcsolatos további információkért tekintse meg a Git-integráció első lépéseit vagy az oktatóanyagot: Teljes életciklus-kezelés.

Forgatókönyv-diagram

Az alábbi ábra a vállalati tartalmak közzétételét támogató leggyakoribb felhasználói műveletek és Power BI-összetevők magas szintű áttekintését mutatja be. A fókusz az Azure DevOps használata a tartalom programozott módon történő kezeléséhez és közzétételéhez a Power BI szolgáltatás fejlesztési, tesztelési és éles munkaterületeken keresztül.

A diagram a vállalati tartalom-közzétételt mutatja be, amely az együttműködés fokozásáról és a tartalom nagy léptékű kezeléséről szól az Azure DevOps használatával. A diagram elemeit a táblázat ismerteti.

Tipp.

Javasoljuk, hogy töltse le a forgatókönyv-diagramot , ha be szeretné ágyazni a bemutatóba, a dokumentációba vagy a blogbejegyzésbe, vagy nyomtassa ki fali plakátként. Mivel ez egy méretezhető vektorgrafika (SVG) kép, minőségromlás nélkül skálázhatja fel vagy le.

A forgatókönyv-diagram a következő felhasználói műveleteket, folyamatokat és funkciókat ábrázolja.

Cikk Leírás
1. elem. A tartalomkészítők a Power BI Desktop vagy a Táblázatszerkesztő használatával fejlesztenek adatmodelleket, és jelentéseket fejlesztenek a Power BI Desktop használatával. A tartalomkészítők a fejlesztés során egy helyi adattárba mentik a munkájukat.
2. elem. A tartalomkészítők klónozhatnak egy távoli adattárat a tartalom helyi másolatának lekéréséhez.
3. elem. Egyes adatforrásokhoz helyszíni adatátjáróra vagy VNet-átjáróra lehet szükség az adatfrissítéshez, például a magánhálózaton belül találhatóakhoz.
4. elem. A tartalomkészítők a fejlesztés során rendszeresen véglegesítik és leküldik a módosításokat egy távoli adattárba egy Git-ügyfél, például a Visual Studio Code használatával. A diagramon a távoli adattár az Azure Repos.
5. elem. Más tartalomkészítők az Azure Repos használatával követhetik nyomon a változásokat a verziókövetéssel. A módosítások külön ágakba való véglegesítésével működnek együtt.
6. elem. A távoli adattár tartalmának módosítása aktiválja az Azure Pipelinest. Az érvényesítési folyamat az első aktivált folyamat. Az érvényesítési folyamat automatikus teszteket végez a tartalom ellenőrzéséhez a közzététel előtt.
7. elem. Az érvényesítési folyamaton áthaladó tartalom egy későbbi buildelési folyamatot aktivál. A buildelési folyamat előkészíti a tartalmat a Power BI szolgáltatás való közzétételhez. Az eddig a pontig tartó folyamatot általában folyamatos integrációnak (CI) nevezzük.
8. elem. A tartalom közzététele és üzembe helyezése kiadási folyamatokkal történik. A kiadási folyamatok a Power BI REST API-k vagy a munkaterület XMLA-végpontja használatával programozott módon importálják a tartalmat a Power BI szolgáltatás. A kiadási folyamatok használatával történő üzembe helyezést általában folyamatos üzembe helyezésnek (CD) nevezzük.
9. elem. A kiadáskezelő az Üzembe helyezést az Azure Pipelines kiadási jóváhagyásával tesztelheti és éles környezetben tesztelheti. A vállalati tartalom-közzétételben a kiadáskezelő általában a tartalomkiadást tervezi és koordinálja a teszteléshez és az éles környezetekhez. Koordinálják és kommunikálnak a tartalomkészítőkkel, az érdekelt felekkel és a felhasználókkal.
10. tétel. A kiadási folyamat tartalmat tesz közzé a fejlesztési munkaterületen, vagy előlépteti a tartalmakat a fejlesztéstől a munkaterületek tesztelésén át az éles munkaterületeken való tesztelésig.
11. tétel. A Fabric-kapacitáslicenc-móddal rendelkező munkaterületen dolgozó tartalomkészítők használhatják a Git-integrációt. A Git-integrációval a tartalomkészítők egy privát munkaterületen dolgozhatnak a fejlesztés során. A tartalomkészítő szinkronizál egy távoli ágat (általában egy adott szolgáltatáságat vagy egy hibaágat) az Azure-adattárakból a saját privát munkaterületére. A tartalommódosítások szinkronizálódnak az Azure-adattárak távoli ága és a munkaterület között. Ebben a forgatókönyvben a tartalomkészítőknek nem kell az Azure Pipelines használatával közzétenni a tartalmakat. A tartalomkészítők a közzététel után rendszeresen véglegesíthetik és leküldhetik a módosításokat a munkaterületről. Ha készen áll, a tartalomkészítők lekéréses kérelmet (PR) hajthatnak végre a fő ág módosításainak egyesítése érdekében.
12. elem. A Git-integráció használatakor a fejlesztői munkaterület szinkronizálódik a fő ággal a tartalom legújabb verzióinak lekéréséhez. Ez a tartalom tartalmazza a lekéréses kérelmek minden olyan módosítását, amelyet a kiadáskezelő felülvizsgál, jóváhagy és egyesít.
13. tétel. A munkaterületek fabrickapacitásra, prémium szintű kapacitásra, felhasználónkénti Premium vagy Embeddedlicencmódra vannak beállítva, hogy lehetővé tegyék a Power BI üzembehelyezési folyamatainak és az XMLA olvasási/írási végpontjának használatát.
14. tétel. Az üzembehelyezési folyamat rendszergazdája három fázissal állítja be a Power BI üzembehelyezési folyamatot: fejlesztés, tesztelés és éles környezet. Minden fázis egy külön munkaterülethez igazodik a Power BI szolgáltatás. Az üzembehelyezési beállítások és a hozzáférés be van állítva az üzembe helyezési folyamathoz.
15. tétel. A fejlesztési munkaterület tartalmazza a tartalom legújabb verzióit, beleértve az összes jóváhagyott és egyesített módosítást. A jóváhagyást követően a kiadási folyamat üzembe helyezi a tartalmat a fejlesztésből a teszt-munkaterületre.
16. tétel. A teszt-munkaterület véleményezői tesztelést és minőségbiztosítást végeznek a tartalmakon. A jóváhagyást követően egy kiadási folyamat üzembe helyezi a tartalmat a tesztből az éles munkaterületre. Ha Git-integrációt használ az üzembehelyezési folyamatokkal, a teszt-munkaterület nem szinkronizálódik egyetlen ággal sem.
17. tétel. Miután az üzembe helyezési folyamat befejeződött, a tartalomkészítők manuálisan hajtanak végre az üzembe helyezés utáni tevékenységeket. A tevékenységek közé tartozhat az ütemezett adatfrissítés beállítása vagy egy Power BI-alkalmazás frissítése az éles munkaterületen. Ha Git-integrációt használ az üzembehelyezési folyamatokkal, az éles munkaterület nem szinkronizálódik egyetlen ággal sem.
18. tétel. A tartalommegjelenítők az éles munkaterületen vagy egy Power BI-alkalmazáson keresztül férnek hozzá a tartalomhoz.

Tipp.

Javasoljuk, hogy tekintse át az önkiszolgáló tartalom-közzétételt és a speciális adatmodell-kezelési használati forgatókönyveket is. A vállalati tartalom-közzététel használati forgatókönyve az ilyen forgatókönyvek által bevezetett fogalmakra épül.

Kulcsfontosságú pontok

Az alábbiakban néhány fontos szempontot emelünk ki a vállalati tartalom-közzétételi forgatókönyvről.

Verziókövetés

A változások nyomon követése a tartalom életciklusa során fontos annak érdekében, hogy a tartalom stabil és konzisztens legyen a fogyasztók számára. Ebben a használati forgatókönyvben a tartalomkészítők és a tulajdonosok verziókövetéssel kezelik a távoli adattárban lévő tartalommódosításokat. A verziókövetés a fájlok vagy kódok módosításainak központi adattárban való kezelésére szolgál. Ez a gyakorlat jobb együttműködést és a verzióelőzmények hatékony kezelését teszi lehetővé. A verziókövetésnek előnyei vannak a tartalomkészítők számára, beleértve a módosítások visszaállítását vagy egyesítését.

A tartalomkészítők általában adatmodelleket fejlesztenek a Táblázatszerkesztőben a jobb verziókövetés támogatása érdekében. A Power BI Desktopban fejlesztett adatmodellekkel ellentétben a táblázatos szerkesztőben kifejlesztett adatmodellek ember által olvasható metaadat-formátumban lesznek mentve. Ez a formátum lehetővé teszi az adatmodell objektumszintű verziókövetését. Objektumszintű verziókövetést kell használnia, ha ugyanazon az adatmodellen több személyrel dolgozik együtt. További információkért tekintse meg a speciális adatmodell-kezelési használati forgatókönyvet. Power BI Desktop-fájlban (.pbix) végzett módosítások nem láthatók, például a jelentésdefinícióban vagy az adatmodellben. Például nem követheti nyomon a jelentésoldalak módosításait, például a használt vizualizációkat, azok pozícióit, valamint a mezőleképezéseket vagy -formázásokat.

A tartalomkészítők az adatmodell metaadatfájljait és a .pbix-fájlokat egy központi távoli adattárban tárolják, például az Azure Reposban. Ezeket a fájlokat egy műszaki tulajdonos fogja össze. Míg a tartalomkészítők egy megoldást fejlesztenek, a technikai tulajdonos feladata a megoldás kezelése és a módosítások áttekintése, valamint azokat egyetlen megoldássá egyesítése. Az Azure Repos kifinomult lehetőségeket kínál a változások nyomon követésére és kezelésére. Ez a megközelítés eltér az önkiszolgáló tartalom-közzététel használati forgatókönyvében leírt megközelítéstől, ahol a létrehozó a OneDrive-tárterületet használja verziókövetéssel. A jól válogatott, dokumentált adattár fenntartása elengedhetetlen, mivel ez az összes tartalom és együttműködés alapja.

Az alábbiakban bemutatunk néhány fontos szempontot, amelyek segítenek egy távoli adattár beállításában a verziókövetéshez.

  • Hatókör: Egyértelműen határozza meg az adattár hatókörét. Ideális esetben az adattár hatóköre megegyezik az alsóbb rétegbeli munkaterületek és alkalmazások hatókörével, amelyeket a tartalom fogyasztóknak történő továbbításához használ.
  • Hozzáférés: Az adattárhoz való hozzáférést az üzembehelyezési folyamat engedélyeinek és munkaterületi szerepköreinek beállításához hasonló engedélymodell használatával kell beállítania. A tartalomkészítőknek hozzáférésre van szükségük az adattárhoz.
  • Dokumentáció: Szöveges fájlok hozzáadása az adattárhoz a cél, a tulajdonjog, a hozzáférés és a definiált folyamatok dokumentálásához. A dokumentáció például leírja, hogyan kell a módosításokat szakaszosra és véglegesíteni.
  • Eszközök: A távoli adattár módosításainak véglegesítéséhez és leküldéséhez a tartalomkészítőknek olyan Git-ügyfélre van szükségük, mint a Visual Studio vagy a Visual Studio Code. A Git egy elosztott verziókövetési rendszer, amely nyomon követi a fájlok változásait. A Git alapjairól a Mi a Git? című témakörben olvashat.

Feljegyzés

Fontolja meg a Git Large File Storage (LFS) használatát , ha Power BI Desktop-fájlok (.pbix) véglegesítését tervezi. A Git LFS speciális lehetőségeket biztosít olyan fájlok kezelésére, amelyekben a módosítások nem láthatók (nem látható fájlok), például .pbix-fájlok. Fájlzárolással például megakadályozhatja a Power BI-jelentések egyidejű módosításait a fejlesztés során. A Git LFS azonban saját ügyfél- és konfigurációs szolgáltatásokkal rendelkezik.

Együttműködés az Azure DevOpsszal

A megoldások hatókörének és összetettségének növekedésével szükségessé válhat, hogy több tartalomkészítő és tulajdonos működjön együtt. A tartalomkészítők és -tulajdonosok egy központi, szervezett központban kommunikálnak és működnek együtt az Azure DevOps használatával.

Az Azure DevOpsban való együttműködéshez és kommunikációhoz támogató szolgáltatásokat kell használnia.

  • Azure Boards: A tartalomtulajdonosok táblák használatával követik nyomon a munkaelemeket. A munkaelemeket a csapat egyetlen fejlesztője rendeli hozzá, és ismertetik a megoldás problémáit, hibáit vagy funkcióit, valamint a megfelelő érdekelt feleket.
  • Azure Wiki: A tartalomkészítők információkat osztanak meg a csapatukkal, hogy megértsék és hozzájáruljanak a megoldáshoz.
  • Azure-adattárak: A tartalomkészítők nyomon követhetik a távoli adattár módosításait, és egyetlen megoldásba egyesíthetik őket.
  • Azure Pipelines: A folyamattulajdonosok programozott logikát állítottak be a megoldás automatikus vagy igény szerinti üzembe helyezéséhez.

Együttműködési folyamat diagramja

Az alábbi ábra egy példa magas szintű áttekintését mutatja be arról, hogy az Azure DevOps hogyan teszi lehetővé az együttműködést a vállalati tartalom-közzétételi használati forgatókönyvben. A diagram középpontjában az Azure DevOps strukturált és dokumentált tartalom-közzétételi folyamat létrehozása áll.

Diagram a fenti bekezdésben leírtak szerint. A diagram elemeit az alábbi táblázat ismerteti.

A diagram a következő felhasználói műveleteket, folyamatokat és funkciókat ábrázolja.

Cikk Leírás
1. elem. A tartalomkészítő új, rövid élettartamú ágat hoz létre a fő ág klónozásával, amely a tartalom legújabb verzióját tartalmazza. Az új ágat gyakran funkcióágnak nevezik, mivel egy adott funkció fejlesztésére vagy egy adott probléma megoldására szolgál.
2. elem. A tartalomkészítő a fejlesztés során véglegesíti a módosításokat egy helyi adattárban.
3. elem. A tartalomkészítő a módosításokat az Azure Boardsban felügyelt munkaelemekhez csatolja. A Works-elemek az águkra vonatkozó konkrét fejlesztéseket, fejlesztéseket vagy hibajavításokat ismertetik.
4. elem. A tartalomkészítő rendszeresen véglegesíti a módosításokat. Ha elkészült, a tartalomkészítő közzéteszi az ágát a távoli adattárban.
5. elem. A módosítások teszteléséhez a tartalomkészítő üzembe helyezi a megoldását egy elkülönített munkaterületen a fejlesztéshez (ez a diagram nem jelenik meg). A tartalomkészítő a Fabric Git-integrációval szinkronizálhatja a szolgáltatáságat a munkaterületre.
6. elem. A tartalomkészítők és a tartalomtulajdonosok egy Azure Wikiben dokumentálják a megoldást és annak folyamatait, amely a teljes fejlesztői csapat számára elérhető.
7. elem. Ha elkészült, a tartalomkészítő megnyit egy lekéréses kérelmet a funkcióág fő ágba való egyesítése érdekében.
8. elem. A lekéréses kérelem áttekintéséért és a módosítások egyesítéséért a műszaki tulajdonos felel. Amikor jóváhagyják a lekéréses kérelmet, egyesítik a funkcióágat a főágban.
9. elem. A sikeres egyesítés aktiválja a megoldás üzembe helyezését egy fejlesztési munkaterületen egy Azure Pipeline használatával (ez a diagram nem jelenik meg). A Fabric Git-integráció használatakor a fő ág szinkronizálódik a fejlesztési munkaterületre.
10. tétel. A kiadáskezelő elvégzi a megoldás végső felülvizsgálatát és jóváhagyását. Ez a kiadási jóváhagyás megakadályozza a megoldás közzétételét, mielőtt készen áll. A vállalati tartalom-közzétételben a kiadáskezelő általában a tartalomkiadást tervezi és koordinálja a teszteléshez és az éles munkaterületekhez. Koordinálják és kommunikálnak a tartalomkészítőkkel, az érdekelt felekkel és a felhasználókkal.
11. tétel. Amikor a kiadáskezelő jóváhagyja a kiadást, az Azure Pipelines automatikusan előkészíti a megoldást az üzembe helyezésre. Másik lehetőségként az Azure Pipeline üzembe helyezési folyamatot is aktiválhat a munkaterületek közötti tartalom előléptetéséhez.
12. elem. A felhasználók tesztelik és ellenőrzik a teszt-munkaterület tartalmát. Ha Git-integrációt használ az Azure Pipelinessal üzembe helyezéshez, a teszt-munkaterület nem szinkronizálódik egyetlen ággal sem.
13. tétel. Miután a felhasználók elfogadták és érvényesítik a módosításokat, a kiadáskezelő elvégzi a megoldás végleges felülvizsgálatát és jóváhagyását az éles munkaterületen való üzembe helyezéshez.
14. tétel. A felhasználók megtekinthetik az éles munkaterületen közzétett tartalmakat. Ha Git-integrációt használ az Azure Pipelinessal üzembe helyezéshez, az éles munkaterület nem szinkronizálódik egyetlen ággal sem.

A tartalomkészítők egy elágaztatási stratégia használatával valósítják meg az együttműködést. Az elágaztatási stratégia az, ahogyan a tartalomkészítők ágakat hoznak létre, használnak és egyesítenek a tartalommódosítások hatékony elvégzéséhez és kezeléséhez. Az egyes tartalomkészítők külön dolgoznak a helyi adattárukban. Ha elkészültek, a módosításokat egyetlen megoldásként kombinálják a távoli adattárban. A tartalomkészítőknek a munkájukat az ágakra kell korlátozniuk azáltal, hogy munkaelemekhez kapcsolják őket adott fejlesztések, fejlesztések vagy hibajavítások céljából. Minden tartalomkészítő saját ágat hoz létre a távoli adattárból a munka hatóköréhez. A helyi megoldáson végzett munka véglegesítése és leküldése a távoli adattár ágának egy verziójába véglegesítési üzenettel történik. A véglegesítési üzenet ismerteti a véglegesítésben végrehajtott módosításokat.

A módosítások egyesítése érdekében a tartalomkészítő megnyitja a lekéréses kérelmet. A lekéréses kérelmek a társ-felülvizsgálatra való beküldések, amelyek az elvégzett munka egyetlen megoldásba való egyesítéséhez vezethetnek. Az egyesítés ütközéseket eredményezhet, amelyeket az ág egyesítése előtt fel kell oldani. A lekéréses kérelmek áttekintése fontos annak biztosítása érdekében, hogy az alkotók megfeleljenek a fejlesztési, minőségi és megfelelőségi szervezeti szabványoknak és eljárásoknak.

Együttműködési javaslatok

Javasoljuk, hogy definiáljon egy strukturált folyamatot a tartalomkészítők együttműködésének módjához. Győződjön meg arról, hogy a következőt határozza meg:

  • A munka hatókörének és az ágak létrehozásának, elnevezésének és felhasználásának módját.
  • Hogyan csoportosítják a szerzők a módosításokat, és hogyan írják le őket véglegesítési üzenetekkel.
  • Ki a felelős a lekéréses kérelmek áttekintéséért és jóváhagyásáért.
  • Az egyesítési ütközések feloldása.
  • A különböző ágakban végrehajtott módosítások egyesítése egyetlen ágba.
  • A tartalom tesztelésének és a tartalom üzembe helyezése előtti tesztelésének módját.
  • A módosítások üzembe helyezése fejlesztési, tesztelési és éles munkaterületeken.
  • A megoldás üzembe helyezett módosításait és verzióit vissza kell állítani.

Fontos

A DevOps által biztosított érték közvetlenül arányos a használatát meghatározó folyamatok betartásával.

A sikeres együttműködés egy jól meghatározott folyamattól függ. Fontos a fejlesztési munkafolyamat egyértelmű leírása és dokumentálása. Győződjön meg arról, hogy a kiválasztott stratégiák és folyamatok összhangban vannak a csapat meglévő gyakorlataival, és ha nem, akkor hogyan fogja kezelni a módosításokat. Továbbá győződjön meg arról, hogy a folyamatok egyértelműek és minden csapattaggal és érdekelt féllel kommunikálnak. Győződjön meg arról, hogy a folyamatokkal ismerkedő csapattagok és érdekelt felek betanultak az elfogadásuk módjába, és hogy nagyra értékelik a sikeres DevOps-bevezetés értékét.

A Power BI REST API-jai

A Power BI REST API-k használatával programozott logikát fejleszthet a tartalmak Azure DevOpsból való importálásához és üzembe helyezéséhez. Importálási művelettel importálhat Power BI-fájlokat (.pbix) egy munkaterületre. Folyamatművelettel üzembe helyezhet bizonyos tartalmakat vagy az összes tartalmat a Munkaterületek teszteléséhez vagy éles környezetéhez a Power BI üzembehelyezési folyamataival. A programozott logika az Azure Pipelinesban van definiálva.

Javasoljuk, hogy szolgáltatásnévvel hívja meg a Power BI REST API-kat a folyamatokban. A szolgáltatásnév felügyelet nélküli, automatizált tevékenységekhez készült, és nem támaszkodik a felhasználói hitelesítő adatokra. Egyes elemeket és tevékenységeket azonban nem támogatnak a Power BI REST API-k, illetve szolgáltatásnév, például adatfolyamok használata esetén.

Szolgáltatásnév használata esetén ügyeljen arra, hogy gondosan kezelje az engedélyeket. A cél az, hogy kövesse a minimális jogosultság elvét. A szolgáltatásnévhez megfelelő engedélyeket kell beállítania túlkiépítési engedélyek nélkül. Használja az Azure Key Vaultot vagy egy másik szolgáltatást, amely biztonságosan tárolja a szolgáltatásnév titkos kulcsait és hitelesítő adatait.

Figyelemfelhívás

Ha olyan adatmodellt használ, amelyet ember által olvasható metaadat-formátumként ment, az nem tehető közzé a Power BI REST API-kkal. Ehelyett közzé kell tennie az XMLA-végpont használatával. A metaadatfájlokat külső eszközökkel, például a Táblázatszerkesztő parancssori felületével teheti közzé. A metaadatfájlokat programozott módon is közzéteheti saját egyéni .NET-fejlesztésével. Az egyéni megoldások fejlesztése nagyobb erőfeszítést igényel, mivel az Analysis Management Object (AMO) ügyfélkódtárak Microsoft Tabular Object Model (TOM) bővítményét kell használnia.

Azure Pipelines

Az Azure Pipelines programozott módon automatizálja a tartalom tesztelését, kezelését és üzembe helyezését. Egy folyamat futtatásakor a folyamat lépései automatikusan futnak. A folyamattulajdonosok az üzembehelyezési igényeknek megfelelően testre szabhatják az eseményindítókat, a lépéseket és a funkciókat. Így a folyamatok száma és típusai a megoldási követelményektől függően változnak. Az Azure Pipeline például futtathat automatizált teszteket, vagy módosíthatja az adatmodell paramétereit az üzembe helyezés előtt.

A Power BI-megoldás teszteléséhez, kezeléséhez és üzembe helyezéséhez háromféle Azure-folyamat állítható be:

  • Érvényesítési folyamatok.
  • Folyamatok létrehozása.
  • Kiadási folyamatok.

Feljegyzés

Nem szükséges, hogy mindhárom folyamat szerepeljen a közzétételi megoldásban. A munkafolyamattól és az igényektől függően beállíthatja a cikkben ismertetett folyamatok egy vagy több változatát a tartalom közzétételének automatizálásához. A folyamatok testreszabásának képessége az Azure Pipelines előnye a beépített Power BI üzembehelyezési folyamatokkal szemben. Nem kell például érvényesítési folyamatnak rendelkeznie; csak buildelési és kiadási folyamatokat használhat.

Ellenőrzési folyamatok

Az érvényesítési folyamatok alapszintű minőségi ellenőrzéseket végeznek az adatmodelleken, mielőtt közzétennének egy fejlesztési munkaterületen. A távoli adattár egy ágának változásai általában aktiválják a folyamatot a módosítások automatikus teszteléssel történő ellenőrzéséhez.

Az automatizált tesztelés például az ajánlott eljárás szabálysértéseinek vizsgálata az adatmodellben az Ajánlott eljáráselemző (BPA) használatával, vagy DAX-lekérdezések közzétett szemantikai modellen való futtatásával. A tesztek eredményeit ezután a távoli adattárban tárolja a rendszer dokumentációs és naplózási célokra. A sikertelen érvényesítést tartalmazó adatmodelleket nem szabad közzétenni. Ehelyett a folyamatnak értesítenie kell a tartalomkészítőket a problémákról.

Folyamatok létrehozása

A buildelési folyamatok előkészítik az adatmodelleket a Power BI szolgáltatás való közzétételhez. Ezek a folyamatok egyetlen fájlba egyesítik a szerializált modell metaadatait, amelyet később közzétett egy kiadási folyamat (a kiadási folyamatok diagramjában). A buildelési folyamat a metaadatok egyéb módosításait is elvégezheti, például a paraméterértékek módosítását. A buildelési folyamatok olyan üzembehelyezési összetevőket hoznak létre, amelyek adatmodell-metaadatokból (adatmodellekhez) és Power BI Desktop-fájlokból (.pbix) állnak, amelyek készen állnak a Power BI szolgáltatás való közzétételre.

Kiadási folyamatok

A kiadási folyamatok tartalmakat tesznek közzé vagy helyeznek üzembe. A közzétételi megoldások általában több kiadási folyamatot tartalmaznak a célkörnyezettől függően.

  • Fejlesztési kiadási folyamat: Ez az első folyamat automatikusan aktiválódik. A buildelési és érvényesítési folyamatok sikeres végrehajtása után tartalmat tesz közzé egy fejlesztési munkaterületen.
  • Tesztelési és éles kiadási folyamatok: Ezek a folyamatok nem aktiválódnak automatikusan. Ehelyett igény szerint vagy jóváhagyáskor aktiválódnak. A tesztelési és éles kiadási folyamatok a kiadás jóváhagyása után helyeznek üzembe tartalmat egy teszt- vagy éles munkaterületen. A kiadási jóváhagyások biztosítják, hogy a tartalom ne legyen automatikusan üzembe helyezve egy tesztelési vagy éles fázisban, mielőtt készen áll. Ezeket a jóváhagyásokat a kiadáskezelők adják meg, akik a tesztelési és éles környezetek tartalomkiadásának tervezéséért és koordinálásáért felelősek.

A tartalmak tesztelési és kiadási folyamatokkal való közzétételének két különböző módszere van. Vagy egy Power BI üzembehelyezési folyamattal reklámozzák a tartalmat, vagy az Azure DevOpsból teszik közzé a tartalmat a Power BI szolgáltatás.

Az alábbi ábrán az első megközelítés látható. Ebben a megközelítésben a kiadási folyamatok a tartalomterjesztést vezényelik a munkaterületek teszteléséhez és éles környezetéhez a Power BI üzembehelyezési folyamataival. A tartalmat fejlesztési, tesztelési és éles munkaterületek segítik elő a Power BI-ban. Bár ez a megközelítés robusztusabb és egyszerűbb karbantartható, prémium szintű licencelésre van szükség.

Az ábrán az első megközelítés látható a fenti bekezdésben leírtak szerint. A diagram elemeit az alábbi táblázat ismerteti.

A diagram az első megközelítés alábbi felhasználói műveleteit, folyamatait és funkcióit mutatja be.

Cikk Leírás
1. elem. Az első megközelítésben a kiadási folyamatok az XMLA-végpont és a Power BI REST API-k használatával tesznek közzé tartalmakat a Power BI üzembehelyezési folyamataival. A tartalom közzététele és előléptetése fejlesztési, tesztelési és éles munkaterületeken történik. A Power BI üzembehelyezési folyamatai és az XMLA olvasási/írási végpontja prémium szintű funkciók.
2. elem. Egy sikeres ágegyesítés vagy egy felsőbb rétegbeli folyamat befejezése aktiválja a buildelési folyamatot. A buildelési folyamat ezután előkészíti a tartalmat a közzétételhez, és elindítja a fejlesztési kiadási folyamatot.
3. elem. A fejlesztési kiadási folyamat az XMLA-végpont (adatmodell metaadatai) vagy a Power BI REST API-k (adatmodelleket és jelentéseket tartalmazó Power BI Desktop-fájlok esetében) használatával teszi közzé a tartalmat a fejlesztési munkaterületen. A fejlesztési folyamat a Táblázatszerkesztő parancssori felületével (CLI) telepíti az adatmodell metaadatait az XMLA-végpont használatával.
4. elem. A kiadási jóváhagyás vagy az igény szerinti eseményindító aktiválja a tesztelési kiadási folyamatot.
5. elem. A tesztelési kiadási folyamat a Power BI REST API üzembehelyezési műveleteinek használatával helyezi üzembe a tartalmat, amely a Power BI üzembehelyezési folyamatot futtatja.
6. elem. A Power BI üzembehelyezési folyamata előlépteti a tartalmat a fejlesztési munkaterületről a teszt-munkaterületre. Az üzembe helyezés után a kiadási folyamat az üzembe helyezés utáni tevékenységeket a Power BI REST API-k használatával hajtja végre (a diagramon nem látható).
7. elem. A kiadás jóváhagyása vagy igény szerinti eseményindító aktiválja az éles kiadási folyamatot.
8. elem. Az éles kiadási folyamat a Power BI REST API üzembehelyezési műveleteinek használatával helyezi üzembe a tartalmat, amely a Power BI üzembehelyezési folyamatot futtatja.
9. elem. A Power BI üzembehelyezési folyamata előlépteti a teszt-munkaterület tartalmát az éles munkaterületre. Az üzembe helyezés után a kiadási folyamat az üzembe helyezés utáni tevékenységeket a Power BI REST API-k használatával hajtja végre (a diagramon nem látható).

Az alábbi ábra a második megközelítést ábrázolja. Ez a megközelítés nem használ üzembehelyezési folyamatokat. Ehelyett kiadási folyamatokkal teszi közzé a tartalmat az Azure DevOps-munkaterületek teszteléséhez és élesítéséhez. Ez a második megközelítés nem igényel prémium szintű licencelést, ha csak Power BI Desktop-fájlokat tesz közzé a Power BI REST API-kkal. Ez több beállítási erőfeszítést és összetettebb munkát igényel, mivel a Power BI-n kívül kell kezelnie az üzembe helyezést. A Power BI-n kívüli adatmegoldásokhoz a DevOps-t már használó fejlesztői csapatok jobban ismerik ezt a megközelítést. Az ezt a megközelítést használó fejlesztői csapatok összevonhatják az adatmegoldások üzembe helyezését az Azure DevOpsban.

Az ábrán a fenti bekezdésben leírt második megközelítés látható. A diagram elemeit az alábbi táblázat ismerteti.

A diagram a következő felhasználói műveleteket, folyamatokat és funkciókat mutatja be a második megközelítésben.

Cikk Leírás
1. elem. A második megközelítésben a kiadási folyamatok csak az XMLA-végpont és a Power BI REST API-k használatával tesznek közzé tartalmat. A tartalom közzé van téve fejlesztési, tesztelési és éles munkaterületeken.
2. elem. Egy sikeres ágegyesítés vagy egy felsőbb rétegbeli folyamat befejezése aktiválja a buildelési folyamatot. A buildelési folyamat ezután előkészíti a tartalmat a közzétételhez, és elindítja a fejlesztési kiadási folyamatot.
3. elem. A fejlesztési kiadási folyamat az XMLA-végpont (adatmodell metaadatai) vagy a Power BI REST API-k (adatmodelleket és jelentéseket tartalmazó Power BI Desktop-fájlok esetében) használatával teszi közzé a tartalmat a fejlesztési munkaterületen. A fejlesztési folyamat a Táblázatszerkesztő parancssori felületével (CLI) telepíti az adatmodell metaadatait az XMLA-végpont használatával.
4. elem. A kiadási jóváhagyás vagy az igény szerinti eseményindító aktiválja a tesztelési kiadási folyamatot.
5. elem. A fejlesztési kiadási folyamat az XMLA-végpont (adatmodell metaadatai) vagy a Power BI REST API-k (adatmodelleket és jelentéseket tartalmazó Power BI Desktop-fájlok) használatával teszi közzé a tartalmat a teszt-munkaterületen. A fejlesztési folyamat a Táblázatszerkesztő parancssori felületével (CLI) telepíti az adatmodell metaadatait az XMLA-végpont használatával. Az üzembe helyezés után a kiadási folyamat az üzembe helyezés utáni tevékenységeket a Power BI REST API-k használatával hajtja végre (a diagramon nem látható).
6. elem. A kiadás jóváhagyása vagy igény szerinti eseményindító aktiválja az éles kiadási folyamatot.
7. elem. A fejlesztési kiadási folyamat az XMLA-végpont (adatmodell metaadatai) vagy a Power BI REST API-k (adatmodelleket és jelentéseket tartalmazó Power BI Desktop-fájlok) használatával teszi közzé a tartalmat az éles munkaterületen. A fejlesztési folyamat a Táblázatszerkesztő parancssori felületével (CLI) telepíti az adatmodell metaadatait az XMLA-végpont használatával. Az üzembe helyezés után a kiadási folyamat az üzembe helyezés utáni tevékenységeket a Power BI REST API-k használatával hajtja végre (a diagramon nem látható).

A kiadási folyamatoknak az üzembe helyezés utáni tevékenységeket kell kezelnie. Ezek a tevékenységek magukban foglalhatják a szemantikai modell hitelesítő adatainak beállítását, vagy a Power BI-alkalmazás frissítését teszt- és éles munkaterületekhez. Javasoljuk, hogy állítson be értesítéseket , hogy tájékoztassa az érintett személyeket az üzembe helyezési tevékenységekről.

Tipp.

A verziókövetési adattár használatával a tartalomkészítők visszaállítási folyamatot hozhatnak létre. A visszaállítási folyamat az előző verzió visszaállításával megfordíthatja az utolsó üzembe helyezést. Érdemes lehet létrehozni egy külön Azure Pipelines-készletet, amelyet aktiválhat az éles módosítások visszaállításához. Alaposan gondolja át, hogy milyen folyamatokra és jóváhagyásokra van szükség a visszaállítás elindításához. Győződjön meg arról, hogy ezek a folyamatok dokumentálva vannak.

Power BI üzembehelyezési folyamatok

A Power BI üzembehelyezési folyamata három fázisból áll: fejlesztésből, tesztelésből és éles környezetből. Az üzembehelyezési folyamat minden szakaszához egyetlen Power BI-munkaterületet rendelhet hozzá. Üzembe helyezés esetén az üzembe helyezési folyamat előlépteti a Power BI-elemeket egyik munkaterületről a másikra.

Az Azure Pipelines kiadási folyamata a Power BI REST API-kkal helyezi üzembe a tartalmakat Egy Power BI üzembehelyezési folyamat használatával. Az üzembe helyezést végző felhasználók számára a munkaterülethez és az üzembe helyezési folyamathoz is hozzáférés szükséges. Javasoljuk, hogy tervezze meg az üzembehelyezési folyamat elérését , hogy a folyamat felhasználói megtekinthessék az üzembe helyezési előzményeket, és összehasonlíthassák a tartalmat.

Tipp.

Ha elkülöníti az adat-munkaterületeket a jelentéskészítési munkaterületektől, fontolja meg az Azure Pipelines használatát a tartalmak közzétételének vezénylésére több Power BI-üzembehelyezési folyamattal. A szemantikai modell először üzembe lesz helyezve, majd frissülnek. Végül a jelentések üzembe helyezése. Ez a megközelítés megkönnyíti az üzembe helyezést.

Prémium szintű licencelés

A Power BI üzembehelyezési folyamatai és az XMLA olvasási/írási végpontja prémium szintű funkciók. Ezek a funkciók a Power BI Premium-kapacitással és a Felhasználónkénti Power BI Premiummal (PPU) érhetők el.

A PPU költséghatékony módszer a nagyvállalati tartalom-közzététel fejlesztési és tesztelési munkaterületek számára történő kezelésére, amelyek általában kevés felhasználóval rendelkeznek. Ez a megközelítés további előnye, hogy elkülöníti a fejlesztési és tesztelési számítási feladatokat az éles számítási feladatoktól.

Feljegyzés

Továbbra is beállíthatja a vállalati tartalom-közzétételt prémium licenc nélkül, a kiadási folyamat szakaszának második megközelítése szerint. A második megközelítésben az Azure Pipelines használatával felügyelheti a Power BI Desktop-fájlok üzembe helyezését a fejlesztési, tesztelési és éles munkaterületeken. A modell metaadatait azonban nem helyezheti üzembe az XMLA-végpont használatával, mert nem lehet metaadat formátumú szemantikai modellt közzétenni a Power BI REST API-kkal. Emellett nem lehet a tartalmakat prémium licenc nélküli üzembehelyezési folyamatokkal rendelkező környezeteken keresztül előléptetni.

Átjáró beállítása

Általában adatátjáróra van szükség a privát szervezeti hálózaton vagy virtuális hálózaton belül található adatforrások elérésekor. Az átjáró két célja az importált adatok frissítése, valamint egy élő kapcsolatot vagy DirectQuery szemantikai modellt lekérdező jelentés megtekintése (amely nem szerepel a forgatókönyv diagramjában).

Ha több környezettel dolgozik, gyakori, hogy fejlesztési, tesztelési és éles kapcsolatokat állít be a különböző forrásrendszerekhez. Ebben az esetben adatforrás-szabályok és paraméterszabályok használatával kezelheti a környezetek közötti értékeket. Az Azure Pipelines használatával kezelheti az átjárókat a Power BI REST API-k átjáróműveleteivel .

Feljegyzés

A központi adatátjárók standard módban erősen ajánlottak személyes módban lévő átjárókon keresztül. Normál módban az adatátjáró támogatja az élő kapcsolati és DirectQuery-műveleteket (az ütemezett adatfrissítési műveletek mellett).

Rendszerfelügyelet

A tevékenységnapló rögzíti a Power BI szolgáltatás előforduló eseményeket. A Power BI-rendszergazdák a tevékenységnapló használatával naplózhatják az üzembe helyezési tevékenységeket.

A Power BI metaadat-beolvasási API-kkal bérlői leltárt hozhat létre. Az API-eredmények segítségével ellenőrizheti, hogy mely elemek lettek üzembe helyezve az egyes munkaterületeken, ellenőrizheti a leállásokat, és ellenőrizheti a biztonsági beállításokat.

Az Azure DevOpsban van egy auditnapló is, amely kívül esik a Power BI szolgáltatás. Az Azure DevOps-rendszergazdák az auditnaplóval áttekinthetik a távoli adattárakban és folyamatokban végzett tevékenységeket.

Kapcsolódó tartalom

A Power BI implementálási döntéseivel kapcsolatos további hasznos forgatókönyvekért tekintse meg a Power BI használati forgatókönyveit ismertető cikket.