Planning van power BI-implementatie: inhoud implementeren

Notitie

Dit artikel maakt deel uit van de Power BI-implementatieplanning reeks artikelen. Deze reeks richt zich voornamelijk op de Power BI-ervaring binnen Microsoft Fabric. Zie Power BI-implementatieplanningvoor een inleiding tot de reeks.

Dit artikel helpt u bij het implementeren van inhoud als onderdeel van het beheren van de levenscyclus van inhoud. Het is voornamelijk gericht op:

• Fabric-beheerders: de beheerders die verantwoordelijk zijn voor het toezicht op Fabric in de organisatie. Fabric-beheerders moeten mogelijk samenwerken met andere beheerders, zoals beheerders die toezicht houden op Microsoft 365 of Azure DevOps.
• COE- en BI-teams (Center of Excellence): de teams die verantwoordelijk zijn voor het beheer van Power BI in de organisatie. Deze teams omvatten besluitvormers die bepalen hoe de levenscyclus van Power BI-inhoud moet worden beheerd. Deze teams kunnen ook releasemanagers bevatten, die de levenscyclus van inhoudsreleases verwerken en technici die de onderdelen maken en beheren die nodig zijn om effectief levenscyclusbeheer te gebruiken en te ondersteunen.
• makers en eigenaren van inhoud: gebruikers die inhoud maken die ze willen publiceren in de Fabric-portal om met anderen te delen. Deze personen zijn verantwoordelijk voor het beheren van de levenscyclus van de Power BI-inhoud die ze maken.

Levenscyclusbeheer bestaat uit de processen en procedures die u gebruikt om inhoud van het maken ervan tot de uiteindelijke buitengebruikstelling af te handelen. In de derde fase van levenscyclusbeheervalideert u inhoudswijzigingen, waarbij validatie wordt uitgevoerd door zowel makers van inhoud als gebruikers. In de vierde fase implementeert u inhoud voor consumenten om deze te gebruiken.

Als u Power BI-inhoud wilt delen met consumenten, moet u eerst de inhoud publiceren (of implementeren ) naar een Fabric-werkruimte. Het implementeren van inhoud omvat ook het verplaatsen van die inhoud tussen omgevingen, zoals het implementeren van een ontwikkelwerkruimte naar een testwerkruimte of van een testwerkruimte naar een productiewerkruimte.

In de volgende afbeelding ziet u de levenscyclus van Power BI-inhoud, waarbij fase vier wordt gemarkeerd, waar u inhoud implementeert.

Notitie

Zie het eerste artikel in deze reeksvoor een overzicht van het beheer van de levenscyclus van inhoud.

Dit artikel is gericht op belangrijke overwegingen en beslissingen voor het implementeren van inhoud gedurende de gehele levenscyclus. Zie voor meer informatie over het implementeren van inhoud:

• Migreren naar Power BI: Inhoud implementeren: in dit artikel worden belangrijke overwegingen en beslissingen voor implementatie beschreven wanneer u vanuit andere technologieën naar Power BI migreert.
• BI-oplossingsplanning: Implementeren, ondersteunen en bewaken: in dit artikel wordt beschreven hoe u de implementatie kunt plannen wanneer u uw Power BI- of Fabric-oplossing voor het eerst maakt.
• Power BI-implementatieplanning: gebruiksscenario voor selfservice-publicatie van inhoud: Dit artikel beschrijft hoe selfservicegebruikers inhoud kunnen implementeren met behulp van OneDrive voor Werk en School en Fabric-implementatiepijplijnen.
• Power BI-implementatieplanning: scenario voor publicatie van bedrijfsinhoud: in dit artikel wordt beschreven hoe centrale teams inhoud kunnen implementeren en beheren met behulp van Azure DevOps.

U implementeert inhoud op twee hoofdpunten tijdens de levenscyclus van de inhoud:

• Wanneer u inhoud publiceert naar een ontwikkelwerkruimte. Op dit moment publiceert u inhoud om uw wijzigingen te valideren.
• Wanneer u inhoud tussen twee werkruimten promoveert (zoals het promoveren van inhoud van een ontwikkelwerkruimte naar een testwerkruimte). Op dit moment implementeert u inhoud wanneer deze klaar is voor de volgende fase (bijvoorbeeld wanneer nieuwe inhoud gereed is om te worden getest).

In de volgende secties worden benaderingen beschreven die u kunt gebruiken om inhoud te publiceren of te promoten.

Bepalen hoe u inhoud publiceert

Wanneer u inhoud op uw lokale computer ontwikkelt, moet u die inhoud publiceren naar een ontwikkelwerkruimte in de Fabric-portal. Doorgaans publiceert u deze inhoud wanneer u validatie wilt uitvoeren van de wijzigingen die u hebt aangebracht.

