Power BI-gebruiksscenario's: Publicatie van bedrijfsinhoud

Notitie

Dit artikel maakt deel uit van de reeks artikelen over de implementatieplanning van Power BI. Deze reeks richt zich voornamelijk op de Power BI-workload in Microsoft Fabric. Zie de planning van de Power BI-implementatie voor een inleiding tot de reeks.

Wanneer makers van inhoud samenwerken om analytische oplossingen te leveren die belangrijk zijn voor de organisatie, moeten ze zorgen voor tijdige en betrouwbare levering van inhoud aan consumenten. Technische teams pakken deze uitdaging aan met behulp van een proces met de naam DevOps. Met DevOps kunnen teams processen automatiseren en schalen door procedures te gebruiken die de levering verbeteren en versnellen.

Notitie

Gegevensteams die dezelfde uitdagingen aanpakken, kunnen ook DataOps oefenen. DataOps bouwt voort op DevOps-principes, maar DataOps bevat aanvullende procedures die specifiek zijn voor gegevensbeheer, zoals kwaliteitscontrole en governance van gegevens. We verwijzen in dit artikel naar DevOps, maar houd er rekening mee dat de onderliggende principes ook van toepassing kunnen zijn op DataOps.

Makers en consumenten van inhoud profiteren van verschillende voordelen bij het gebruik van DevOps-procedures voor het publiceren van Power BI-inhoud. De volgende punten zijn een algemeen overzicht van hoe dit proces werkt.

1. Inhoud ontwikkelen en werk doorvoeren in een externe opslagplaats: makers van inhoud ontwikkelen hun oplossing op hun eigen computer. Ze zetten hun werk regelmatig vast in een externe opslagplaats en slaan ze op regelmatige tijdstippen in de ontwikkeling op. Een externe opslagplaats bevat de nieuwste versie van de oplossing en is toegankelijk voor het hele ontwikkelteam.
2. Werk samen en beheer inhoudswijzigingen met behulp van versiebeheer: andere makers van inhoud kunnen wijzigingen aanbrengen in de oplossing door een vertakking te maken. Een vertakking is een kopie van een externe opslagplaats. Wanneer deze revisies gereed en goedgekeurd zijn, wordt de vertakking samengevoegd met de nieuwste versie van de oplossing. Alle revisies in de oplossing worden bijgehouden. Dit proces wordt versiebeheer (of broncodebeheer) genoemd.
3. Inhoud implementeren en promoveren met behulp van pijplijnen: In het selfservicescenario voor het publiceren van inhoud wordt inhoud gepromoveerd (of geïmplementeerd) via ontwikkelings-, test- en productiewerkruimten met behulp van Power BI-implementatiepijplijnen. Power BI-implementatiepijplijnen kunnen inhoud naar Power BI Premium-werkruimten handmatig promoveren met behulp van de gebruikersinterface of programmatisch met behulp van de REST API's. Het publiceren van bedrijfsinhoud (de focus van dit gebruiksscenario) bevordert daarentegen inhoud met behulp van Azure Pipelines. Azure Pipelines is een Azure DevOps-service die het testen, beheren en implementeren van inhoud automatiseert met behulp van een reeks aangepaste, programmatische stappen. In het scenario voor publicatie van bedrijfsinhoud kunnen deze pijplijnen ook wel continue integratie- en implementatiepijplijnen (of CI/CD)-pijplijnen worden genoemd. Deze pijplijnen integreren regelmatig en automatisch wijzigingen en stroomlijnen het publiceren van inhoud.

Belangrijk

