Jaa

Power BI:n käyttöskenaariot: Yrityssisällön julkaiseminen

  • Artikkeli

Muistiinpano

Tämä artikkeli on osa Power BI:n käyttöönoton suunnittelun artikkelisarjaa. Tässä sarjassa keskitytään ensisijaisesti Microsoft Fabricin Power BI -kokemukseen. Johdanto sarjaan on artikkelissa Power BI:n käyttöönoton suunnittelu.

Kun sisällöntekijät tekevät yhteistyötä ja tarjoavat organisaatiolle tärkeitä analyyttisia ratkaisuja, heidän on varmistettava, että sisältö toimitetaan kuluttajille oikea-aikaisesti ja luotettavasti. Tekniset tiimit käsittelevät tätä haastetta käyttämällä DevOps-prosessia. DevOpsin avulla tiimit voivat automatisoida ja skaalata prosesseja omaksumalla käytäntöjä, jotka parantavat ja nopeuttavat toimitusta.

Muistiinpano

Samoihin haasteisiin vastaavat tietoryhmät saattavat myös harjoittaa DataOpsia. DataOps perustuu DevOpsin periaatteisiin, mutta DataOps sisältää tietojen hallintaan liittyviä lisäkäytäntöjä, kuten tietojen laadunvarmistuksen ja hallinnon. Tässä artikkelissa viitataan DevOpsiin, mutta huomaa, että taustalla olevat periaatteet voivat koskea myös DataOpsia.

Sisällöntekijät ja kuluttajat hyötyvät useista eduista, kun he omaksuvat DevOps-käytäntöjä Power BI -sisällön julkaisemiseksi. Seuraavat pisteet ovat korkean tason yleiskatsaus prosessin toiminnasta.

  1. Kehitä sisältöä ja lähetä työt etäsäilöön: Sisällöntuottajat kehittävät ratkaisunsa omalla koneellaan. He sitoutuvat ja tallentavat työnsä etäsäilöön säännöllisin väliajoin kehityksen aikana. Etäsäilö sisältää ratkaisun uusimman version, ja se on koko kehitystiimin käytettävissä.
  2. Sisällön muutosten yhteiskäyttö ja hallinta versionhallinnan avulla: Muut sisällöntuottajat voivat tehdä muutoksia ratkaisuun luomalla haaran. Haara on etäsäilön kopio. Kun nämä muutokset on valmis ja hyväksytty, -haara yhdistetään ratkaisun uusimpaan versioon. Kaikkia ratkaisun muutoksia seurataan. Tätä prosessia kutsutaan versionhallinnaksi (tai lähteen ohjausobjektiksi).
  3. Sisällön käyttöönotto ja ylentäminen putkien avulla: Itsepalvelusisällön julkaisemisen käyttöskenaariossa sisältö ylennetään (tai otetaan käyttöön) kehitys-, testi- ja tuotantotyötilojen kautta Käyttämällä Power BI:n käyttöönottoputkia. Power BI:n käyttöönottojaksot voivat ylentää sisällön Power BI Premium -työtiloihin manuaalisesti käyttöliittymän avulla tai ohjelmallisesti REST-ohjelmointirajapintojen avulla. Sen sijaan yrityssisällön julkaiseminen (tässä käyttöskenaariossa) edistää sisältöä Azure-putkien avulla. Azure Pipelines on Azure DevOps -palvelu, joka automatisoi sisällön testauksen, hallinnan ja käyttöönoton käyttämällä mukautettuja, ohjelmallisia vaiheita. Yrityssisällön julkaisemisen käyttöskenaariossa näitä putkia voidaan kutsua myös jatkuviksi integrointi- ja käyttöönottoputkiksi (tai CI/CD-putkiksi). Nämä jaksot integroivat muutokset usein ja automaattisesti ja virtaviivaistavat sisällön julkaisemista.

Tärkeä

Joskus tämä artikkeli viittaa Power BI Premiumiin tai sen kapasiteettitilauksiin (P-varastointiyksiköt). Ota huomioon, että Microsoft vahvistaa parhaillaan ostovaihtoehtoja ja poistaa käytöstä Kapasiteettikohtaisen Power BI Premiumin. Uusien ja nykyisten asiakkaiden kannattaa harkita Fabric-kapasiteettitilausten (F-varastointiyksiköiden) ostamista.

Lisätietoja on artikkelissa Power BI Premium -käyttöoikeuksien tärkeä päivitys ja Power BI Premiumin usein kysytyt kysymykset.

DevOps tukee kypsää ja järjestelmällistä lähestymistapaa sisällönhallintaan ja julkaisemiseen. Sen avulla sisällöntuottajat voivat tehdä yhteistyötä ratkaisujen parissa ja varmistaa sisällön nopean ja luotettavan toimituksen kuluttajille. Kun noudatat DevOps-käytäntöjä, hyödyt virtaviivaistetun työnkulun, pienempien virheiden ja sisällöntuottajien ja sisällöntuottajien käyttökokemuksen parantumisesta.