Notitie

In dit artikel verwijzen we naar het publiceren van inhoud als de initiële implementatie naar de ontwikkelwerkruimte. In principe is het publiceren van inhoud echter hetzelfde als het implementeren ervan.

Inhoud die is gemaakt in de Fabric-portal (zoals gegevensstromen, dashboards en scorecards) wordt rechtstreeks in de ontwikkelwerkruimte gemaakt en hoeft niet te worden gepubliceerd.

In de volgende secties worden verschillende benaderingen beschreven die u kunt gebruiken om inhoud te publiceren.

Publiceren met Power BI Desktop

Met Power BI Desktop kunnen gebruikers semantische modellen en rapporten publiceren vanaf hun lokale computer naar een werkruimte in de Fabric-portal. Deze aanpak is de eenvoudigste manier om inhoud te publiceren; Het kan echter niet worden geautomatiseerd.

Overweeg deze methode te gebruiken wanneer:

• Makers van inhoud geven er de voorkeur aan om het publiceren van inhoud handmatig te beheren in de Fabric-portal.
• Makers van inhoud gebruiken Power BI Desktop om inhoud te ontwikkelen en te beheren.
• Makers van inhoud zijn niet bekend met Azure DevOps of Git.
• Inhoud bestaat alleen uit semantische modellen of rapporten.

Publiceren met hulpprogramma's van derden

Met hulpprogramma's van derden kunnen makers van inhoud een semantisch model publiceren met behulp van de werkruimte XMLA-eindpunt voor lezen/schrijven. Een maker van inhoud maakt bijvoorbeeld gebruik van Tabular Editor voor het ontwikkelen en beheren van modelmetagegevens, zoals TMDL (Tabular Model Definition Language) of .bim-bestanden.

Tip

Zie het geavanceerde gebruiksscenario voor gegevensmodellenvoor meer informatie over het gebruik van hulpprogramma's van derden voor het implementeren van semantische modellen.

Zie Semantische modelconnectiviteit met het XMLA-eindpuntvoor meer informatie over het inschakelen en gebruiken van XMLA-lees-/schrijfeindpunten.

Overweeg deze methode te gebruiken wanneer:

• Makers van inhoud geven er de voorkeur aan om het publiceren van inhoud handmatig te beheren in de Fabric-portal.
• Makers van inhoud gebruiken een hulpprogramma van derden om de inhoud te ontwikkelen en te beheren.
• Inhoud wordt gepubliceerd naar een werkruimte die gebruikmaakt van Premium per gebruiker (PPU), Premium-capaciteit of fabriccapaciteitslicentiemodus.
• Makers van inhoud zijn niet bekend met Azure DevOps of Git.
• Inhoud bestaat alleen uit semantische modellen.

Publiceren met OneDrive-vernieuwing

Met OneDrive kunnen zelfbedieningsinhoudmakers automatisch semantische modellen of rapporten publiceren naar een werkruimte in de Fabric-portal met behulp van OneDrive-refresh. Makers van inhoud kunnen Power BI Desktop-bestanden (.pbix) opslaan in een gedeelde bibliotheek in OneDrive. De gedeelde bibliotheek kan ook een SharePoint- of Microsoft Teams-documentbibliotheek zijn.

Tip

Zie voor meer informatie over het gebruik van OneDrive voor Werk en School met Power BI-inhoud het scenario voor het publiceren van selfservice-inhoud.

Zie Een semantisch model vernieuwen dat is opgeslagen in OneDrive of SharePoint Onlinevoor meer informatie over het instellen van OneDrive-vernieuwing.

Overweeg deze methode te gebruiken wanneer:

• Makers van inhoud willen het publiceren van inhoud automatiseren naar de Fabric-portal.
• Makers van inhoud zijn niet bekend met Azure DevOps of Git.
• Makers van inhoud voeren versiebeheer van inhoud uit met OneDrive of SharePoint.
• Makers van inhoud slaan semantische modellen en rapporten op als PBIX-bestanden.
• Inhoud bestaat alleen uit semantische modellen of rapporten.

Publiceren met Git-integratie van Fabric

Fabric Git-integratie is een functie die exclusief is voor Fabric-capaciteiten waarmee makers van inhoud een vertakking van een externe Git-opslagplaats kunnen synchroniseren naar een Fabric-werkruimte. U kunt Git-integratie samen met Azure DevOps gebruiken om inhoud van Azure-opslagplaatsen te synchroniseren of u kunt inhoud implementeren met behulp van Azure Pipelines (beschreven in de volgende sectie).

Notitie

Azure DevOps- is een suite met services die zijn geïntegreerd met Power BI en Fabric om u te helpen bij het plannen en organiseren van levenscyclusbeheer van inhoud. Wanneer u Azure DevOps op deze manier gebruikt, maakt u doorgaans gebruik van de volgende services:

• Azure-opslagplaatsen: hiermee kunt u een externe Git-opslagplaats maken en gebruiken. Dit is een externe opslaglocatie die u gebruikt om wijzigingen in inhoud bij te houden en te beheren.
• Azure Pipelines: hiermee kunt u een set geautomatiseerde taken maken en gebruiken om inhoud van een externe opslagplaats naar een werkruimte te verwerken, te testen en te implementeren.
• Azure-testplannen: hiermee kunt u tests ontwerpen om de oplossing te valideren en kwaliteitscontrole samen met Azure Pipelines te automatiseren.
• Azure Boards: hiermee kunt u borden gebruiken om taken en plannen als werkitems bij te houden en werkitems van andere Azure DevOps-services te koppelen of te raadplegen.
• Azure Wiki-: hiermee kunt u informatie delen met hun team om inhoud te begrijpen en bij te dragen.

Samenvattend wordt de inhoud die is doorgevoerd en naar de externe opslagplaats gepusht, automatisch naar de werkruimte gepubliceerd via dit synchronisatieproces. Een belangrijk voordeel van deze aanpak is dat u hiermee uw broncodebeheer kunt koppelen processen met inhoudspublicatie. Het maakt het bijvoorbeeld eenvoudiger om wijzigingen of volledige versies van een oplossing terug te draaien.

Tip

Zie het scenario voor het publiceren van bedrijfsinhoudvoor meer informatie over het gebruik van Fabric Git-integratie voor het implementeren van Power BI-inhoud.

Zie zelfstudie: Levenscyclusbeheer in Fabric en Power BI Desktop-projecten: Git-integratievoor meer informatie over het instellen van Git-integratie.

Overweeg deze methode te gebruiken wanneer:

• Makers van inhoud zijn bekend met Azure DevOps en Git.
• Makers van inhoud gebruiken Azure DevOps voor samenwerking en broncodebeheer.
• Makers van inhoud slaan semantische modellen en rapporten op als Power BI-project (.pbip) bestanden.
• Inhoud wordt gepubliceerd naar een werkruimte op een Fabric capaciteit.
• Inhoud bestaat uit ondersteunde itemtypen door de Git-integratiefunctie.
• Inhoud heeft geen gevoeligheidslabels.

Notitie

Hoe u Git-integratie gebruikt voor het implementeren en beheren van inhoud, is sterk afhankelijk van uw vertakkings- en samenvoegstrategieën, die u in fase twee van levenscyclusbeheer bepaalt.

Publiceren met Azure Pipelines

Azure Pipelines programmatisch testen, beheren en implementeren van inhoud automatiseren. Wanneer een pijplijn wordt uitgevoerd, worden de stappen in de pijplijn automatisch uitgevoerd. Azure Pipelines is complexer en vereist meer tijd en moeite om in te stellen in vergelijking met andere benaderingen, maar biedt de meeste controle en flexibiliteit om het implementatieproces te organiseren.

Tip

U kunt inhoud implementeren met behulp van Azure Pipelines en Power BI REST API's voor werkruimten die zich niet in fabric- of Premium-capaciteit bevinden. De REST API's van Fabric werken echter alleen met Fabric en de XMLA-eindpunten werken alleen met Fabric- of Premium-capaciteit.

Zie het scenario voor het publiceren van bedrijfsinhoudvoor meer informatie over het gebruik van Azure Pipelines voor het implementeren van Power BI-inhoud.

Zie Power BI Desktop-projecten voor Azure DevOps-integratie en build-pijplijnenvoor meer informatie over hoe u Azure DevOps kunt integreren met Power BI.

Overweeg om Azure Pipelines te gebruiken om inhoudsimplementatie in te delen wanneer:

• Makers van inhoud zijn bekend met Azure DevOps en de REST API's van Fabric.
• Makers van inhoud gebruiken Azure DevOps voor samenwerking en broncodebeheer.
• Makers van inhoud maken geen gebruik van Fabric Git-integratie.

Azure Pipelines en andere hulpprogramma's op basis van code kunnen inhoud programmatisch implementeren met behulp van een of meer van de volgende API's of eindpunten:

• Power BI REST API's: er zijn verschillende Power BI REST API-eindpunten die u kunt gebruiken om inhoud te implementeren. De Power BI REST API's ondersteunen alleen Power BI-itemtypen.
  • importeren: u kunt ondersteunde items publiceren met behulp van de Power BI REST API's om een geldig bronbestand te importeren in een werkruimte (zoals een PBIX-bestand).
  • Implementeren: u kunt ondersteunde items implementeren, waardoor ze van de ene werkruimte naar de andere worden gepromoot als ze fasen in een implementatiepijplijn zijn.