Soms verwijst dit artikel naar Power BI Premium of de capaciteitsabonnementen (P-SKU's). Houd er rekening mee dat Microsoft momenteel aankoopopties consolideert en de Power BI Premium-SKU's per capaciteit buiten gebruik stelt. Nieuwe en bestaande klanten moeten overwegen om in plaats daarvan F-SKU's (Fabric-capaciteitsabonnementen) aan te schaffen.

Zie Belangrijke update voor Power BI Premium-licenties en veelgestelde vragen over Power BI Premium voor meer informatie.

DevOps biedt ondersteuning voor een volwassen, systematische benadering van inhoudsbeheer en publicatie. Het stelt makers van inhoud in staat om samen te werken aan oplossingen en zorgt voor een snelle en betrouwbare levering van inhoud aan consumenten. Wanneer u zich houdt aan DevOps-procedures, profiteert u van gestroomlijnde werkstromen, minder fouten en verbeterde ervaringen voor makers van inhoud en gebruikers van inhoud.

U stelt DevOps-procedures voor uw Power BI-oplossing in en beheert deze met behulp van Azure DevOps. In bedrijfsscenario's kunt u de publicatie van inhoud automatiseren met Azure DevOps en de Power BI REST API's op drie verschillende manieren.

• Power BI REST API's met Power BI-implementatiepijplijnen: u kunt inhoud importeren in ontwikkelwerkruimten en implementatiepijplijnen gebruiken om inhoud te implementeren via test- en productiewerkruimten. U beheert nog steeds de implementatie vanuit Azure DevOps en gebruikt de Power BI REST API's om implementatiepijplijnen te beheren in plaats van afzonderlijke inhoudsitems. Daarnaast gebruikt u het XMLA-eindpunt om metagegevens van gegevensmodellen te implementeren in plaats van een Power BI Desktop-bestand (.pbix) met Azure DevOps. Met deze metagegevens kunt u wijzigingen op objectniveau bijhouden met behulp van versiebeheer. Hoewel deze aanpak robuuster en eenvoudiger te onderhouden is, vereist deze aanpak premiumlicenties en gemiddelde scriptinspanningen om inhoudsimport en -implementatie in te stellen met de Power BI REST API's. Gebruik deze benadering als u het levenscyclusbeheer van inhoud wilt vereenvoudigen met implementatiepijplijnen en u een Premium-licentie hebt. Het XMLA-eindpunt en power BI-implementatiepijplijnen zijn Premium-functies.
• Power BI REST API's: u kunt ook inhoud importeren in ontwikkel-, test- en productiewerkruimten met behulp van Azure DevOps en alleen de Power BI REST API's. Voor deze benadering is geen Premium-licentie vereist, maar hiervoor is veel scripting en installatie vereist, omdat de implementatie buiten Power BI wordt beheerd. Gebruik deze methode als u Power BI-inhoud centraal wilt implementeren vanuit Azure DevOps of wanneer u geen Premium-licentie hebt. Zie het stroomdiagram van de releasepijplijnbenaderingen voor een visuele vergelijking tussen de eerste twee benaderingen.
• Power BI-automatiseringshulpprogramma's met Power BI-implementatiepijplijnen: u kunt de Azure DevOps-extensie voor Power BI-automatisering gebruiken om implementatiepijplijnen te beheren in plaats van de Power BI REST API's. Deze benadering is een alternatief voor de eerste optie, die gebruikmaakt van de Power BI REST API's met Power BI-implementatiepijplijnen. De power BI Automation Tools-extensie is een opensource-hulpprogramma. Hiermee kunt u inhoud van Azure DevOps beheren en publiceren zonder Dat u PowerShell-scripts hoeft te schrijven. Gebruik deze methode als u implementatiepijplijnen van Azure DevOps wilt beheren met minimale scriptinspanning en u een Premium-capaciteit hebt.

Dit artikel is gericht op de eerste optie, die gebruikmaakt van de Power BI REST API's met Power BI-implementatiepijplijnen. Hierin wordt beschreven hoe u Azure DevOps kunt gebruiken om DevOps-procedures in te stellen. Ook wordt beschreven hoe u Azure-opslagplaatsen kunt gebruiken voor uw externe opslagplaatsen en het automatiseren van inhoudstests, integratie en levering met Azure Pipelines. Azure DevOps is niet de enige manier om publicatie van bedrijfsinhoud in te stellen, maar eenvoudige integratie met Power BI maakt het een goede keuze.

Notitie

Dit gebruiksscenario is een van de scenario's voor inhoudsbeheer en implementatie . Voor de beknoptheid worden sommige aspecten die worden beschreven in het onderwerp over samenwerking en levering van inhoud niet behandeld in dit artikel. Lees eerst deze artikelen voor volledige dekking.

Tip

Microsoft Fabric biedt andere opties voor het publiceren van bedrijfsinhoud met behulp van Fabric Git-integratie. Met Git-integratie kunt u een Fabric-werkruimte koppelen aan een vertakking in de externe opslagplaats van Azure-opslagplaatsen. Inhoud die in die vertakking is opgeslagen, wordt automatisch gesynchroniseerd met de werkruimte, alsof die inhoud naar de werkruimte is gepubliceerd. Omgekeerd kunnen makers van inhoud wijzigingen vanuit de Infrastructuurwerkruimte doorvoeren en pushen naar de externe opslagplaats.

Git-integratie kan samenwerking en publicatie van inhoud stroomlijnen, maar hiervoor is meer planning vereist voor het gebruik van Fabric-werkruimten en wat uw vertakkingsstrategie is. Zie Aan de slag met Git-integratie of zelfstudie: End-to-end levenscyclusbeheer voor meer informatie over het instellen en gebruiken van Fabric Git-integratie.

Scenariodiagram

In het volgende diagram ziet u een algemeen overzicht van de meest voorkomende gebruikersacties en Power BI-onderdelen die ondersteuning bieden voor het publiceren van bedrijfsinhoud. De focus ligt op het gebruik van Azure DevOps voor het programmatisch beheren en publiceren van inhoud op schaal via ontwikkel-, test- en productiewerkruimten in de Power BI-service.

Tip

We raden u aan het scenariodiagram te downloaden als u het wilt insluiten in uw presentatie, documentatie of blogbericht, of als een poster op een muur wilt afdrukken. Omdat het een SVG-afbeelding (Scalable Vector Graphics) is, kunt u deze omhoog of omlaag schalen zonder verlies van kwaliteit.

In het scenariodiagram ziet u de volgende gebruikersacties, processen en functies.

Artikel	Beschrijving
	Makers van inhoud ontwikkelen gegevensmodellen met behulp van Power BI Desktop of Tabular Editor en ontwikkelen rapporten met behulp van Power BI Desktop. Makers van inhoud slaan hun werk tijdens de ontwikkeling op in een lokale opslagplaats.
	Makers van inhoud kunnen een externe opslagplaats klonen om een lokale kopie van die inhoud op te halen.
	Voor sommige gegevensbronnen is mogelijk een on-premises gegevensgateway of VNet-gateway vereist voor gegevensvernieuwing, zoals gegevensbronnen die zich in een particulier organisatienetwerk bevinden.
	Makers van inhoud voeren hun wijzigingen regelmatig door naar een externe opslagplaats tijdens de ontwikkeling met behulp van een Git-client zoals Visual Studio Code. In het diagram is de externe opslagplaats Azure-opslagplaatsen.
	Andere makers van inhoud gebruiken Azure-opslagplaatsen om wijzigingen bij te houden met versiebeheer. Ze werken samen door wijzigingen door te voeren in afzonderlijke vertakkingen.
	Wijzigingen in inhoud in de externe opslagplaats activeren Azure Pipelines. Een validatiepijplijn is de eerste pijplijn die wordt geactiveerd. De validatiepijplijn voert geautomatiseerde tests uit om inhoud te valideren voordat deze wordt gepubliceerd.
	Inhoud die de validatiepijplijn doorgeeft, activeert een volgende build-pijplijn. De build-pijplijn bereidt inhoud voor op het publiceren naar de Power BI-service. Het proces tot dit punt wordt meestal aangeduid als continue integratie (CI).
	Inhoud wordt gepubliceerd en geïmplementeerd met behulp van releasepijplijnen. De releasepijplijnen maken gebruik van de Power BI REST API's of het XMLA-eindpunt van de werkruimte om inhoud programmatisch te importeren in de Power BI-service. Implementatie met behulp van release-pijplijnen wordt meestal aangeduid als continue implementatie (CD).
	Een releasemanager bepaalt de implementatie om werkruimten te testen en te produceren met behulp van een goedkeuring voor de release van Azure Pipelines. Bij het publiceren van bedrijfsinhoud plant en coördineert een releasemanager de inhoudsrelease voor test- en productieomgevingen. Ze coördineren en communiceren met makers van inhoud, belanghebbenden en gebruikers.
	Een releasepijplijn publiceert inhoud naar de ontwikkelwerkruimte of bevordert inhoud van ontwikkeling tot testwerkruimten, of test naar productiewerkruimten.
	Makers van inhoud die werken in een werkruimte die over de licentiemodus infrastructuurcapaciteit beschikt, kunnen Git-integratie gebruiken. Met Git-integratie kunnen makers van inhoud tijdens de ontwikkeling in een privéwerkruimte werken. De maker van inhoud synchroniseert een externe vertakking (meestal een specifieke functievertakking of een bugvertakking) van Azure-opslagplaatsen naar hun privéwerkruimte. Inhoudswijzigingen worden gesynchroniseerd tussen de externe vertakking in Azure-opslagplaatsen en de werkruimte. In dit scenario hoeven makers van inhoud geen Azure Pipelines te gebruiken om inhoud te publiceren. Makers van inhoud kunnen ook regelmatig wijzigingen doorvoeren en pushen vanuit de werkruimte na publicatie. Wanneer ze klaar zijn, kunnen makers van inhoud een pull-aanvraag (PR) maken om hun wijzigingen samen te voegen in de hoofdbranch.
	Wanneer u Git-integratie gebruikt, wordt de ontwikkelwerkruimte gesynchroniseerd met de hoofdbranch om de nieuwste versies van inhoud op te halen. Deze inhoud omvat alle wijzigingen van pull-aanvragen die een releasemanager beoordeelt, goedkeurt en samenvoegt.
	Werkruimten zijn ingesteld op Fabric-capaciteit, Premium-capaciteit, Premium per gebruiker of Embedded-licentiemodus om het gebruik van Power BI-implementatiepijplijnen en het XMLA-lees-/schrijfeindpunt toe te staan.
	Een beheerder van een implementatiepijplijn stelt de Power BI-implementatiepijplijn in met drie fasen: ontwikkeling, test en productie. Elke fase wordt uitgelijnd op een afzonderlijke werkruimte in de Power BI-service. Implementatie-instellingen en -toegang worden ingesteld voor de implementatiepijplijn.
	De ontwikkelwerkruimte bevat de nieuwste versies van inhoud, inclusief alle goedgekeurde en samengevoegde wijzigingen. Na goedkeuring implementeert een release-pijplijn inhoud van de ontwikkeling naar de testwerkruimte.
	Revisoren in de testwerkruimte voeren tests en kwaliteitscontrole uit op inhoud. Zodra deze is goedgekeurd, implementeert een release-pijplijn inhoud van de test naar de productiewerkruimte. Wanneer u Git-integratie met implementatiepijplijnen gebruikt, wordt de testwerkruimte niet gesynchroniseerd met een vertakking.
	Nadat de implementatiepijplijn is voltooid, voeren makers van inhoud handmatig activiteiten na de implementatie uit. Activiteiten kunnen omvatten het instellen van geplande gegevensvernieuwing of het bijwerken van een Power BI-app voor de productiewerkruimte. Wanneer u Git-integratie met implementatiepijplijnen gebruikt, wordt de productiewerkruimte niet gesynchroniseerd met een vertakking.
	Inhoudsviewers openen de inhoud met behulp van de productiewerkruimte of een Power BI-app.

Tip

U wordt aangeraden ook de selfservice voor het publiceren van inhoud en geavanceerde gebruiksscenario's voor gegevensmodellen te bekijken. Het scenario voor publicatie van bedrijfsinhoud is gebaseerd op concepten die in deze scenario's worden geïntroduceerd.

Belangrijkste punten

Hier volgen enkele belangrijke punten die u moet benadrukken over het scenario voor het publiceren van bedrijfsinhoud.

Versiebeheer

Het bijhouden van wijzigingen tijdens de levenscyclus van inhoud is belangrijk om een stabiele en consistente levering van inhoud aan consumenten te garanderen. In dit gebruiksscenario beheren makers en eigenaren van inhoud wijzigingen in een externe opslagplaats met behulp van versiebeheer. Versiebeheer is de praktijk van het beheren van wijzigingen in bestanden of code in een centrale opslagplaats. Met deze praktijk kunt u beter samenwerken en effectief beheer van versiegeschiedenis. Versiebeheer heeft voordelen voor makers van inhoud, waaronder de mogelijkheid om wijzigingen terug te draaien of samen te voegen.

Makers van inhoud ontwikkelen doorgaans gegevensmodellen in Tabular Editor om beter versiebeheer te ondersteunen. In tegenstelling tot een gegevensmodel dat u in Power BI Desktop ontwikkelt, wordt een gegevensmodel dat is ontwikkeld in tablaire editor , opgeslagen in de indeling voor leesbare metagegevens. Met deze indeling kunt u versiebeheer op objectniveau van het gegevensmodel inschakelen. U moet versiebeheer op objectniveau gebruiken wanneer u samenwerkt met meerdere personen in hetzelfde gegevensmodel. Zie het gebruiksscenario voor geavanceerd gegevensmodelbeheer voor meer informatie. Het is niet mogelijk om wijzigingen te zien die u hebt aangebracht in een Power BI Desktop-bestand (.pbix), zoals de rapportdefinitie of het gegevensmodel. U kunt bijvoorbeeld geen wijzigingen bijhouden in een rapportpagina, zoals de gebruikte visuals, hun posities en veldtoewijzingen of opmaak.

Makers van inhoud slaan metagegevensbestanden en PBIX-bestanden op in een centrale externe opslagplaats, zoals Azure-opslagplaatsen. Deze bestanden worden samengesteld door een technische eigenaar. Hoewel een maker van inhoud een oplossing ontwikkelt, is een technische eigenaar verantwoordelijk voor het beheren van de oplossing en het controleren van de wijzigingen en het samenvoegen ervan in één oplossing. Azure-opslagplaatsen bieden geavanceerde opties voor het bijhouden en beheren van wijzigingen. Deze benadering verschilt van de benadering die wordt beschreven in het scenario voor het publiceren van selfservice-inhoud, waarbij de maker OneDrive-opslag gebruikt met versietracking. Het onderhouden van een goed gecureerde, gedocumenteerde opslagplaats is essentieel omdat het de basis vormt van alle inhoud en samenwerking.

Hier volgen enkele belangrijke overwegingen om u te helpen bij het instellen van een externe opslagplaats voor versiebeheer.

• Bereik: Definieer duidelijk het bereik van de opslagplaats. In het ideale voorbeeld is het bereik van de opslagplaats identiek aan het bereik van de downstreamwerkruimten en apps die u gebruikt om inhoud aan consumenten te leveren.
• Toegang: U moet toegang tot de opslagplaats instellen met behulp van een vergelijkbaar machtigingsmodel, zoals u hebt ingesteld voor uw machtigingen voor de implementatiepijplijn en werkruimterollen. Makers van inhoud hebben toegang nodig tot de opslagplaats.
• Documentatie: Voeg tekstbestanden toe aan de opslagplaats om het doel, eigendom, toegang en gedefinieerde processen te documenteren. In de documentatie kan bijvoorbeeld worden beschreven hoe wijzigingen moeten worden gefaseerd en doorgevoerd.
• Hulpprogramma's: Voor het doorvoeren en pushen van wijzigingen in een externe opslagplaats hebben makers van inhoud een Git-client nodig, zoals Visual Studio of Visual Studio Code. Git is een gedistribueerd versiebeheersysteem waarmee wijzigingen in uw bestanden worden bijgehouden. Zie Wat is Git?voor meer informatie over de basisprincipes van Git.

Notitie

Overweeg om Git Large File Storage (LFS) te gebruiken als u Power BI Desktop-bestanden (.pbix) wilt doorvoeren. Git LFS biedt geavanceerde opties voor het beheren van bestanden waarbij wijzigingen niet zichtbaar zijn (onbruikbare bestanden), zoals een PBIX-bestand. U kunt bijvoorbeeld bestandsvergrendeling gebruiken om gelijktijdige wijzigingen in een Power BI-rapport tijdens de ontwikkeling te voorkomen. Git LFS heeft echter een eigen client en configuratie.

Samenwerking met Azure DevOps

Naarmate een oplossing in omvang en complexiteit toeneemt, kan het nodig zijn dat meerdere makers en eigenaren van inhoud samenwerken. Makers en eigenaren van inhoud communiceren en samenwerken in een centrale, georganiseerde hub met behulp van Azure DevOps.

Als u wilt samenwerken en communiceren in Azure DevOps, gebruikt u ondersteunende services.

• Azure Boards: eigenaren van inhoud gebruiken borden om werkitems bij te houden. Werkitems worden elk toegewezen aan één ontwikkelaar in het team en ze beschrijven problemen, bugs of functies in de oplossing en de bijbehorende belanghebbenden.
• Azure Wiki: makers van inhoud delen informatie met hun team om inzicht te hebben in en bij te dragen aan de oplossing.
• Azure-opslagplaatsen: makers van inhoud volgen wijzigingen in de externe opslagplaats en voegen deze samen in één oplossing.
• Azure Pipelines: pijplijneigenaren stellen programmatische logica in om de oplossing te implementeren, automatisch of on-demand.

Stroomdiagram voor samenwerking

In het volgende diagram ziet u een algemeen overzicht van een voorbeeld van hoe Azure DevOps samenwerking mogelijk maakt in het scenario voor publicatie van bedrijfsinhoud. De focus van dit diagram ligt op het gebruik van Azure DevOps om een gestructureerd en gedocumenteerd publicatieproces voor inhoud te maken.

In het diagram ziet u de volgende gebruikersacties, processen en functies.

Artikel	Beschrijving
	Een maker van inhoud maakt een nieuwe korte vertakking door de hoofdvertakking te klonen, die de nieuwste versie van de inhoud bevat. De nieuwe vertakking wordt vaak de functiebranch genoemd, omdat deze wordt gebruikt om een specifieke functie te ontwikkelen of een specifiek probleem op te lossen.
	De maker van de inhoud doorvoert de wijzigingen in een lokale opslagplaats tijdens de ontwikkeling.
	De maker van de inhoud koppelt de wijzigingen aan werkitems die worden beheerd in Azure Boards. Werkitems beschrijven specifieke ontwikkelingen, verbeteringen of bugfixes binnen het bereik van hun vertakking.
	De maker van de inhoud doorvoert regelmatig de wijzigingen. Wanneer de maker van de inhoud klaar is, publiceert de vertakking naar de externe opslagplaats.
	Als u de wijzigingen wilt testen, implementeert de maker van de inhoud de oplossing in een geïsoleerde werkruimte voor de ontwikkeling (niet weergegeven in dit diagram). De maker van de inhoud kan de functiebranch ook synchroniseren met de werkruimte met behulp van Infrastructuur-Git-integratie.
	Makers van inhoud en eigenaren van inhoud documenteren de oplossing en de bijbehorende processen in een Azure Wiki, die beschikbaar is voor het hele ontwikkelteam.
	Wanneer deze klaar is, opent de maker van de inhoud een pull-aanvraag om de functiebranch samen te voegen in de hoofdbranch.
	Een technische eigenaar is verantwoordelijk voor het controleren van de pull-aanvraag en het samenvoegen van wijzigingen. Wanneer ze de pull-aanvraag goedkeuren, voegen ze de functiebranch samen in de hoofdbranch.
	Een geslaagde samenvoeging activeert de implementatie van de oplossing naar een ontwikkelwerkruimte met behulp van een Azure-pijplijn (niet weergegeven in dit diagram). Wanneer u Infrastructuur git-integratie gebruikt, wordt de hoofdbranch gesynchroniseerd met de ontwikkelwerkruimte.
	De releasebeheerder voert een definitieve beoordeling en goedkeuring van de oplossing uit. Deze releasegoedkeuring voorkomt dat de oplossing wordt gepubliceerd voordat deze gereed is. Bij het publiceren van bedrijfsinhoud plant en coördineert een releasemanager doorgaans de inhoudsrelease om werkruimten te testen en te produceren. Ze coördineren en communiceren met makers van inhoud, belanghebbenden en gebruikers.
	Wanneer de releasebeheerder de release goedkeurt, bereidt Azure Pipelines de oplossing automatisch voor op implementatie. Een Azure Pipeline kan ook een implementatiepijplijn activeren om inhoud tussen werkruimten te promoten.
	Gebruikers testen en valideren inhoud in de testwerkruimte. Wanneer u Git-integratie met Azure Pipelines gebruikt voor implementatie, wordt de testwerkruimte niet gesynchroniseerd met een vertakking.
	Nadat gebruikers wijzigingen accepteren en valideren, voert de releasebeheerder een definitieve beoordeling en goedkeuring van de oplossing uit om te implementeren in de productiewerkruimte.
	Gebruikers bekijken inhoud die is gepubliceerd naar de productiewerkruimte. Wanneer u Git-integratie met Azure Pipelines gebruikt voor implementatie, wordt de productiewerkruimte niet gesynchroniseerd met een vertakking.

Om uit te werken, bereiken makers van inhoud samenwerking met behulp van een vertakkingsstrategie. Een vertakkingsstrategie is hoe makers van inhoud vertakkingen maken, gebruiken en samenvoegen om inhoudswijzigingen effectief aan te brengen en te beheren. Afzonderlijke makers van inhoud werken geïsoleerd in hun lokale opslagplaats. Wanneer ze klaar zijn, combineren ze hun wijzigingen als één oplossing in de externe opslagplaats. Makers van inhoud moeten hun werk aan vertakkingen aanpassen door ze te koppelen aan werkitems voor specifieke ontwikkelingen, verbeteringen of oplossingen voor fouten. Elke maker van inhoud maakt een eigen vertakking van de externe opslagplaats voor het werkbereik. Er wordt gewerkt aan de lokale oplossing en gepusht naar een versie van de vertakking in de externe opslagplaats met een doorvoerbericht. In een doorvoerbericht worden de wijzigingen beschreven die in die doorvoering zijn aangebracht.

Als u de wijzigingen wilt samenvoegen, opent een maker van inhoud een pull-aanvraag. Een pull-aanvraag is een inzending voor peerbeoordeling die kan leiden tot de samenvoeging van het werk dat in één oplossing is uitgevoerd. Samenvoegen kan leiden tot conflicten, die moeten worden opgelost voordat de vertakking kan worden samengevoegd. Beoordelingen van pull-aanvragen zijn belangrijk om ervoor te zorgen dat makers voldoen aan de organisatiestandaarden en -procedures voor ontwikkeling, kwaliteit en naleving.

Aanbevelingen voor samenwerking

U wordt aangeraden een gestructureerd proces te definiëren voor de wijze waarop makers van inhoud moeten samenwerken. Zorg ervoor dat u het volgende bepaalt:

• Hoe werk wordt bepaald en hoe vertakkingen worden gemaakt, benoemd en gebruikt.
• Hoe auteurs groepswijzigingen wijzigen en beschrijven met doorvoerberichten.
• Wie is verantwoordelijk voor het controleren en goedkeuren van pull-aanvragen.
• Hoe samenvoegingsconflicten worden opgelost.
• Hoe wijzigingen in verschillende vertakkingen worden samengevoegd tot één vertakking.
• Hoe inhoud wordt getest en wie tests uitvoert voordat inhoud wordt geïmplementeerd.
• Hoe en wanneer wijzigingen worden geïmplementeerd in ontwikkel-, test- en productiewerkruimten.
• Hoe en wanneer geïmplementeerde wijzigingen of versies van de oplossing moeten worden teruggedraaid.

Belangrijk

De waarde van DevOps is rechtstreeks evenredig met de naleving van de processen die het gebruik ervan definiëren.

Een succesvolle samenwerking is afhankelijk van een goed gedefinieerd proces. Het is belangrijk om de end-to-end ontwikkelwerkstroom duidelijk te beschrijven en te documenteren. Zorg ervoor dat de geselecteerde strategieën en processen overeenkomen met bestaande procedures in uw team en zo niet, hoe u wijzigingen gaat beheren. Zorg er bovendien voor dat de processen duidelijk zijn en worden gecommuniceerd met alle teamleden en belanghebbenden. Zorg ervoor dat teamleden en belanghebbenden die niet bekend zijn met de processen, worden getraind om ze te implementeren en dat ze de waarde waarderen van succesvolle DevOps-acceptatie.

REST-API's voor Power BI

U ontwikkelt programmatische logica voor het importeren en implementeren van inhoud uit Azure DevOps met behulp van de Power BI REST API's. U importeert Power BI-bestanden (.pbix) in een werkruimte met behulp van een importbewerking. U gebruikt een pijplijnbewerking om bepaalde inhoud of alle inhoud te implementeren om werkruimten te testen of te produceren met behulp van Power BI-implementatiepijplijnen. De programmatische logica wordt gedefinieerd in de Azure Pipelines.

U wordt aangeraden een service-principal te gebruiken om Power BI REST API's aan te roepen in uw pijplijnen. Een service-principal is bedoeld voor onbeheerde, geautomatiseerde activiteiten en is niet afhankelijk van gebruikersreferenties. Sommige items en activiteiten worden echter niet ondersteund door de Power BI REST API's of wanneer u een service-principal gebruikt, zoals gegevensstromen.

Wanneer u een service-principal gebruikt, moet u de machtigingen zorgvuldig beheren. Uw doel moet zijn om het principe van minimale bevoegdheden te volgen. U moet voldoende machtigingen instellen voor de service-principal zonder machtigingen voor overinrichting. Gebruik Azure Key Vault of een andere service waarmee de geheimen en referenties van de service-principal veilig worden opgeslagen.

Let op

Als u een gegevensmodel hebt dat is opgeslagen als een door mensen leesbare metagegevensindeling, kan het niet worden gepubliceerd met behulp van de Power BI REST API's. In plaats daarvan moet u het publiceren met behulp van het XMLA-eindpunt. U kunt metagegevensbestanden publiceren met behulp van hulpprogramma's van derden, zoals de opdrachtregelinterface van de Tabular Editor (CLI). U kunt metagegevensbestanden ook programmatisch publiceren met behulp van uw eigen aangepaste .NET-ontwikkeling. Voor het ontwikkelen van een aangepaste oplossing is meer inspanning vereist, omdat u de Microsoft Tabular Object Model -extensie (TOM) van de AMO-clientbibliotheken (Analysis Management Object) moet gebruiken.

Azure-pipelines

Azure Pipelines automatiseert programmatisch testen, beheren en implementeren van inhoud. Wanneer een pijplijn wordt uitgevoerd, worden de stappen in de pijplijn automatisch uitgevoerd. Eigenaren van pijplijnen kunnen de 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. Een Azure Pipeline kan bijvoorbeeld geautomatiseerde tests uitvoeren of parameters voor gegevensmodellen wijzigen vóór een implementatie.

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 deze pijplijnen 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 Power BI-implementatiepijplijnen. U hoeft bijvoorbeeld geen validatiepijplijn te hebben; u kunt alleen build- en release-pijplijnen gebruiken.

Validatiepijplijnen

Validatiepijplijnen voeren basiskwaliteitscontroles van gegevensmodellen uit voordat ze worden gepubliceerd naar een ontwikkelwerkruimte. Normaal gesproken activeren wijzigingen in een vertakking van de externe opslagplaats de pijplijn om deze wijzigingen 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

Bouw pijplijnen voor het voorbereiden van gegevensmodellen voor publicatie naar het Power BI-service. Deze pijplijnen combineren geserialiseerde modelmetagegevens in één bestand dat later wordt gepubliceerd door een release-pijplijn (beschreven in het diagram met releasepijplijnen). Een build-pijplijn kan ook andere 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 Desktop-bestanden (.pbix) 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.

• Release-pijplijn voor ontwikkeling: deze eerste pijplijn wordt automatisch geactiveerd. Inhoud wordt gepubliceerd naar een ontwikkelwerkruimte nadat de build- en validatiepijplijnen zijn geslaagd.
• Test- en productiereleasepijplijnen: deze pijplijnen worden niet automatisch geactiveerd. In plaats daarvan worden ze geactiveerd op aanvraag of wanneer ze zijn goedgekeurd. Test- en productiereleasepijplijnen implementeren respectievelijk inhoud in een test- of productiewerkruimte na goedkeuring van de release. Goedkeuringen voor de release 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.

Er zijn twee verschillende benaderingen voor het publiceren van inhoud met test- en release-pijplijnen. Ze promoten inhoud met behulp van een Power BI-implementatiepijplijn of publiceren inhoud naar de Power BI-service vanuit Azure DevOps.

In het volgende diagram ziet u de eerste benadering. In deze benadering organiseren releasepijplijnen de implementatie van inhoud om werkruimten te testen en te produceren met behulp van Power BI-implementatiepijplijnen. Inhoud wordt gepromoveerd via ontwikkel-, test- en productiewerkruimten in Power BI. Hoewel deze aanpak robuuster en eenvoudiger te onderhouden is, is Premium-licentie vereist.

In het diagram ziet u de volgende gebruikersacties, processen en functies van de eerste benadering.

Artikel	Beschrijving
	In de eerste benadering publiceren de releasepijplijnen inhoud met behulp van het XMLA-eindpunt en de Power BI REST API's met Power BI-implementatiepijplijnen. Inhoud wordt gepubliceerd en vervolgens gepromoveerd via ontwikkel-, test- en productiewerkruimten. Power BI-implementatiepijplijnen en het XMLA-eindpunt voor lezen/schrijven zijn Premium-functies.
	Een geslaagde vertakkingssamenvoeging of voltooiing van een upstream-pijplijn activeert de build-pijplijn. De build-pijplijn bereidt vervolgens inhoud voor op het publiceren en activeert de release-pijplijn voor ontwikkeling.
	De releasepijplijn voor ontwikkeling publiceert inhoud naar de ontwikkelwerkruimte met behulp van het XMLA-eindpunt (voor metagegevens van het gegevensmodel) of de Power BI REST API's (voor Power BI Desktop-bestanden, die gegevensmodellen en rapporten kunnen bevatten). De ontwikkelingspijplijn maakt gebruik van de opdrachtregelinterface van de Tabular Editor (CLI) om metagegevens van het gegevensmodel te implementeren met behulp van het XMLA-eindpunt.
	Met een releasegoedkeuring of trigger op aanvraag wordt de testreleasepijplijn geactiveerd.
	Met de testreleasepijplijn wordt inhoud geïmplementeerd met behulp van de Power BI REST API-implementatiebewerkingen, waarmee de Power BI-implementatiepijplijn wordt uitgevoerd.
	De Power BI-implementatiepijplijn bevordert inhoud van de ontwikkelwerkruimte naar de testwerkruimte. Na de implementatie voert de release-pijplijn activiteiten na de implementatie uit met behulp van de Power BI REST API's (niet weergegeven in het diagram).
	Een releasegoedkeuring of trigger op aanvraag activeert de productiereleasepijplijn.
	Met de productiereleasepijplijn wordt inhoud geïmplementeerd met behulp van de Power BI REST API-implementatiebewerkingen, waarmee de Power BI-implementatiepijplijn wordt uitgevoerd.
	De Power BI-implementatiepijplijn bevordert inhoud van de testwerkruimte naar de productiewerkruimte. Na de implementatie voert de release-pijplijn activiteiten na de implementatie uit met behulp van de Power BI REST API's (niet weergegeven in het diagram).

In het volgende diagram ziet u de tweede benadering. Deze benadering maakt geen gebruik van implementatiepijplijnen. In plaats daarvan worden releasepijplijnen gebruikt om inhoud te publiceren om werkruimten te testen en te produceren vanuit Azure DevOps. Deze tweede benadering vereist geen Premium-licenties wanneer u alleen Power BI Desktop-bestanden met de Power BI REST API's publiceert. Het omvat 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 meer vertrouwd met deze aanpak. Ontwikkelteams die deze aanpak gebruiken, kunnen de implementatie van gegevensoplossingen in Azure DevOps consolideren.

In het diagram ziet u de volgende gebruikersacties, processen en functies in de tweede benadering.

Artikel	Beschrijving
	In de tweede benadering publiceren de releasepijplijnen alleen inhoud met behulp van het XMLA-eindpunt en de Power BI REST API's. Inhoud wordt gepubliceerd naar ontwikkel-, test- en productiewerkruimten.
	Een geslaagde vertakkingssamenvoeging of voltooiing van een upstream-pijplijn activeert de build-pijplijn. De build-pijplijn bereidt vervolgens inhoud voor op het publiceren en activeert de release-pijplijn voor ontwikkeling.
	De releasepijplijn voor ontwikkeling publiceert inhoud naar de ontwikkelwerkruimte met behulp van het XMLA-eindpunt (voor metagegevens van het gegevensmodel) of de Power BI REST API's (voor Power BI Desktop-bestanden, die gegevensmodellen en rapporten kunnen bevatten). De ontwikkelingspijplijn maakt gebruik van de opdrachtregelinterface van de Tabular Editor (CLI) om metagegevens van het gegevensmodel te implementeren met behulp van het XMLA-eindpunt.
	Met een releasegoedkeuring of trigger op aanvraag wordt de testreleasepijplijn geactiveerd.
	De releasepijplijn voor ontwikkeling publiceert inhoud naar de testwerkruimte met behulp van het XMLA-eindpunt (voor metagegevens van gegevensmodellen) of Power BI REST API's (voor Power BI Desktop-bestanden, die gegevensmodellen en rapporten kunnen bevatten). De ontwikkelingspijplijn maakt gebruik van de opdrachtregelinterface van de Tabular Editor (CLI) om metagegevens van het gegevensmodel te implementeren met behulp van het XMLA-eindpunt. Na de implementatie voert de release-pijplijn activiteiten na de implementatie uit met behulp van de Power BI REST API's (niet weergegeven in het diagram).
	Een releasegoedkeuring of trigger op aanvraag activeert de productiereleasepijplijn.
	De releasepijplijn voor ontwikkeling publiceert inhoud naar de productiewerkruimte met behulp van het XMLA-eindpunt (voor metagegevens van gegevensmodellen) of Power BI REST API's (voor Power BI Desktop-bestanden, die gegevensmodellen en rapporten kunnen bevatten). De ontwikkelingspijplijn maakt gebruik van de opdrachtregelinterface van de Tabular Editor (CLI) om metagegevens van het gegevensmodel te implementeren met behulp van het XMLA-eindpunt. Na de implementatie voert de release-pijplijn activiteiten na de implementatie uit met behulp van de Power BI REST API's (niet weergegeven in het diagram).

Release-pijplijnen moeten activiteiten na de implementatie beheren. Deze activiteiten kunnen bestaan uit het instellen van semantische modelreferenties of het bijwerken van de Power BI-app voor test- en productiewerkruimten. U wordt aangeraden meldingen in te stellen om relevante personen te informeren over implementatieactiviteiten.

Tip

Met behulp van een opslagplaats voor versiebeheer kunnen makers van inhoud een terugdraaiproces maken. Het terugdraaiproces kan de laatste implementatie omkeren door de vorige versie te herstellen. Overweeg om een afzonderlijke set Azure Pipelines te maken die u kunt activeren om productiewijzigingen terug te draaien. Denk goed na over welke processen en goedkeuringen nodig zijn om een terugdraaiactie te starten. Zorg ervoor dat deze processen worden gedocumenteerd.

Power BI-implementatiepijplijnen

Een Power BI-implementatiepijplijn bestaat uit drie fasen: ontwikkeling, test en productie. U wijst één Power BI-werkruimte toe aan elke fase in de implementatiepijplijn. Wanneer een implementatie plaatsvindt, bevordert de implementatiepijplijn Power BI-items van de ene werkruimte naar de andere.

Een Release-pijplijn van Azure Pipelines maakt gebruik van de Power BI REST API's om inhoud te implementeren met behulp van een Power BI-implementatiepijplijn. Toegang tot zowel de werkruimte als de implementatiepijplijn is vereist voor de gebruikers die een implementatie uitvoeren. U wordt aangeraden de implementatiepijplijntoegang te plannen, zodat pijplijngebruikers de implementatiegeschiedenis kunnen bekijken en inhoud kunnen vergelijken.

Tip

Wanneer u gegevenswerkruimten van rapportagewerkruimten scheidt, kunt u Overwegen Azure Pipelines te gebruiken om het publiceren van inhoud te organiseren met meerdere Power BI-implementatiepijplijnen. Semantisch model wordt eerst geïmplementeerd en vervolgens worden ze vernieuwd. Ten slotte worden rapporten geïmplementeerd. Deze aanpak helpt u bij het vereenvoudigen van de implementatie.

Premium-licenties

Power BI-implementatiepijplijnen en het XMLA-eindpunt voor lezen/schrijven zijn Premium-functies. Deze functies zijn beschikbaar met Power BI Premium-capaciteit en PPU (Power BI Premium Per User).

PPU is een rendabele manier om publicatie van bedrijfsinhoud te beheren voor ontwikkelings- en testwerkruimten, die doorgaans weinig gebruikers hebben. Deze aanpak heeft het extra voordeel van het isoleren van ontwikkel- en testworkloads van productieworkloads.

Notitie

U kunt het publiceren van bedrijfsinhoud nog steeds instellen zonder een Premium-licentie, zoals beschreven in de tweede benadering in de sectie release-pijplijn . In de tweede benadering gebruikt u Azure Pipelines om de implementatie van Power BI Desktop-bestanden te beheren voor ontwikkel-, test- en productiewerkruimten. U kunt modelmetagegevens echter niet implementeren met behulp van het XMLA-eindpunt, omdat het niet mogelijk is om een semantisch model voor metagegevensindeling te publiceren met de Power BI REST API's. Het is ook niet mogelijk om inhoud te promoten via omgevingen met implementatiepijplijnen zonder een Premium-licentie.

Gateway instellen

Normaal gesproken is een gegevensgateway vereist bij het openen van gegevensbronnen die zich in het particuliere organisatienetwerk of een virtueel netwerk bevinden. De twee doeleinden van een gateway zijn het vernieuwen van geïmporteerde gegevens en het weergeven van een rapport waarin een query wordt uitgevoerd op een liveverbinding of een semantisch DirectQuery-model (niet weergegeven in het scenariodiagram).

Wanneer u met meerdere omgevingen werkt, is het gebruikelijk om ontwikkel-, test- en productieverbindingen met verschillende bronsystemen in te stellen. In dit geval gebruikt u gegevensbronregels en parameterregels om waarden te beheren die verschillen tussen omgevingen. U kunt Azure Pipelines gebruiken om gateways te beheren met behulp van de gatewaybewerkingen van de Power BI REST API's.

Notitie

Een gecentraliseerde gegevensgateway in de standaardmodus wordt sterk aanbevolen voor gateways in de persoonlijke modus. In de standaardmodus ondersteunt de gegevensgateway liveverbindings- en DirectQuery-bewerkingen (naast geplande bewerkingen voor gegevensvernieuwing).

Systeemtoezicht

In het activiteitenlogboek worden gebeurtenissen vastgelegd die voorkomen in de Power BI-service. Power BI-beheerders kunnen het activiteitenlogboek gebruiken om implementatieactiviteiten te controleren .

U kunt de API's voor het scannen van Power BI-metagegevens gebruiken om een tenantinventaris te maken. De API-resultaten zijn handig om te controleren welke items in elke werkruimte zijn geïmplementeerd, om herkomst te controleren en beveiligingsinstellingen te valideren.

Er is ook een auditlogboek in Azure DevOps, dat zich buiten de Power BI-service bevindt. Azure DevOps-beheerders kunnen het auditlogboek gebruiken om activiteiten in externe opslagplaatsen en pijplijnen te controleren.

Gerelateerde inhoud

Zie het artikel over power BI-gebruiksscenario's voor andere nuttige scenario's om u te helpen bij het nemen van beslissingen over power BI-implementaties.