Voit määrittää Ja hallita Power BI -ratkaisusi DevOps-käytäntöjä Azure DevOpsin avulla. Yritysskenaarioiden avulla voit automatisoida sisällön julkaisun Azure DevOpsin ja Power BI REST -ohjelmointirajapintojen avulla kolmella eri tavalla.

  • Power BI REST -ohjelmointirajapinnat Power BI -käyttöönottoputkissa: Voit tuoda sisältöä kehitystyötiloihin ja käyttää käyttöönottoputkia sisällön käyttöönottoon testi- ja tuotantotyötilojen kautta. Hallitset yhä käyttöönottoa Azure DevOpsista ja käytät Power BI REST -ohjelmointirajapintoja käyttöönottoputkien hallitsemiseen yksittäisten sisältökohteiden sijaan. Lisäksi käytät XMLA-päätepistettä tietomallin metatietojen käyttöönottoon Power BI Desktop -tiedoston (.pbix) sijaan Azure DevOpsissa. Näiden metatietojen avulla voit seurata objektitason muutoksia versionhallinnan avulla. Vaikka tämä lähestymistapa on tehokkaampi ja helpompi ylläpitää, se edellyttää Premium-käyttöoikeuksia ja kohtalaista komentosarjatyötä sisällön tuonnin ja käyttöönoton määrittämiseksi Power BI REST -ohjelmointirajapinnoilla. Käytä tätä lähestymistapaa, kun haluat yksinkertaistaa sisällön elinkaaren hallintaa käyttöönottojaksojen avulla ja sinulla on Premium-käyttöoikeus. XMLA-päätepiste ja Power BI -käyttöönottoputket ovat Premium-ominaisuuksia.
  • Power BI REST -ohjelmointirajapinnat: Voit myös tuoda sisältöä kehitys-, testaus- ja tuotantotyötiloihin käyttämällä Azure DevOpsia ja vain Power BI REST -ohjelmointirajapintoja. Tämä lähestymistapa ei edellytä Premium-käyttöoikeuksia, mutta siihen liittyy paljon komentosarjatyötä ja asennusta, koska käyttöönottoa hallitaan Power BI:n ulkopuolella. Käytä tätä lähestymistapaa, kun haluat ottaa Power BI -sisällön käyttöön keskitetysti Azure DevOpsista tai kun sinulla ei ole Premium-käyttöoikeutta. Kahden ensimmäisen lähestymistavan visuaalinen vertailu on julkaisuputken lähestymistapojen työnkulkukaaviossa.
  • Power BI -automaatiotyökalut Power BI -käyttöönottoputkilla: Voit käyttää Power BI -automaatiotyökaluja Azure DevOps -laajennuksen avulla käyttöönottoputkien hallintaan Power BI REST -ohjelmointirajapintojen sijaan. Tämä menetelmä on vaihtoehto ensimmäiselle vaihtoehdolle, jossa käytetään Power BI REST -ohjelmointirajapintoja Power BI -käyttöönottoputkien kanssa. Power BI -automaatiotyökalujen laajennus on avoimen lähdekoodin työkalu. Sen avulla voit hallita ja julkaista sisältöä Azure DevOpsista ilman tarvetta kirjoittaa PowerShell-komentosarjoja. Käytä tätä lähestymistapaa, kun haluat hallita Azure DevOpsin käyttöönottoputkia mahdollisimman pienellä komentosarjatyöllä, ja sinulla on Premium-kapasiteetti.

Tässä artikkelissa keskitytään ensimmäiseen vaihtoehtoon, jossa käytetään Power BI REST -ohjelmointirajapintoja Power BI -käyttöönottoputkien kanssa. Siinä kuvataan, miten voit määrittää DevOps-käytäntöjä Azure DevOpsin avulla. Siinä kuvataan myös, miten voit käyttää Azure-säilöjä etäsäilöihisi ja automatisoida sisällön testauksen, integroinnin ja toimituksen Azure-putkilla. Azure DevOps ei ole ainoa tapa määrittää yrityssisällön julkaisemista, mutta yksinkertainen integrointi Power BI:hin tekee siitä hyvän valinnan.

Muistiinpano

Tämä käyttöskenaario on yksi sisällön hallinnan ja käyttöönoton skenaarioista. Sisältöyhteistyö- ja toimitusskenaarioita käsittelevässä aiheessa kuvattuja näkökohtia ei käsitellä nyt tässä artikkelissa. Lue lisätietoja näistä artikkeleista ensin.

Vihje

Microsoft Fabric tarjoaa muita vaihtoehtoja yrityssisällön julkaisemiseen Fabric Git -integroinnin avulla. Git-integroinnin avulla voit linkittää Fabric-työtilan Azure Repos -etäsäilön haaraan. Kyseiseen haaraan tallennettu sisältö synkronoi työtilan automaattisesti aivan kuin sisältö olisi julkaistu työtilaan. Sitä vastoin sisällön luojat voivat lähettää muutoksia Fabric-työtilasta etäsäilöön.

Gatin integrointi voi sujuvoittaa yhteistyötä ja sisällön julkaisemista, mutta se vaatii enemmän suunnittelua fabric-työtilojen käyttöön ja haarautumisstrategiaasi. Lisätietoja Fabric Git -integroinnin määrittämisestä ja käyttämisestä on artikkelissa Gatin integroinnin aloittaminen tai Opetusohjelma: Elinkaaren loppuminen hallinta.

Skenaariokaavio

Seuraavassa kaaviossa esitetään korkean tason yleiskatsaus yleisimpiin käyttäjätoimintoihin ja Power BI -komponentteihin, jotka tukevat yrityssisällön julkaisemista. Painopisteenä on Azure DevOpsin käyttö sisällön ohjelmallisesti hallitsemiseen ja julkaisemiseen suuressa mittakaavassa Power BI -palvelun kehitys-, testi- ja tuotantotyötilojen kautta.

Kaaviossa näytetään yrityssisällön julkaiseminen, jossa on kyse yhteistyön parantamisesta ja sisällön hallinnasta mittakaavassa Azure DevOpsin avulla. Kaavion kohteet kuvataan taulukossa.

Vihje

Suosittelemme lataamaan skenaariokaavion , jos haluat upottaa sen esitykseen, dokumentaatioon tai blogikirjoitukseen tai tulostaa sen seinäjulisteena. Koska kyseessä on SVG-kuva, voit skaalata sitä ylös- tai alaspäin ilman laadun heikkenemistä.

Skenaariokaaviossa esitetään seuraavat käyttäjän toiminnot, prosessit ja ominaisuudet.