• Fabric REST API's: er zijn verschillende Fabric REST API-eindpunten die u kunt gebruiken om inhoud te implementeren. De REST API's van Fabric ondersteunen zowel Power BI- als Fabric-itemtypen.
  • maken: u kunt ondersteunde items maken met behulp van de Fabric REST API's, samen met een geldige itemdefinitie.
  • Bijwerken vanuit Git: u kunt een werkruimte bijwerken met inhoud uit een externe opslagplaats die is verbonden met behulp van Git-integratie.
• XMLA-eindpunten voor lezen/schrijven: u kunt maken of semantische modellen wijzigen met behulp van XMLA-eindpunten in combinatie met een geldig model.bim-bestand. Met XMLA-eindpunten kunt u wijzigingen implementeren in specifieke modelobjecten in plaats van het hele model. Azure Pipelines kan gebruikmaken van hulpprogramma's van derden (zoals de opdrachtregelinterface van de Tabular Editor) om semantische modellen te implementeren met behulp van de XMLA-eindpunten.

Fooi

Wanneer u de Fabric- of Power BI REST API's gebruikt, moet u eerst een app-registratie maken in Azure (hier beschreven voor Power BI Embedded). Hiervoor zijn een Microsoft Entra ID-tenant en een organisatiegebruiker vereist. Dit kan een complex proces zijn om de juiste machtigingen in te stellen. U kunt de Fabric REST API's echter uitvoeren in notebooks zonder dat u een app-registratie hoeft te maken. Dit stroomlijnt de installatie en het gebruik van API's in uw oplossingen, zodat u geen referenties hoeft te beheren of een installatie hoeft te configureren voordat u de API's gebruikt.

Als u de Fabric REST API's wilt gebruiken zonder een app te registreren, gebruikt u semantische koppeling in een Fabric-notebook met de FabricRestClientClass- van sempy- om de API aan te roepen.

Samen met geautomatiseerde tests helpt de integratie van Azure Pipelines met Power BI u bij het bereiken van continue integratie en continue implementatie (CI/CD).

Wanneer u Azure Pipelines gebruikt, kunnen eigenaren van pijplijnen triggers, stappen en functionaliteit aanpassen om te voldoen aan de implementatiebehoeften. Als zodanig variëren het aantal en de typen pijplijnen, afhankelijk van de oplossingsvereisten.

Er zijn drie typen Azure Pipelines die u kunt instellen voor het testen, beheren en implementeren van uw Power BI-oplossing.

• Validatiepijplijnen
• Pijplijnen bouwen
• Release-pijplijnen

Notitie

Het is niet nodig om alle drie de typen pijplijn in uw publicatieoplossing te hebben. Afhankelijk van uw werkstroom en behoeften kunt u een of meer van de varianten van de pijplijnen instellen die in dit artikel worden beschreven om de publicatie van inhoud te automatiseren. Deze mogelijkheid om de pijplijnen aan te passen is een voordeel van Azure Pipelines ten opzichte van de ingebouwde Fabric-implementatiepijplijnen.

Validatiepijplijnen

Validatiepijplijnen voeren basiskwaliteitscontroles van gegevensmodellen uit voordat ze worden gepubliceerd naar een ontwikkelwerkruimte. Normaal gesproken triggeren wijzigingen in een tak van de remote repository de pijplijn om deze veranderingen te valideren met geautomatiseerde tests.

Voorbeelden van geautomatiseerde tests zijn het scannen van het gegevensmodel op schendingen van best practice-regels met behulp van Best Practice Analyzer (BPA)of door DAX-query's uit te voeren op een gepubliceerd semantisch model. De resultaten van deze tests worden vervolgens opgeslagen in de externe opslagplaats voor documentatie- en controledoeleinden. Gegevensmodellen die niet kunnen worden gevalideerd, mogen niet worden gepubliceerd. In plaats daarvan moet de pijplijn inhoudsmakers op de hoogte stellen van de problemen.

Pijplijnen bouwen

Pijplijnen bouwen gegevensmodellen voorbereiden voor publicatie in de Power BI-service. Deze pijplijnen combineren geserialiseerde modelmetagegevens in één bestand dat later wordt gepubliceerd door een release-pijplijn. Een build-pijplijn kan ook wijzigingen aanbrengen in de metagegevens, zoals het wijzigen van parameterwaarden. De build-pijplijnen produceren implementatieartefacten die bestaan uit metagegevens van gegevensmodellen (voor gegevensmodellen) en Power BI-projectbestanden (.pbip) die klaar zijn voor publicatie naar de Power BI-service.

Release-pijplijnen

Release-pijplijnen publiceren of implementeren inhoud. Een publicatieoplossing bevat doorgaans verschillende releasepijplijnen, afhankelijk van de doelomgeving.