Kohde Kuvaus
Kohde 1. Sisällöntekijät kehittävät tietomalleja käyttämällä Power BI Desktopia tai Tabular Editoria, ja he kehittävät raportteja Power BI Desktopin avulla. Sisällöntekijät tallentavat työnsä paikalliseen säilöön kehityksen aikana.
Kohde 2. Sisällöntekijät voivat kloonata etäsäilön saadakseen paikallisen kopion kyseisestä sisällöstä.
Kohde 3. Jotkin tietolähteet saattavat edellyttää paikallista tietoyhdyskäytävää tai VNet-yhdyskäytävää tietojen päivittämiseen, kuten yksityisessä organisaatioverkossa sijaitsevat tietolähteet.
Kohde 4. Sisällöntekijät sitoutuvat ja siirtävät muutokset etäsäilöön kehityksen aikana Git-asiakasohjelmistolla, kuten Visual Studio Codella. Kaaviossa etäsäilö on Azure Repos.
Kohde 5. Muut sisällöntekijät käyttävät Azure Repos -säilöjä muutosten seuraamiseen versionhallinnan avulla. He tekevät yhteistyötä vahvistamalla muutokset erillisiin haaroihin.
Kohde 6. Etäsäilön sisällön muutokset käynnistävät Azure Pipelines -putket. Vahvistusputki on ensimmäinen putkessa, joka käynnistetään. Vahvistusjakso suorittaa automaattiset testit sisällön vahvistamiseksi ennen sen julkaisemista.
Kohde 7. Sisältö, joka läpäisee vahvistusputken, käynnistää seuraavan koontijakson. Koontiversioputki valmistelee sisällön julkaisemista varten Power BI -palveluun. Tähän asti tätä prosessia kutsutaan yleensä jatkuvaksi integroinniksi (CI).
Kohde 8. Sisältö julkaistaan ja otetaan käyttöön julkaisuputkien avulla. Julkaisujaksot käyttävät joko Power BI REST -ohjelmointirajapintoja tai työtilan XMLA-päätepistettä sisällön ohjelmallisesti tuomiseen Power BI -palveluun. Käyttöönottoa julkaisuputkia käyttämällä kutsutaan yleensä jatkuvaksi käyttöönotoksi (CD).
Kohde 9. Julkaisupäällikkö hallitsee käyttöönottoa työtilojen testaamiseen ja tuotantoon Azure-putkien julkaisuhyväksynnän avulla. Yrityssisällön julkaisemisessa julkaisupäällikkö suunnittelee ja koordinoi yleensä sisällön julkaisua testi- ja tuotantoympäristöissä. Ne koordinoivat ja viestivät sisällöntuottajien, sidosryhmien ja käyttäjien kanssa.
Kohde 10. Julkaisujakso julkaisee sisältöä kehitystyötilaan tai ylentää sisällön kehityksestä testityötiloihin tai testauksen tuotantotyötiloihin.
Kohde 11. Sisällöntekijät, jotka työskentelevät työtilassa, jossa on Fabric-kapasiteetin käyttöoikeustila, voivat käyttää Git-integrointia. Git-integroinnin avulla sisällön luojat voivat työskennellä yksityisessä työtilassa kehityksen aikana. Sisällöntekijä synkronoi etähaaran (yleensä tietty ominaisuushaara tai ohjelmavirhehaara) Azure Reposista yksityiseen työtilaansa. Sisällön muutokset synkronoidaan Azure Reposin etähaaran ja työtilan välillä. Tässä skenaariossa sisällöntuottajien ei tarvitse käyttää Azure-putkia sisällön julkaisemiseen. Sisällöntekijät voivat myös säännöllisesti sitoa ja lähettää muutoksia työtilasta julkaisemisen jälkeen. Kun sisältö on valmis, sisällön luojat voivat tehdä pull-pyynnön (PR) yhdistääkseen muutokset päähaaraan.
Kohde 12. Kun käytät Git-integrointia, kehitystyötila synkronoituu päähaaran kanssa saadakseen sisällön uusimmat versiot. Tämä sisältö sisältää kaikki muutokset pull-pyynnöistä, jotka julkaisupäällikkö tarkistaa, hyväksyy ja yhdistää.
Kohde 13. Työtiloille on määritetty Fabric-kapasiteetti, Premium-kapasiteetti, käyttäjäkohtainen Premium tai Embedded-käyttöoikeustila, jotta Power BI -käyttöönottoputket ja XMLA:n luku- ja kirjoituspäätepiste voidaan sallia.
Kohde 14. Käyttöönottoputken järjestelmänvalvoja määrittää Power BI -käyttöönottoputken, jossa on kolme vaihetta: kehitys, testaus ja tuotanto. Jokainen vaihe tasataan erilliseen työtilaan Power BI -palvelussa. Käyttöönottoasetukset ja käyttöoikeudet määritetään käyttöönottoputkelle.
Kohde 15. Kehitystyötila sisältää sisällön uusimmat versiot, mukaan lukien kaikki hyväksytyt ja yhdistetyt muutokset. Kun se on hyväksytty, julkaisuputki ottaa käyttöön sisältöä kehityksestä testityötilaan.
Kohde 16. Testityötilan tarkistajat suorittavat testauksen ja laadunvarmistuksen sisällölle. Hyväksymisen jälkeen julkaisuputki ottaa käyttöön testin sisällön tuotantotyötilassa. Kun käytät Git-integrointia käyttöönottoputkien kanssa, testityötila ei synkronoidu minkään haaran kanssa.
Kohde 17. Kun käyttöönottoputki on valmis, sisällön luojat suorittavat käyttöönoton jälkeiset toimet manuaalisesti. Aktiviteettiin voi kuulua ajoitetun tietojen päivittämisen määrittäminen tai Power BI -sovelluksen päivittäminen tuotantotyötilaa varten. Kun käytät Git-integrointia käyttöönottoputkien kanssa, tuotantotyötila ei synkronoidu minkään haaran kanssa.
Kohde 18. Sisällön katselijat voivat käyttää sisältöä tuotantotyötilan tai Power BI -sovelluksen avulla.

Vihje

Suosittelemme, että tutustut myös itsepalvelusisällön julkaisemiseen ja kehittyneisiin tietomallin hallinnan käyttötilanteisiin. Yrityssisällön käyttöskenaario perustuu käsitteisiin, joita nämä skenaariot ottavat käyttöön.

Avainasiat

Seuraavassa on joitakin avainkohtia, joita tulee korostaa yrityssisällön julkaisemisen skenaariossa.

Versionhallinta

Sisällön elinkaaren aikana tehtyjen muutosten seuranta on tärkeää, jotta sisällön toimitus kuluttajille pysyy vakaana ja johdonmukaisena. Tässä käyttöskenaariossa sisällön luojat ja omistajat hallitsevat etäsäilön sisällön muutoksia versionhallinnan avulla. Versionhallinta on käytäntö hallita tiedostojen tai koodin muutoksia keskitetyssä säilössä. Tämä käytäntö mahdollistaa yhteistyön parantamisen ja versiohistorian tehokkaan hallinnan. Versionhallinta tarjoaa sisällöntekijöille etuja, kuten mahdollisuuden peruuttaa tai yhdistää muutoksia.

Sisällöntekijät kehittävät yleensä tietomalleja Tabular Editorissa versionhallinnan parantamiseksi. Toisin kuin Power BI Desktopissa kehittämäsi tietomalli, Tabular Editorissa kehitetty tietomalli tallennetaan ihmisen luettavissa olevassa metatietomuodossa. Tämä muoto ottaa käyttöön tietomallin objektitason version hallinnan. Objektitason version hallintaa kannattaa käyttää, kun teet yhteistyötä useiden henkilöiden kanssa samassa tietomallissa. Lisätietoja on kehittyneen tietomallin hallinnan käyttöskenaariossa. Et voi nähdä Power BI Desktop -tiedostoon (.pbix) tekemiäsi muutoksia, kuten raportin määritystä tai tietomallia. Et voi esimerkiksi seurata raporttisivun muutoksia, kuten käytettyjä visualisointeja, niiden sijainteja ja kenttien yhdistämismäärityksiä tai muotoiluja.

Sisällöntekijät tallentavat tietomallin metatietotiedostot ja .pbix-tiedostot keskitettyyn etäsäilöön, kuten Azure Reposiin. Tekninen omistaja koostaa nämä tiedostot. Samalla kun sisällöntekijä kehittää ratkaisua, tekninen omistaja on vastuussa ratkaisun hallinnasta ja muutosten tarkistamisesta ja niiden yhdistämisestä yhdeksi ratkaisuksi. Azure Repos tarjoaa kehittyneitä vaihtoehtoja muutosten seurantaan ja hallintaan. Tämä lähestymistapa eroaa omatoimisen sisällön julkaisemisen käyttöskenaariossa kuvatusta lähestymistavasta, jossa tekijä käyttää OneDrive-tallennustilaa version seurannan kanssa. Hyvin valvotun ja dokumentoidun säilön ylläpitäminen on välttämätöntä, koska se on kaiken sisällön ja yhteistyön perusta.

Seuraavassa on joitakin tärkeitä huomioon otettavia seikkoja, joiden avulla voit määrittää etäsäilön versionhallintaa varten.

  • Laajuus: Määritä säilön laajuus selkeästi. Ihannetapauksessa säilön laajuus on sama kuin jatkotason työtilat ja sovellukset, joita käytät sisällön toimittamiseen kuluttajille.
  • Käyttö: Sinun tulee määrittää käyttöoikeus säilöön käyttämällä samankaltaista käyttöoikeusmallia kuin olet määrittänyt käyttöönottojakson käyttöoikeuksille ja työtilarooleille. Sisällöntekijät tarvitsevat säilön käyttöoikeuden.
  • Dokumentaatio: Lisää tekstitiedostoja säilöön sen tarkoituksen, omistajuuden, käyttöoikeuksien ja määritettyjen prosessien dokumentoimiseksi. Dokumentaatiossa voidaan esimerkiksi kuvata, miten muutokset tehdään ja miten muutokset tehdään.
  • Työkalut: Sisällöntekijät tarvitsevat Git-asiakasohjelman , kuten Visual Studion tai Visual Studio Coden, jotta he voivat lähettää muutoksia etäsäilöön. Git on hajautettu versiontarkistusjärjestelmä, joka seuraa tiedostojesi muutoksia. Jos haluat oppia Gitin perusteet, katso Mikä on Git?.

Muistiinpano

Harkitse Git Large File Storagen (LFS) käyttöä, jos aiot sitoa Power BI Desktop -tiedostot (.pbix). Git LFS tarjoaa lisäasetuksia, joilla hallitaan tiedostoja, joissa muutokset eivät ole näkyvissä (tiedostoja, joita ei voi tunnistaa), kuten .pbix-tiedostoa. Voit esimerkiksi käyttää tiedostojen lukitsemista estääksesi Power BI -raportin samanaikaiset muutokset kehityksen aikana. Git LFS:llä on kuitenkin oma asiakas ja määritys.

Yhteistyö Azure DevOpsin kanssa

Kun ratkaisun vaikutusalue ja monimutkaisuus kasvavat, useiden sisällöntekijöiden ja omistajien on ehkä tehtävä yhteistyötä. Sisällöntekijät ja omistajat viestivät ja tekevät yhteistyötä keskitetyssä, organisoidussa keskuksessa Azure DevOpsin avulla.

Jos haluat tehdä yhteistyötä ja viestiä Azure DevOpsissa, voit käyttää tukipalveluja.

  • Azure Boards: Sisällön omistajat käyttävät tauluja työkohteiden seurantaan. Työkohteet määritetään kullekin tiimin kehittäjälle, ja ne kuvaavat ratkaisun ongelmia, virheitä tai ominaisuuksia sekä vastaavia sidosryhmiä.
  • Azure Wiki: Sisällöntuottajat jakavat tiiminsä kanssa tietoja, joiden avulla he ymmärtävät ratkaisun ja antavat siihen oman panoksensa.
  • Azure-säilöt: Sisällöntekijät seuraavat etäsäilön muutoksia ja yhdistävät ne yhdeksi ratkaisuksi.
  • Azure-putket: Putken omistajat määrittävät ohjelmallisen logiikan ratkaisun käyttöönottoa varten joko automaattisesti tai pyydettäessä.

Yhteistyötyönkulun kaavio

Seuraavassa kaaviossa esitetään korkean tason yleiskatsaus yhdestä esimerkistä siitä, miten Azure DevOps mahdollistaa yhteistyön yrityssisällön julkaisemisen käyttöskenaariossa. Tässä kaaviossa keskitytään Azure DevOpsin käyttöön, jolla luodaan jäsennetty ja dokumentoitu sisällön julkaisuprosessi.

Kaavio edellä olevan kappaleen mukaisesti. Kaavion kohteet on kuvattu alla olevassa taulukossa.

Kaaviossa esitetään seuraavat käyttäjän toiminnot, prosessit ja ominaisuudet.