• Development Release-pijplijn: deze eerste pijplijn wordt automatisch geactiveerd. Inhoud wordt gepubliceerd in een ontwikkelwerkruimte nadat de build- en validatiepijplijnen met succes zijn afgerond.
• pijplijnen voor test- en productiereleases: deze pijplijnen worden niet automatisch geactiveerd. In plaats daarvan worden ze op aanvraag geactiveerd of wanneer ze zijn goedgekeurd. Test- en productiereleasepijplijnen implementeren respectievelijk inhoud in een test- of productiewerkruimte na releasegoedkeuring. Releasegoedkeuringen zorgen ervoor dat inhoud niet automatisch wordt geïmplementeerd in een test- of productiefase voordat deze gereed is. Deze goedkeuringen worden aangeboden door releasebeheerders die verantwoordelijk zijn voor het plannen en coördineren van inhoudsrelease voor test- en productieomgevingen.

Bepalen hoe u inhoud tussen werkruimten promoveert

Wanneer u verschillende omgevingen gebruikt voor ontwikkeling, testen en productie, moet u inhoud implementeren in alle drie de omgevingen. Er zijn verschillende hulpprogramma's en benaderingen die u kunt gebruiken om inhoud tussen werkruimten te promoten, afhankelijk van uw specifieke werkstroom en behoeften.

In de volgende secties worden benaderingen beschreven die u kunt gebruiken om inhoud tussen werkruimten te promoten.

Voorzichtigheid

Vermijd het handmatig publiceren van inhoud vanaf uw lokale computer om werkruimten te testen en te produceren. Dit kan leiden tot fouten of onderbrekingen vanwege fouten. Over het algemeen moet u alleen publiceren naar een ontwikkelwerkruimte of naar een privéwerkruimte als u er een gebruikt.

Implementeren met Fabric-implementatiepijplijnen

Met implementatiepijplijnen kunt u twee of meer fasen (zoals ontwikkeling, test of productie) instellen en fabric-inhoud tussen deze fasen implementeren. Een pijplijnbeheerder wijst één Power BI-werkruimte toe aan elke fase in de implementatiepijplijn. Hoe u implementatiepijplijnen gebruikt, is afhankelijk van hoe u hebt besloten om werkruimten in te stellen en te gebruiken.

Overweeg het gebruik van implementatiepijplijnen wanneer:

• Inhoud wordt gedeployd naar werkruimten met PPU-, Premium-capaciteit of Fabric-capaciteitslicentiemodus.
• Typen en scenario's voor inhoudsitems worden ondersteund door implementatiepijplijnen.

Overweeg een andere benadering dan implementatiepijplijnen wanneer:

• U wilt liever inhoud implementeren vanuit een externe opslagplaats, zoals met behulp van Azure Pipelines.
• U bent van plan git-integratie te gebruiken om verschillende fasen te synchroniseren met verschillende vertakkingen van uw externe opslagplaats in plaats van de inhoud te implementeren.

Tip

Zie de gebruiksscenario's van zelfbedieningsinhoud publiceren en bedrijfsinhoud publiceren voor meer informatie over hoe u opleveringspijplijnen gebruikt om inhoud tussen werkruimten te promoten.

Zie Implementatiepijplijnen voor meer informatie over implementatiepijplijnen: Inzicht in het implementatieproces.

De eenvoudigste manier om een implementatiepijplijn te gebruiken, is wanneer u alle inhoud naar één werkruimte publiceert en deze naar latere fasen binnen één implementatiepijplijn promoveert. In het volgende diagram ziet u deze eerste benadering voor het implementeren van inhoud met behulp van een implementatiepijplijn.

Kortom, een contentmaker plaatst doorgaans eerst inhoud in de eerste fase van de pijplijn. Vervolgens activeert een pijplijnbeheerder een implementatie om inhoud naar de latere fasen te promoveren. Wanneer een implementatie plaatsvindt, implementeert de implementatiepijplijn metagegevens van inhoud van de ene werkruimte naar de volgende.

Wanneer u inhoud op itemtype in verschillende werkruimten scheidt, gebruikt u afzonderlijke implementatiepijplijnen om deze inhoud te implementeren. U kunt inhoud koppelen tussen werkruimten met meerdere implementatiepijplijnen door gebruik te maken van auto-binding. Automatische binding tussen implementatiepijplijnen zorgt ervoor dat inhoud gekoppeld blijft aan het juiste item in de respectieve fase. Het rapport in de ontwikkelingsfase blijft bijvoorbeeld gekoppeld aan het model in de ontwikkelingsfase van de andere implementatiepijplijn. U kunt echter ook autokoppelingsgedrag vermijden als uw scenario vereist dat inhoud tussen werkruimten wordt gekoppeld volgens een ander patroon.