Kohde Kuvaus
Kohde 1. Sisällöntekijä tekee uuden lyhytikäisen haaran kloonaamalla päähaaran, joka sisältää sisällön uusimman version. Uutta haaraa kutsutaan usein ominaisuushaaraksi, koska sitä käytetään tietyn ominaisuuden kehittämiseen tai tietyn ongelman korjaamiseen.
Kohde 2. Sisällöntekijä sitoo muutokset paikalliseen säilöön kehityksen aikana.
Kohde 3. Sisällöntekijä linkittää muutoksensa työkohteisiin, joita hallitaan Azure Boardsissa. Työkohteet kuvaavat tietyn kehityksen, parannukset tai niiden haaraan kuuluvat virheenkorjaukset.
Kohde 4. Sisällöntekijä tekee muutokset säännöllisesti. Kun sisältö on valmis, sisällön tekijä julkaisee haaransa etäsäilöön.
Kohde 5. Testatakseen muutoksiaan sisällön tekijä ottaa ratkaisunsa käyttöön eristetyssä työtilassa kehitystyötään varten (ei näytetä tässä kaaviossa). Sisällöntekijä voi myös synkronoida ominaisuushaaran työtilaan Fabric Git -integroinnin avulla.
Kohde 6. Sisällöntuottajat ja sisällön omistajat dokumentoivat ratkaisun ja sen prosessit Azure Wikissä, joka on koko kehitystiimin käytettävissä.
Kohde 7. Kun sisältö on valmis, sisällön tekijä avaa pull-pyynnön, joka yhdistää ominaisuushaaran päähaaraan.
Kohde 8. Tekninen omistaja on vastuussa pull-pyynnön tarkistamisesta ja muutosten yhdistämisestä. Kun käyttäjä hyväksyy pull-pyynnön, hän yhdistää ominaisuushaaran päähaaraan.
Kohde 9. Onnistunut yhdistäminen käynnistää ratkaisun käyttöönoton kehitystyötilassa Azure-putken avulla (ei näytetä tässä kaaviossa). Kun käytät Fabric Git -integrointia, päähaara synkronoituu kehitystyötilaan.
Kohde 10. Julkaisupäällikkö suorittaa ratkaisun lopullisen tarkistuksen ja hyväksynnän. Tämä julkaisuhyväksyntä estää ratkaisun julkaisun, ennen kuin se on valmis. Yrityssisällön julkaisemisessa julkaisupäällikkö suunnittelee ja koordinoi yleensä sisällön julkaisua testi- ja tuotantotyötiloissa. Ne koordinoivat ja viestivät sisällöntuottajien, sidosryhmien ja käyttäjien kanssa.
Kohde 11. Kun julkaisupäällikkö hyväksyy julkaisun, Azure Pipelines valmistelee ratkaisun käyttöönottoa varten automaattisesti. Vaihtoehtoisesti Azure-putki voi myös käynnistää käyttöönottoputken sisällön ylentämiseksi työtilojen välillä.
Kohde 12. Käyttäjät testaavat ja vahvistavat testityötilan sisältöä. Kun käytät Git-integrointia Azure Pipelinesin kanssa käyttöönottoa varten, testityötila ei synkronoidu minkään haaran kanssa.
Kohde 13. Kun käyttäjät ovat hyväksyneet ja vahvistaneet muutokset, julkaisupäällikkö tarkistaa ja hyväksyy ratkaisun lopullisesti, jotta se voidaan ottaa käyttöön tuotantotyötilassa.
Kohde 14. Käyttäjät tarkastelevat sisältöä, joka on julkaistu tuotantotyötilassa. Kun käytät Git-integrointia Azure Pipelinesin kanssa käyttöönottoa varten, tuotantotyötila ei synkronoidu minkään haaran kanssa.

Tarkemmin sanottuna sisällöntuottajat voivat tehdä yhteistyötä haaraamisstrategian avulla. Haarautumisstrategia on se, miten sisällöntuottajat luovat, käyttävät ja yhdistävät haaroja sisällön muutosten tekemiseksi ja hallitsemiseksi tehokkaasti. Yksittäiset sisällöntekijät työskentelevät erillään paikallisessa säilössään. Kun ne ovat valmiita, ne yhdistävät muutoksensa yhtenä ratkaisuna etäsäilössä. Sisällöntekijöiden tulee rajata työ haaraan linkittämällä heidät tietyn kehityksen, parannuksien tai ohjelmavirhekorjausten työkohteisiin. Jokainen sisällöntekijä luo etäsäilön oman haaran oman haaransa oman toimialaansa varten. Paikallisen ratkaisun työ on varattu ja lähetetty etäsäilön haaran versioon vahvistusviestillä. Vahvistusviesti kuvaa vahvistukseen tehtyjä muutoksia.

Jos haluat yhdistää muutokset, sisällön luoja avaa pull-pyynnön. Pull-pyyntö on vertaisarviointia varten lähettävä pyyntö, joka voi johtaa tehdyn työn yhdistämiseen yhdeksi ratkaisuksi. Yhdistäminen voi aiheuttaa ristiriitoja, jotka on ratkaistava ennen kuin haara voidaan yhdistää. Pull-pyyntöjen tarkistaminen on tärkeää sen varmistamiseksi, että luojat noudattavat organisaation standardeja ja kehitys-, laatu- ja vaatimustenmukaisuusstandardeja.

Yhteistyösuositukset

On suositeltavaa määrittää jäsennelty prosessi sille, miten sisällöntuottajat tekevät yhteistyötä. Varmista, että määrität:

  • Miten työ suodatetaan ja miten haaroja luodaan, nimetään ja käytetään.
  • Miten tekijät ryhmittelevät muutoksia ja kuvailevat niitä muutos muutosviestien avulla.
  • Kuka on vastuussa pull-pyyntöjen tarkistamisesta ja hyväksymisestä.
  • Yhdistämisristiriitojen ratkaiseminen.
  • Miten eri haaroihin tehdyt muutokset yhdistetään yhdeksi haaraksi.
  • Miten sisältöä testataan ja kuka suorittaa testauksen ennen sisällön käyttöönottoa.
  • Miten ja milloin muutokset otetaan käyttöön kehitys-, testi- ja tuotantotyötiloissa.
  • Miten ja milloin käyttöönotetut muutokset tai versiot ratkaisusta peruutetaan.

Tärkeä

DevOpsin antama arvo on suoraan suhteessa sen käyttöä määrittävän prosessin noudattamiseen.

Onnistunut yhteistyö riippuu määritellystä prosessista. On tärkeää kuvailla ja dokumentoida päästä päähän -kehitystyönkulku. Varmista, että valitut strategiat ja prosessit ovat linjassa tiimisi nykyisten käytäntöjen kanssa, ja jos ei, miten voit hallita muutoksia. Varmista myös, että prosessit ovat selkeitä ja viestitään kaikille tiimin jäsenille ja sidosryhmille. Varmista, että prosessien uudet tiimin jäsenet ja sidosryhmät on koulutettu niiden käyttöönottoon ja että he arvostavat onnistuneen DevOps-käyttöönoton arvoa.

Power BI:n REST-ohjelmointirajapinnat

Kehität ohjelmallisen logiikan tuoda ja ottaa käyttöön sisältöä Azure DevOpsista Power BI REST -ohjelmointirajapintojen avulla. Voit tuoda Power BI -tiedostoja (.pbix) työtilaan tuontitoiminnon avulla. Putkitoiminnon avulla voit ottaa käyttöön sisältöä tai kaikkea sisältöä työtilojen testaamiseen tai tuotantoon Power BI -käyttöönottoputkia käyttämällä. Ohjelmallinen logiikka määritetään Azure-putkissa.

Suosittelemme, että käytät palvelun päänimeä power BI REST -ohjelmointirajapintojen kutsumiseen jaksoissasi. Palvelun päänimi on tarkoitettu automaattisiin ja valvottaviin toimintoihin, eikä se perustu käyttäjän tunnistetietoihin. Power BI REST -ohjelmointirajapinnat eivät kuitenkaan tue joitakin kohteita ja toimintoja tai käytettäessä palvelun päänimeä, kuten tietovoita.

Kun käytät palvelun päänimeä, varmista, että hallitset käyttöoikeuksia huolellisesti. Tavoitteenasi on olla noudattaa pienintä etuoikeutta. Sinun tulisi määrittää palvelun päänimelle riittävät käyttöoikeudet ilman ylivarausoikeuksia. Käytä Azure Key Vaultia tai muuta palvelua, joka tallentaa turvallisesti palvelun päänimen salaisuudet ja tunnistetiedot.

Varoitus

Jos sinulla on tietomalli, joka on tallennettu ihmisen luettavissa olevana metatietomuotona, sitä ei voi julkaista Power BI REST -ohjelmointirajapintojen avulla. Sinun on sen sijaan julkaistava se XMLA-päätepisteen avulla. Voit julkaista metatietotiedostoja kolmansien osapuolten työkaluilla, kuten Tabular Editorin komentoriviliittymällä (CLI). Voit myös julkaista metatietotiedostoja ohjelmallisesti käyttämällä omaa mukautettua .NET-kehitystäsi. Mukautetun ratkaisun kehittäminen vaatii enemmän vaivaa, koska sinun on käytettävä Microsoft Tabular Object Model (TOM) -laajennusta Analysis Management Object (AMO) -asiakaskirjastoissa.

Azure-putket

Azure-putket automatisoivat ohjelmallisesti sisällön testauksen, hallinnan ja käyttöönoton. Kun putki suoritetaan, putken osavaiheet suoritetaan automaattisesti. Jakson omistajat voivat mukauttaa sen käynnistimiä, vaiheita ja toimintoja käyttöönottotarpeiden mukaan. Näin ollen putkien määrä ja tyypit vaihtelevat ratkaisun vaatimusten mukaan. Azure-putki voi esimerkiksi suorittaa automaattisia testejä tai muokata tietomallin parametreja ennen käyttöönottoa.

Voit määrittää kolmentyyppisiä Azure-putkia, joilla voit testata, hallita ja ottaa käyttöön Power BI -ratkaisusi:

  • Vahvistusputket.
  • Luo putkia.
  • Julkaisuputket.

Muistiinpano

Kaikkien kolmen putken ei tarvitse olla julkaisuratkaisussasi. Työnkulun ja tarpeiden mukaan voit määrittää yhden tai useamman tässä artikkelissa kuvatun putkien variantin sisällön julkaisemisen automatisoimiseksi. Tämä mahdollisuus mukauttaa putkia on Azure-putkien etu verrattuna sisäisiin Power BI -käyttöönottoputkiin. Sinulla ei esimerkiksi tarvitse olla vahvistusputkea. voit käyttää vain koontiversio- ja julkaisuputkia.

Vahvistusputket

Vahvistusjaksot suorittavat tietomallien perustason laaduntarkistuksia ennen kuin ne julkaistaan kehitystyötilassa. Yleensä etäsäilön haaran muutokset käynnistävät putken vahvistaakseen nämä muutokset automaattisella testauksella.

Automatisoituja testejä ovat esimerkiksi tietomallin tarkistaminen parhaiden käytäntöjen sääntörikkomusten varalta käyttämällä best practice analyzeria (BPA) tai DAX-kyselyiden suorittaminen julkaistua semanttista mallia vasten. Näiden testien tulokset tallennetaan sitten etäsäilöön dokumentaatiota ja valvontaa varten. Tietomalleja, jotka eivät pysty tarkistamaan oikeellisuustarkistusta, ei tule julkaista. Sen sijaan putken pitäisi ilmoittaa ongelmista sisällöntekijöille.

Putkien muodostaminen

Koontijaksot valmistelevat tietomallit julkaistavaksi Power BI -palveluun. Nämä jaksot yhdistävät sarjoitetut mallin metatiedot yksittäiseksi tiedostoksi, joka julkaistaan myöhemmin julkaisuputkessa (kuvataan julkaisuputkikaaviossa). Koontiputki voi tehdä myös muita muutoksia metatietoihin, kuten muokata parametriarvoja. Koontiversioputket tuottavat käyttöönottoartefaktit, jotka koostuvat tietomallin metatiedoista (tietomalleille) ja Power BI Desktop -tiedostoista (.pbix), jotka ovat valmiita julkaistavaksi Power BI -palveluun.

Julkaisuputket

Julkaisujaksot julkaisevat tai ottavat käyttöön sisältöä. Julkaisuratkaisu sisältää yleensä useita julkaisuputkia kohdeympäristöstä riippuen.

  • Kehityksen julkaisuputki: Tämä ensimmäinen putki käynnistetään automaattisesti. Se julkaisee sisältöä kehitystyötilaan koonti- ja vahvistusjaksojen onnistuttua.
  • Testin ja tuotannon julkaisuputket: Näitä putkia ei käynnistetä automaattisesti. Sen sijaan ne käynnistetään pyydettäessä tai kun ne hyväksytään. Testin ja tuotannon julkaisujaksot ottavat sisällön käyttöön testi- tai tuotantotyötilassa julkaisuhyväksynnän jälkeen. Julkaisuhyväksynnät varmistavat , että sisältöä ei automaattisesti käytetä testi- tai tuotantovaiheessa ennen kuin se on valmis. Nämä hyväksynnät tarjoaa julkaisupäälliköt, jotka vastaavat sisällön julkaisun suunnittelusta ja koordinoinnista testi- ja tuotantoympäristöissä.

Voit julkaista testi- ja julkaisuputkien sisällön kahdella eri tavalla. He joko ylentävät sisältöä Käyttämällä Power BI -käyttöönottoputkea tai julkaisevat sisältöä Azure DevOpsin Power BI -palveluun.

Seuraava kaavio esittää ensimmäisen lähestymistavan. Tässä lähestymistavassa julkaisuputket järjestävät sisällön käyttöönoton testi- ja tuotantotyötilojen testaamiseksi Power BI -käyttöönottoputkia käyttämällä. Sisältöä ylennetään Power BI:n kehitys-, testi- ja tuotantotyötilojen kautta. Vaikka tämä lähestymistapa on tehokkaampi ja yksinkertaisempi ylläpitää, se edellyttää Premium-käyttöoikeuksia.