In het volgende diagram ziet u deze tweede benadering voor het implementeren van inhoud met behulp van meerdere implementatiepijplijnen.

Kortom, het implementeren van inhoud met behulp van meerdere implementatiepijplijnen is vergelijkbaar met het gebruik van één pijplijn. Een belangrijk verschil is dat u inhoud die is verbonden tussen werkruimten en implementatiepijplijnen optioneel kunt koppelen met behulp van automatische binding. Anders is het identiek aan de eerste benadering.

Implementatiepijplijnen zijn een flexibel, eenvoudig hulpprogramma dat geschikt is voor het verbeteren van het levenscyclusbeheer van inhoud voor zowel selfservice- als bedrijfsscenario's.

Toegang tot zowel de werkruimte als de implementatiepijplijn is vereist voor de gebruikers die een implementatie uitvoeren. U wordt aangeraden implementatiepijplijntoegang te plannen, zodat pijplijnbeheerders de implementatiegeschiedenis kunnen bekijken en inhoud kunnen vergelijken. Wanneer u samenwerkt met meerdere makers van inhoud, kunt u overwegen om pijplijntoegang te beperken tot releasemanagers of technische eigenaren die het meest geschikt zijn om toezicht te houden op de implementatie- en releaseprocessen.

U kunt ook implementatieregels gebruiken om verschillende configuraties in te stellen voor items in verschillende fasen. U wilt bijvoorbeeld een semantisch model in de ontwikkelomgeving om gegevens te halen uit de ontwikkelingsdatabase, terwijl het semantische model in de productieomgeving gegevens haalt uit de productiedatabase.

Tip

Als meerdere personen toegang hebben tot uw implementatiepijplijn, raden we u aan de implementatiegeschiedenis regelmatig te bekijken. Deze beoordelingen kunnen u helpen bij het identificeren van niet-goedgekeurde implementaties of implementatiefouten.

Als u autokoppeling gebruikt om items in implementatiepijplijnen te verbinden, moet u ook de herkomst van de items controleren om onderbrekingen in de autokoppeling te identificeren die worden veroorzaakt doordat iemand gekoppelde inhoud naar de verkeerde fase publiceert.

U kunt implementaties handmatig of programmatisch activeren met behulp van de Power BI REST API's. In beide gevallen moet u een duidelijk en robuust proces definiëren over wanneer u inhoud naar elke fase promovt en hoe u onbedoelde wijzigingen kunt terugdraaien.

Implementatie handmatig uitvoeren

U kunt inhoud handmatig implementeren met behulp van de Fabric-deploypijplijn. U kunt kiezen alle inhoud implementeren of itemsselecteren. Selectieve implementatie kan nuttig zijn wanneer bepaalde inhoud klaar is om naar de volgende fase te gaan, maar sommige items worden nog steeds ontwikkeld of gevalideerd. Daarnaast kunt u een achterwaartse implementatie uitvoeren wanneer inhoudswijzigingen in een latere fase bestaan, maar niet in een eerdere fase.

Voorzichtigheid

Wanneer u implementatiepijplijnen gebruikt, raden we u aan om inhoud in één richting te implementeren, zoals van ontwikkeling tot testen naar productiewerkruimten. Normaal gesproken moet u voorkomen dat u in latere fasen wijzigingen aan inhoud aanbrengt voordat deze wijzigingen de juiste validatie in ontwikkeling of test hebben ondergaan.

Wanneer u een handmatige implementatie uitvoert, kunt u fasen vergelijken om inhoudswijzigingen te identificeren in het wijzigingsbeoordelingsvenster. Deze aanpak is vooral handig wanneer u geen externe Git-opslagplaats gebruikt voor broncodebeheer.

De Power BI REST API's gebruiken om de implementatie uit te voeren

U kunt de Power BI REST API's gebruiken om inhoud te implementeren met behulp van een implementatiepijplijn. Een voordeel van het gebruik van de REST API's is dat u de implementatie kunt automatiseren en integreren met andere hulpprogramma's, zoals Azure Pipelines in Azure DevOps.

Implementeren met Azure Pipelines

Met Azure Pipelines kunt u de implementatie tussen alle fasen organiseren. Met deze aanpak gebruikt u de Rest API's van Fabric om inhoud te implementeren en te beheren, waarbij u gebruikmaakt van verschillende Azure Pipelines, zoals validatie- en releasepijplijnen.

Overweeg het gebruik van Azure Pipelines wanneer:

• U wilt de indeling van de implementatie centraliseren vanuit Azure DevOps.
• Makers van inhoud gebruiken Azure DevOps om samen te werken en voor broncodebeheer.

Overweeg een andere benadering dan Azure Pipelines wanneer:

• Makers van inhoud zijn niet bekend met Azure DevOps of op code gebaseerde implementaties.
• Inhoud bevat itemtypen die geen ondersteunde definitie of bronbestandsindeling hebben, zoals dashboards.

Er zijn twee verschillende benaderingen voor het implementeren van inhoud met Azure Pipelines. Ze organiseren implementatiepijplijnen of ze implementeren inhoud in een werkruimte zonder een implementatiepijplijn.

Infrastructuurimplementatiepijplijnen organiseren met behulp van Azure Pipelines

In deze benadering coördineren releasepijplijnen de invoering van inhoud naar test- en productieomgevingen door gebruik te maken van implementatiepijplijnen. Inhoud wordt gepromoveerd via ontwikkel-, test- en productiewerkruimten in Fabric.

In het volgende diagram ziet u hoe u implementatiepijplijnen van Azure Pipelines indeelt.

Samengevat publiceren contentmakers inhoud in de werkruimte in de eerste fase van het uitrolproces. Vervolgens keurt een releasebeheerder de implementatie goed, waardoor een Azure Pipeline wordt geactiveerd. Deze pijplijn maakt gebruik van de Power BI REST API's om inhoud tussen fasen te promoten, zodat de metagegevens worden geïmplementeerd in een andere werkruimte. Een voordeel van deze aanpak is dat u de implementatie van meerdere Fabric-itemtypen kunt organiseren via implementatiepijplijnen, omdat sommige itemtypen zijn ontwikkeld in de Fabric-portal en dus niet alleen door Azure Pipelines kunnen worden geïmplementeerd.

Inhoud implementeren met behulp van alleen Azure Pipelines

U kunt ook inhoud implementeren in een werkruimte vanuit Azure DevOps met behulp van Azure Pipelines. Deze benadering maakt geen gebruik van implementatiepijplijnen. In plaats daarvan worden releasepijplijnen gebruikt om bronbestanden of metagegevensbestanden te implementeren met behulp van de Fabric- of Power BI REST API's of XMLA-eindpunten voor lezen/schrijven. Deze bestanden worden doorgaans opgeslagen in een Azure Repos Git-opslagplaats.

In het volgende diagram ziet u hoe u inhoud implementeert met behulp van alleen Azure Pipelines.

Kortom, inhoudmakers committen en pushen inhoudswijzigingen naar een externe Git-opslagplaats in Azure Repos. Deze inhoud wordt gebruikt door Azure Pipelines voor de implementatie. Zodra de releasebeheerder de specifieke implementatie goedkeurt, implementeert De Azure Pipeline inhoud naar de werkruimte, hetzij met behulp van de Power BI REST API's (dat wil gezegd, voor PBIX-bestanden), de REST API's van Fabric (dat wil gezegd, voor itemdefinities) of XMLA-eindpunten (dat wil wel voor model.bim-bestanden). Er bestaat een afzonderlijke Azure-pijplijn voor elke werkruimte.

Voor deze benadering is geen Fabric-capaciteit of Premium-licentie vereist wanneer u alleen Power BI Desktop-bestanden met de Power BI REST API's publiceert. Het omvat echter meer installatie-inspanningen en complexiteit, omdat u de implementatie buiten Power BI moet beheren. Ontwikkelteams die devOps al gebruiken voor gegevensoplossingen buiten Power BI, zijn mogelijk bekend met deze aanpak. Ontwikkelteams die deze aanpak gebruiken, kunnen de implementatie van gegevensoplossingen in Azure DevOps consolideren.

Implementeren met Fabric Git-integratie

Wanneer u Git-integratie gebruikt, kunt u verschillende vertakkingen synchroniseren met verschillende werkruimten in plaats van inhoud expliciet te publiceren of implementeren. Op die manier kunt u afzonderlijke branches hebben voor ontwikkel-, test- en productiewerkruimten. In dit scenario wordt de hoofdbranch gesynchroniseerd met de productiewerkruimte. Vervolgens implementeert u inhoud tussen werkruimten door een pull-aanvraag uit te voeren om de ontwikkelingsbranch samen te voegen in de testbranch (te implementeren in de testwerkruimte) of om de testbranch samen te voegen in de hoofdbranch (om te implementeren in de productiewerkruimte).

In het volgende diagram ziet u hoe u inhoud implementeert met behulp van Fabric Git-integratie om vertakkingen naar verschillende werkruimten te synchroniseren. Ter vereenvoudiging bevat het diagram geen details van vertakking of het samenvoegen van inhoud.