Kaaviossa näkyy ensimmäinen menetelmä edellä olevan kappaleen mukaisesti. Kaavion kohteet on kuvattu alla olevassa taulukossa.

Kaaviossa esitetään seuraavat ensimmäisen lähestymistavan käyttäjän toiminnot, prosessit ja ominaisuudet.

Kohde Kuvaus
Kohde 1. Ensimmäisessä lähestymistavassa julkaisujaksot julkaisevat sisältöä käyttämällä XMLA-päätepistettä ja Power BI REST -ohjelmointirajapintoja Power BI -käyttöönottoputkissa. Sisältö julkaistaan ja sitä ylennetään kehitys-, testi- ja tuotantotyötilojen kautta. Power BI:n käyttöönottoputket ja XMLA:n luku- ja kirjoituspäätepiste ovat Premium-ominaisuuksia.
Kohde 2. Joko onnistunut haaran yhdistäminen tai yläpuolisen säilön putken valmistuminen käynnistää koontiputken. Koontiversioputki valmistelee sitten sisällön julkaisemista varten ja käynnistää kehityksen julkaisuputken.
Kohde 3. Kehityksen julkaisuputki julkaisee sisältöä kehitystyötilaan käyttämällä XMLA-päätepistettä (tietomallin metatiedoille) tai Power BI REST -ohjelmointirajapintoja (Power BI Desktop -tiedostoille, jotka voivat sisältää tietomalleja ja raportteja). Kehitysjakso käyttää Tabular Editor -komentorivikäyttöliittymää (CLI) tietomallin metatietojen käyttöönottoon XMLA-päätepisteen avulla.
Kohde 4. Julkaisun hyväksyntä tai pyydettäessä suoritettava käynnistin aktivoi testin julkaisuputken.
Kohde 5. Testijulkaisuputki ottaa sisällön käyttöön käyttämällä Power BI:n REST-ohjelmointirajapinnan käyttöönottotoimintoja, jotka suorittavat Power BI -käyttöönottoputken.
Kohde 6. Power BI -käyttöönottoputki ylentää sisällön kehitystyötilasta testityötilaan. Käyttöönoton jälkeen julkaisuputki suorittaa käyttöönoton jälkeiset toimet Power BI REST -ohjelmointirajapintojen avulla (ei näytetä kaaviossa).
Kohde 7. Julkaisun hyväksyntä tai pyydettäessä -käynnistin aktivoi tuotannon julkaisuputken.
Kohde 8. Tuotannon julkaisuputki ottaa sisällön käyttöön käyttämällä Power BI:n REST-ohjelmointirajapinnan käyttöönottotoimintoja, jotka suorittavat Power BI -käyttöönottoputken.
Kohde 9. Power BI -käyttöönottoputki ylentää sisällön testityötilasta tuotantotyötilaan. Käyttöönoton jälkeen julkaisuputki suorittaa käyttöönoton jälkeiset toimet Power BI REST -ohjelmointirajapintojen avulla (ei näytetä kaaviossa).

Seuraavassa kaaviossa esitetään toinen lähestymistapa. Tässä lähestymistavassa ei käytetä käyttöönottoputkia. Sen sijaan se käyttää julkaisuputkia sisällön julkaisemiseen Azure DevOpsin testi- ja tuotantotyötilojen kautta. Tämä toinen lähestymistapa ei edellytä Premium-käyttöoikeuksia, kun julkaiset vain Power BI Desktop -tiedostoja Power BI REST -ohjelmointirajapinnoilla. Siihen liittyy enemmän määritystoimia ja monimutkaisuutta, koska käyttöönottoa on hallittava Power BI:n ulkopuolella. Kehitystiimit, jotka käyttävät DevOpsia jo Power BI:n ulkopuolisiin tietoratkaisuihin, saattavat tuntea tämän lähestymistavan paremmin. Tätä lähestymistapaa käyttävät kehitystiimit voivat yhdistää tietoratkaisujen käyttöönoton Azure DevOpsissa.

Kaaviossa näkyy toinen menetelmä edellä kuvatulla tavalla. Kaavion kohteet on kuvattu alla olevassa taulukossa.

Kaaviossa esitetään seuraavat käyttäjän toiminnot, prosessit ja ominaisuudet toisessa lähestymistavassa.

Kohde Kuvaus
Kohde 1. Toisessa lähestymistavassa julkaisujaksot julkaisevat sisältöä käyttämällä XMLA-päätepistettä ja vain Power BI REST -ohjelmointirajapintoja. Sisältö julkaistaan kehitys-, testi- ja tuotantotyötiloihin.
Kohde 2. Joko onnistunut haaran yhdistäminen tai yläpuolisen säilön putken valmistuminen käynnistää koontiputken. Koontiversioputki valmistelee sitten sisällön julkaisemista varten ja käynnistää kehityksen julkaisuputken.
Kohde 3. Kehityksen julkaisuputki julkaisee sisältöä kehitystyötilaan käyttämällä XMLA-päätepistettä (tietomallin metatiedoille) tai Power BI REST -ohjelmointirajapintoja (Power BI Desktop -tiedostoille, jotka voivat sisältää tietomalleja ja raportteja). Kehitysjakso käyttää Tabular Editor -komentorivikäyttöliittymää (CLI) tietomallin metatietojen käyttöönottoon XMLA-päätepisteen avulla.
Kohde 4. Julkaisun hyväksyntä tai pyydettäessä suoritettava käynnistin aktivoi testin julkaisuputken.
Kohde 5. Kehityksen julkaisuputki julkaisee sisältöä testityötilaan käyttämällä XMLA-päätepistettä (tietomallin metatiedoille) tai Power BI REST -ohjelmointirajapintoja (Power BI Desktop -tiedostoille, jotka voivat sisältää tietomalleja ja raportteja). Kehitysjakso käyttää Tabular Editor -komentorivikäyttöliittymää (CLI) tietomallin metatietojen käyttöönottoon XMLA-päätepisteen avulla. Käyttöönoton jälkeen julkaisuputki suorittaa käyttöönoton jälkeiset toimet Power BI REST -ohjelmointirajapintojen avulla (ei näytetä kaaviossa).
Kohde 6. Julkaisun hyväksyntä tai pyydettäessä -käynnistin aktivoi tuotannon julkaisuputken.
Kohde 7. Kehityksen julkaisuputki julkaisee sisältöä tuotantotyötilaan käyttämällä XMLA-päätepistettä (tietomallin metatiedoille) tai Power BI REST -ohjelmointirajapintoja (Power BI Desktop -tiedostoille, jotka voivat sisältää tietomalleja ja raportteja). Kehitysjakso käyttää Tabular Editor -komentorivikäyttöliittymää (CLI) tietomallin metatietojen käyttöönottoon XMLA-päätepisteen avulla. Käyttöönoton jälkeen julkaisuputki suorittaa käyttöönoton jälkeiset toimet Power BI REST -ohjelmointirajapintojen avulla (ei näytetä kaaviossa).

Julkaisujaksojen tulee hallita käyttöönoton jälkeisiä toimintoja. Nämä toiminnot voivat sisältää semanttisen mallin tunnistetietojen määrittämisen tai Power BI -sovelluksen päivittämisen testi- ja tuotantotyötiloja varten. Suosittelemme, että määrität ilmoituksia, jotka ilmoittavat asianmukaisille henkilöille käyttöönottotoimista.

Vihje

Säilön versionhallinnan avulla sisällöntuottajat voivat luoda palautusprosessin. Palautusprosessi voi kumota viimeisimmän käyttöönoton palauttamalla edellisen version. Harkitse erillisen Azure-putkien joukon luomista. Voit käynnistää tuotantomuutosten palauttamisen. Mieti tarkkaan, mitä prosesseja ja hyväksyntöjä vaaditaan peruunnmisen aloittamiseen. Varmista, että nämä prosessit on dokumentoitu.

Power BI:n käyttöönottoputket

Power BI:n käyttöönottojakso koostuu kolmesta vaiheesta: kehityksestä, testauksesta ja tuotannosta. Voit määrittää yhden Power BI -työtilan käyttöönottoputken kuhunkin vaiheeseen. Käyttöönoton yhteydessä käyttöönottojakso ylentää Power BI -kohteet työtilasta toiseen.

Azure Pipelines -julkaisuputki käyttää Power BI REST -ohjelmointirajapintoja sisällön käyttöönottoon Power BI -käyttöönottoputken avulla. Käyttöönottoa suorittaville käyttäjille vaaditaan käyttöoikeus sekä työtilaan että käyttöönottoputkeen . Suosittelemme, että suunnittelet käyttöönottoputken käytön , jotta jakson käyttäjät voivat tarkastella käyttöönottohistoriaa ja vertailla sisältöä.

Vihje

Kun erotat tietotyötilat raportointityötiloista, harkitse Azure-putkien avulla sisällön julkaisemisen järjestämistä useilla Power BI -käyttöönottoputkilla. Semanttinen malli otetaan käyttöön ensin, ja sitten ne päivitetään. Lopuksi raportteja otetaan käyttöön. Tämän lähestymistavan avulla voit yksinkertaistaa käyttöönottoa.

Premium-käyttöoikeudet

Power BI:n käyttöönottoputket ja XMLA:n luku- ja kirjoituspäätepiste ovat Premium-ominaisuuksia. Nämä ominaisuudet ovat käytettävissä Power BI Premium -kapasiteetissa ja käyttäjäkohtaisessa Power BI Premiumissa (PPU).

PPU on kustannustehokas tapa hallita yrityssisällön julkaisemista kehitys- ja testityötiloissa, joilla on yleensä vähän käyttäjiä. Tämän lähestymistavan etuna on myös kehitys- ja testikuormitusten eristäminen tuotantokuormituksista.

Muistiinpano

Voit silti määrittää yrityssisällön julkaisemisen ilman Premium-käyttöoikeutta, kuten julkaisuputkiosion toisessa lähestymistavassa on kuvattu. Toisessa lähestymistavassa käytetään Azure Pipelinesia Power BI Desktop -tiedostojen käyttöönoton hallintaan kehitys-, testi- ja tuotantotyötiloissa. Et kuitenkaan voi ottaa käyttöön mallin metatietoja XMLA-päätepisteen avulla, koska ei ole mahdollista julkaista metatietomuodon semanttista mallia Power BI REST -ohjelmointirajapinnoilla. Sisältöä ei myöskään voi ylentää käyttöönottoputkia sisältävien ympäristöjen kautta ilman Premium-käyttöoikeutta.

Yhdyskäytävän asennus

Yleensä tietoyhdyskäytävää tarvitaan käytettäessä tietolähteitä, jotka ovat yksityisessä organisaatioverkossa tai näennäisverkossa. Yhdyskäytävän kaksi tarkoitus on päivittää tuodut tiedot ja tarkastella raporttia, joka tekee kyselyn reaaliaikaiseen yhteyteen tai semanttiseen DirectQuery-malliin (ei esitetty skenaariokaaviossa).

Kun työskentelet useissa ympäristöissä, on tavallista määrittää kehitys-, testi- ja tuotantoyhteyksiä eri lähdejärjestelmiin. Käytä tässä tapauksessa tietolähdesääntöjä ja parametrisääntöjä ympäristöjen välisten erojen hallitsemiseen. Azure-putkien avulla voit hallita yhdyskäytäviä käyttämällä Power BI REST -ohjelmointirajapintojen yhdyskäytävätoimintoja .

Muistiinpano

Keskitettyä tietoyhdyskäytävää normaalissa tilassa suositellaan vahvasti henkilökohtaisen tilan yhdyskäytäviä varten. Normaalissa tilassa tietoyhdyskäytävä tukee reaaliaikaista yhteyttä ja DirectQuery-toimintoja (ajoitettujen tietojen päivitystoimintojen lisäksi).

Järjestelmän valvonta

Toimintoloki kirjaa Power BI -palvelussa tapahtuvat tapahtumat. Power BI -järjestelmänvalvojat voivat valvoa käyttöönottotoimia toimintalokin avulla.

Voit luoda vuokraajaluettelon Power BI - metatietojen skannauksen ohjelmointirajapintojen avulla. Ohjelmointirajapinnan tulokset ovat hyödyllisiä, jotta voit tarkistaa, mitkä kohteet on otettu käyttöön kussakin työtilassa, tarkistaa historiatiedot ja vahvistaa suojausasetukset.

Azure DevOpsissa on myös valvontaloki , joka sijaitsee Power BI -palvelun ulkopuolella. Azure DevOps -järjestelmänvalvojat voivat valvontalokin avulla tarkastella etäsäilöjen ja -putkien toimintoja.

Liittyvä sisältö

Muita hyödyllisiä skenaarioita, jotka auttavat Power BI:n toteutuspäätöksissä, on artikkelissa Power BI:n käyttöskenaariot .