Kortom, contentmakers voeren wijzigingen door en pushen inhoudswijzigingen naar een externe Git-opslagplaats in Azure Repos. Inhoudmakers openen pull-aanvragen (PR's) om hun wijzigingen te integreren in een specifieke branche. Afhankelijk van de vertakkingsstrategie zijn verschillende vertakkingen verbonden met verschillende werkruimten. Zodra wijzigingen zijn samengevoegd in een vertakking, synchroniseren makers van inhoud de werkruimte met de externe Git-opslagplaats om de meest recente wijzigingen in de inhoud in die werkruimte weer te geven.

Houd rekening met deze aanpak wanneer:

• U wilt de implementatie tussen werkruimten organiseren met behulp van uw vertakkings- en samenvoegstrategie.
• U bent niet van plan om Azure Pipelines of Fabric-implementatiepijplijnen te gebruiken om implementaties te organiseren om te testen en te produceren.
• De werkruimte bevat geen niet-ondersteunde items of scenario's.
• Inhoud heeft geen gevoeligheidslabels.

Notitie

Er zijn veel geldige manieren om inhoud te implementeren. U kunt bijvoorbeeld een combinatie van de verschillende benaderingen gebruiken die in dit artikel worden besproken.

U kunt bijvoorbeeld inhoud implementeren in een ontwikkelwerkruimte met behulp van een Azure Pipeline, waarmee u kunt profiteren van functies voor continue integratie en geautomatiseerde tests kunt uitvoeren (zoals het gebruik van Best Practice Analyzer). Vervolgens kunt u inhoud tussen werkruimten implementeren met behulp van Git-integratie of een Infrastructuurimplementatiepijplijn.

Kies de methode die het beste past bij uw behoeften en de manier waarop uw team werkt.

Bepalen hoe u activiteiten na de implementatie kunt afhandelen

Na de implementatie zijn er verschillende activiteiten na de implementatie die moeten worden verwerkt. Veel van deze activiteiten kunnen programmatisch worden verwerkt, bijvoorbeeld door een Azure Pipeline of notebook en de REST API's van Power BI en Fabric. U kunt bijvoorbeeld programmatisch gegevensbronreferenties instellen, geplande vernieuwing beheren en vernieuwingen activeren na een metagegevensimplementatie. Voor sommige taken is echter handmatige tussenkomst vereist, zoals een eerste installatie of het bijwerken van een Power BI-app.

Zorg ervoor dat u alle relevante activiteiten na de implementatie voor uw inhoud identificeert en dat u besluit hoe deze worden verwerkt.

Zodra u hebt gepland hoe u inhoud gaat implementeren, moet u overwegen hoe u ondersteuning en deze bewaakt.

Checklist - Bij het plannen van het implementeren van inhoud zijn belangrijke beslissingen en acties onder andere:

• De implementatieopties identificeren die voor u beschikbaar zijn: afhankelijk van uw licentie en inhoud, zijn er verschillende opties beschikbaar om inhoud te publiceren of te promoveren tussen werkruimten. Bepaal of u implementatiepijplijnen, Azure DevOps, Git-integratie, de Fabric REST API's en XMLA-eindpunten voor lezen/schrijven kunt gebruiken.
• bepalen hoe u inhoud publiceert: kies een methode om inhoud te publiceren die het beste past bij uw werkstroom en behoeften. Zorg ervoor dat deze aanpak overeenkomt met uw andere strategieën, zoals hoe u wijzigingen bijhoudt en beheert.
• Bepalen hoe u inhoud tussen werkruimtenpromoveert: kies een benadering voor het implementeren van inhoud van ontwikkeling tot het testen van werkruimten en van testwerkruimten tot productiewerkruimten. Zorg ervoor dat deze aanpak overeenkomt met uw andere strategieën, zoals hoe u inhoud publiceert.
• uw releasestrategie plannen: bepaal of een specifieke persoon verantwoordelijk is voor de definitieve beoordeling van de inhoud voordat een release of implementatie wordt goedgekeurd. Zorg ervoor dat deze persoon op de hoogte is van deze taak en wat ze moeten doen om het implementatieproces te beveiligen zonder de voortgang te blokkeren.
• Activiteiten na de implementatie plannen: Zorg ervoor dat u hebt besloten om activiteiten uit te voeren, zoals het bijwerken van een Power BI-app of het vernieuwen van gegevensitems na een metagegevensimplementatie. Overweeg dit proces te automatiseren met behulp van de Fabric REST API's.
• Voor het eerst instellen van implementatiehulpprogramma's en -processen uitvoeren: Zorg ervoor dat u de juiste toegang instelt en dat machtigingen zijn afgestemd op de manier waarop u toegang tot uw inhoud instelt.
• Inhoud implementeren in productie: Wanneer u uw implementatie hebt gepland en ingesteld, implementeert u inhoud in productie.

Verwante inhoud

In het volgende artikel in deze reeksleert u hoe u inhoud kunt ondersteunen en bewaken als onderdeel van het beheren van de levenscyclus van inhoud.