Power BI-implementatieplanning: inhoud ontwikkelen en wijzigingen beheren

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-ervaring in Microsoft Fabric. Zie de planning van de Power BI-implementatie voor een inleiding tot de reeks.

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

• Coe- en BI-teams (Center of Excellence): de teams die verantwoordelijk zijn voor het toezicht op 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 rollen bevatten, zoals releasemanagers, die de levenscyclus van inhoudsreleases verwerken, of technici die de onderdelen maken en beheren die nodig zijn om het levenscyclusbeheer effectief te gebruiken en te ondersteunen.
• Makers van inhoud en eigenaren van inhoud: gebruikers die inhoud maken, die ze willen publiceren naar 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 is de processen en procedures die u gebruikt om inhoud van het maken ervan tot de uiteindelijke buitengebruikstelling af te handelen. In de eerste fase van levenscyclusbeheer plant en ontwerpt u inhoud, waarbij oplossingsplanning en belangrijke beslissingen worden genomen die van invloed zijn op uw benadering van levenscyclusbeheer. In de tweede fase ontwikkelt u inhoud en beheert u wijzigingen.

Het beheren van inhoudswijzigingen tijdens de levenscyclus is belangrijk om effectieve samenwerking tussen makers van inhoud en stabiele en consistente levering van inhoud aan consumenten te garanderen.

In de volgende afbeelding ziet u de levenscyclus van Power BI-inhoud, waarbij fase 2 wordt gemarkeerd, waarin u inhoud ontwikkelt en wijzigingen beheert.

Notitie

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

Tip

Dit artikel richt zich op belangrijke beslissingen en overwegingen om u te helpen bij het ontwikkelen van inhoud en het beheren van wijzigingen gedurende de gehele levenscyclus. Zie voor meer informatie over het ontwikkelen van inhoud en het beheren van wijzigingen:

• Wat is levenscyclusbeheer in Microsoft Fabric?: dit artikel bevat een technische inleiding en zelfstudie over infrastructuur-Git-integratie- en implementatiepijplijnen.
• Aanbevolen procedures voor levenscyclusbeheer: dit artikel bevat praktische tips en richtlijnen voor het gebruik van de functies voor levenscyclusbeheer van Fabric en Power BI om inhoud te ontwikkelen en wijzigingen te beheren.
• Integratie van Power BI Desktop OneDrive en SharePoint: dit artikel bevat een overzicht van de opties voor het gebruik en opslaan van bestanden die zijn opgeslagen in OneDrive voor Werk en School of SharePoint wanneer u versiebeheer uitvoert met PBIX-bestanden.
• Aan de slag met Git in Azure-opslagplaatsen: deze reeks artikelen bevat praktische tips, zelfstudies en richtlijnen voor het uitvoeren van broncodebeheer met behulp van een Git-opslagplaats in Azure-opslagplaatsen.

Makers en eigenaren van inhoud moeten inhoudswijzigingen beheren met behulp van versiebeheer. Versiebeheer is de praktijk van het beheren van wijzigingen in bestanden of code in een centrale opslagplaats. Deze praktijk faciliteert effectievere samenwerking en inhoudsbeheer.

Andere voordelen van versiebeheer zijn de mogelijkheid om:

• Wijzigingen van meerdere makers van inhoud samenvoegen en samenvoegingsconflicten afhandelen.
• Bepaal welke inhoud is gewijzigd en wat er in die inhoud is gewijzigd.
• Inhoudswijzigingen aan specifieke werkitems koppelen.
• Groepeer wijzigingen in afzonderlijke releases met versiegeschiedenis.
• Wijzigingen of volledige versies van inhoud terugdraaien.

Tip

U wordt aangeraden versiebeheer te gebruiken voor alle inhoud die u maakt, indien mogelijk. Het gebruik van versiebeheer heeft aanzienlijke voordelen voor zowel makers van inhoud als consumenten en vermindert het risico op onderbrekingen als gevolg van bestandsverlies of het niet terugdraaien van wijzigingen.

De eerste stap voor het instellen van versiebeheer is om te bepalen hoe u inhoud gaat ontwikkelen.

Bepalen hoe u inhoud ontwikkelt

Afhankelijk van hoe u inhoud ontwerpt, neemt u verschillende beslissingen over het beheren ervan. Voor Power BI-rapporten en semantische modellen heeft een Power BI Desktop-bestand (.pbix) bijvoorbeeld minder opties voor versiebeheer in vergelijking met de Power BI Desktop-projectindeling (.pbip ). Dat komt doordat een PBIX-bestand een binaire indeling is, terwijl de PBIP-indeling tekstgebaseerde, door mensen leesbare inhoud en metagegevens bevat. Door leesbare inhoud en metagegevens te hebben, kunnen model- en rapportwijzigingen eenvoudiger worden bijgehouden met behulp van broncodebeheer. Broncodebeheer is wanneer u wijzigingen in inhoud in de code en metagegevens ervan bekijkt en beheert.

Tip

Bij het ontwikkelen van semantische modellen en rapporten met behulp van Power BI Desktop raden we u aan PBIP-bestanden te gebruiken in plaats van PBIX-bestanden. Bij het ontwikkelen van semantische modellen met behulp van XMLA-hulpprogramma's raden we u aan de TMDL-indeling (Tabular Model Definition Language) te gebruiken in plaats van .bim-bestanden.

De .pbip- en TMDL-indelingen bieden ondersteuning voor eenvoudiger bijhouden en samenvoegen van wijzigingen op objectniveau. Dit betekent dat u wijzigingen in afzonderlijke objecten, zoals DAX-metingen of tabellen, kunt bekijken en beheren.

Power BI Desktop

U kunt Power BI Desktop gebruiken om semantische modellen of rapporten te maken, die u kunt opslaan als PBIX- of PBIP-bestanden. Er zijn extra aangepaste inhoudsbestanden die u ook kunt gebruiken wanneer u Power BI Desktop gebruikt. Wanneer u Power BI Desktop gebruikt om inhoud te maken, moet u enkele belangrijke beslissingen nemen:

• Welke bestandsindeling moet worden gebruikt: u kunt inhoud opslaan als PBIX- of PBIP-bestanden. Git-integratie vereist bijvoorbeeld dat u PBIP-bestanden gebruikt, kunnen selfservicemakers .pbix-bestanden eenvoudiger vinden om te beheren en te onderhouden in Teams, SharePoint of OneDrive.
• Aangepaste inhoud beheren: u kunt thema's, aangepaste visuals of afbeeldingen toevoegen aan Power BI Desktop-bestanden. Hiervoor zijn mogelijk verschillende overwegingen vereist voor levenscyclusbeheer. Wanneer makers van inhoud bijvoorbeeld hun eigen aangepaste visuals maken, moeten ze de definitie van de visual opslaan en beheren in een afzonderlijk bestand.
• Preview-functies beheren: u kunt zich aanmelden voor preview-functies of -instellingen in Power BI Desktop, waardoor inhoud wordt gewijzigd en hoe u deze gaat gebruiken. U kunt bijvoorbeeld aanvullende stappen uitvoeren om inhoud te valideren die gebruikmaakt van preview-functies.

Webcreatie

Bepaalde inhoud, zoals gegevensstromen, dashboards en scorecards, kan alleen worden gemaakt in de Fabric-portal. U kunt ook bepaalde inhoud, zoals semantische modellen, rapporten en gepagineerde rapporten, maken of wijzigen in zowel de Fabric-portal als met behulp van lokale hulpprogramma's. Bij het maken van inhoud met behulp van webcreatie moeten enkele belangrijke beslissingen worden genomen:

• Wijzigingen beheren: U kunt wijzigingen aanbrengen in veel itemtypen door webcreatie te gebruiken, maar deze wijzigingen kunnen direct worden opgeslagen, waarbij eerdere versies worden overschreven. Als u bijvoorbeeld met anderen samenwerkt, wilt u mogelijk voorkomen dat webcreatie wordt uitgevoerd op gedeelde items, maar in plaats daarvan op uw eigen kopie.
• Back-ups van inhoud ophalen: u kunt inhoud zoals rapporten of semantische modellen maken met webcreatie, maar deze items kunnen niet worden gedownload naar lokale PBIX-bestanden. U kunt bijvoorbeeld een back-up van deze inhoud maken door de metagegevens op te halen en op te slaan.

Tip

Bij het ontwikkelen van gegevensstromen en scorecards wordt u aangeraden de itemdefinities op te halen om wijzigingen te beheren en een back-up op te slaan. U kunt het ophalen van gegevensstromen en scorecards automatiseren met behulp van de Rest API's van Fabric. U kunt met name de eindpunten Gegevensstroom ophalen en Scorecards ophalen gebruiken.

Let op

Sommige inhoud, zoals dashboards, heeft niet de mogelijkheid om een definitie op te halen. Voor deze inhoud kunt u wijzigingen niet eenvoudig bijhouden of een back-up ophalen.

Andere hulpprogramma's

U kunt andere hulpprogramma's gebruiken om bepaalde typen inhoud te maken of te beheren. Deze hulpprogramma's bieden mogelijk extra voordelen, passen beter bij uw werkstroom of zijn vereist voor het beheren van specifieke functies of inhoudstypen. U kunt zowel andere Microsoft-hulpprogramma's als hulpprogramma's van derden gebruiken om inhoud te maken en te beheren. Andere hulpprogramma's die u kunt gebruiken om inhoud te maken of te beheren, zijn als volgt.

• Visual Studio of Visual Studio Code: een geïntegreerde ontwikkelomgeving voor ontwikkelaars voor het maken en beheren van semantische modellen of Fabric-notebooks. Met zowel Visual Studio als Visual Studio Code kunnen ontwikkelaars ook broncodebeheer (SCM) uitvoeren door lokale wijzigingen door te voeren en naar een externe opslagplaats te pushen.
• Tabular Editor: een hulpprogramma van derden voor het ontwikkelen en beheren van semantische modellen.
• Excel: een clienthulpprogramma voor draaitabellen en live verbonden tabellen die werken met een semantisch model.
• Power BI Report Builder: een bureaubladtoepassing voor het maken van gepagineerde rapportbestanden (.rdl).

Bij het maken van inhoud met behulp van andere hulpprogramma's moet u enkele belangrijke beslissingen nemen:

• Licenties beheren: voor andere hulpprogramma's zijn mogelijk extra licenties vereist die u moet beheren.
• Inhoud publiceren: voor andere hulpprogramma's zijn mogelijk aanvullende stappen vereist voor het publiceren van inhoud, zoals het gebruik van XMLA-eindpunten of de Power BI REST API's.

Zodra u besluit hoe u inhoud gaat maken, moet u vervolgens kiezen waar u inhoud gaat publiceren en testen terwijl u deze ontwikkelt.

Bepalen hoe u werkruimten instelt en gebruikt

Bij het ontwikkelen van inhoud moet u meerdere werkruimten (of fasen) gebruiken om productie-inhoud die door de organisatie wordt gebruikt te scheiden van inhoud die wordt ontwikkeld of gevalideerd. Er zijn verschillende voordelen voor het gebruik van afzonderlijke werkruimten voor uw inhoud:

• U kunt inhoud ontwikkelen en testen zonder dat dit van invloed is op de inhoud die momenteel wordt gebruikt. Dit voorkomt wijzigingen die onbedoelde onderbreking van inhoud in productie kunnen veroorzaken.
• U kunt afzonderlijke resources gebruiken voor het ontwikkelen en testen van inhoud, zoals het gebruik van afzonderlijke gegevensgateways of Fabric-capaciteiten. Dit voorkomt dat resources die worden gebruikt voor ontwikkeling en testen productieworkloads verstoren, waardoor trage gegevensvernieuwingen of rapporten ontstaan.
• U kunt een meer gestructureerd proces maken voor het ontwikkelen, testen en vrijgeven van inhoud door afzonderlijke omgevingen te hebben voor elk van deze fasen. Dit helpt u om de productiviteit te verbeteren.

In Fabric en Power BI raden we u aan afzonderlijke Fabric-werkruimten te gebruiken, zoals beschreven in de planningsartikelen op tenant- en werkruimteniveau .

Belangrijk

Het gebruik van afzonderlijke omgevingen is een essentiële stap om het succes van uw levenscyclusbeheer van inhoud te garanderen.

Er zijn meerdere manieren om Fabric-werkruimten te gebruiken om omgevingen te scheiden. Doorgaans gebruikt u naast uw lokale omgeving twee of meer werkruimten om inhoud tijdens de levenscyclus te beheren.

Beantwoord de volgende vragen wanneer u plant hoe u gedurende de levenscyclus van deze inhoud afzonderlijke werkruimten gaat gebruiken:

• Hoeveel werkruimten hebt u nodig?
• Scheidt u werkruimten op itemtype?
• Wie heeft toegang tot elke werkruimte?
• Behoort de werkruimten tot een Infrastructuurimplementatiepijplijn of organiseert u de implementatie met behulp van andere methoden, zoals met behulp van Azure Pipelines?
• Hoe beheert u publicatie tussen werkruimten? Moet u er bijvoorbeeld voor zorgen dat rapporten in een testwerkruimte voor rapporten verbinding maken met semantische modellen in een afzonderlijke testwerkruimte voor gegevensitems?
• Moet u ook afzonderlijke ondersteunende resources gebruiken voor items in productiewerkruimten, zoals een afzonderlijk on-premises gegevensgatewaycluster?

De volgende secties bieden een algemeen overzicht van de verschillende benaderingen die u kunt gebruiken om werkruimten te scheiden om levenscyclusbeheer te vergemakkelijken.

Notitie

De volgende secties richten zich op het instellen en gebruiken van afzonderlijke werkruimten. U kunt inhoud implementeren in deze werkruimten met behulp van een van de volgende vier benaderingen:

• Publiceren vanuit Power BI Desktop.
• Inhoud implementeren vanuit een andere werkruimte met behulp van Infrastructuurimplementatiepijplijnen.
• Inhoud synchroniseren vanuit een externe Git-opslagplaats met behulp van Git-integratie.
• Inhoud programmatisch implementeren met behulp van de Fabric REST API's, Power BI REST API's of XMLA-eindpunten.

Zie fase 4: Inhoud later in deze reeks implementeren voor meer informatie over deze methoden voor het implementeren van inhoud .

Werkruimten testen en productie

Wanneer u eenvoudigere inhoud levert die niet essentieel is voor de organisatie, kunnen twee werkruimten vaak voldoende zijn. In dit scenario hebben makers van inhoud doorgaans beperkte samenwerking op dezelfde items en ontwikkelen ze lokaal inhoud.

In het volgende diagram ziet u een voorbeeld op hoog niveau van hoe u afzonderlijke omgevingen kunt gebruiken met alleen een test- en productiewerkruimte.

In het diagram ziet u de volgende processen en onderdelen voor het scheiden van werkruimten in deze benadering.

Artikel	Beschrijving
	Makers van inhoud ontwikkelen inhoud in hun lokale omgeving.
	Wanneer ze klaar zijn, publiceren makers van inhoud inhoud naar een testwerkruimte. Makers van inhoud kunnen inhoud ontwikkelen die alleen kan worden geproduceerd met webcreatie en inhoudsvalidatie uitvoeren in de testwerkruimte.
	Wanneer ze klaar zijn, implementeren makers van inhoud inhoud in een productiewerkruimte. In de productiewerkruimte distribueren makers van inhoud inhoud door een Power BI-app te publiceren of inhoud uit de werkruimte te delen.

Notitie

Er zijn veel verschillende manieren om afzonderlijke werkruimten in te stellen en te gebruiken en inhoud tussen deze werkruimten te implementeren. We raden u echter aan geen lokale ontwikkeling uit te voeren en vervolgens inhoud rechtstreeks naar een productiewerkruimte te publiceren. Dit kan leiden tot te voorkomen onderbrekingen en fouten.

Ontwikkel-, test- en productiewerkruimten

Wanneer u bedrijfskritieke inhoud levert, gebruikt u doorgaans drie of meer afzonderlijke werkruimten. In dit scenario werken makers van inhoud vaak samen in een extra ontwikkelwerkruimte die de nieuwste versie van de oplossing bevat.

In het volgende diagram ziet u een voorbeeld op hoog niveau van hoe u afzonderlijke omgevingen kunt gebruiken met een ontwikkel-, test- en productiewerkruimte.

In het diagram ziet u de volgende processen en onderdelen voor het scheiden van werkruimten in deze benadering.

Artikel	Beschrijving
	Makers van inhoud ontwikkelen inhoud in hun lokale omgeving.
	Wanneer ze klaar zijn, publiceren makers van inhoud inhoud naar een ontwikkelwerkruimte. In de ontwikkelwerkruimte kunnen makers van inhoud inhoud ontwikkelen die alleen kan worden geproduceerd met webcreatie. Makers van inhoud kunnen ook inhoud valideren in de ontwikkelwerkruimte.
	Wanneer inhoudsmakers klaar zijn, implementeren ze inhoud in een testwerkruimte. In de testwerkruimte valideren gebruikers inhoud in de werkruimte of een app.
	Wanneer ze klaar zijn, implementeren makers van inhoud inhoud in een productiewerkruimte. In de productiewerkruimte distribueren makers van inhoud inhoud door een Power BI-app te publiceren of inhoud uit de werkruimte te delen.

Notitie

U kunt maximaal tien verschillende omgevingen gebruiken met implementatiepijplijnen. U wilt bijvoorbeeld een preproductieomgeving hebben tussen test en productie die specifiek is voor speciale typen validatie, zoals prestatietests.

Privéwerkruimte met Git-integratie

Bij het leveren van bedrijfskritieke inhoud kan elke ontwikkelaar ook een eigen privéwerkruimte gebruiken voor ontwikkeling. In dit scenario kunnen makers van inhoud met een privéwerkruimte inhoud testen in de Fabric-portal of functies zoals geplande vernieuwing gebruiken zonder dat anderen in het ontwikkelteam last hebben van onderbrekingen. Makers van inhoud kunnen hier ook inhoud ontwikkelen in de Fabric-portal, zoals gegevensstromen. Privéwerkruimten kunnen een goede keuze zijn wanneer u inhoudswijzigingen beheert met behulp van Git-integratie in combinatie met Azure DevOps.

Notitie

Azure DevOps is een suite met services die kunnen worden 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 hieraan bij te dragen.

In het volgende diagram ziet u een voorbeeld op hoog niveau van hoe u afzonderlijke omgevingen kunt gebruiken met behulp van een privéwerkruimte met Git-integratie.

Notitie

In het diagram ziet u afzonderlijke ontwikkelaars die aan afzonderlijke vertakkingen van een oplossing werken (vertakking één en twee vertakkingen) voordat ze hun wijzigingen samenvoegen in een hoofdbranch. Dit is een vereenvoudigde weergave van een Git-vertakkingsstrategie om te illustreren hoe ontwikkelaars hun wijzigingen kunnen integreren met een externe Git-opslagplaats en kunnen profiteren van Git-integratie in Fabric.

In het diagram ziet u de volgende processen en onderdelen voor het scheiden van werkruimten in deze benadering.

Artikel	Beschrijving
	Elke maker van inhoud ontwikkelt inhoud in een eigen lokale omgeving.
	Wanneer ze klaar zijn, voeren makers van inhoud hun wijzigingen door naar een externe opslagplaats, zoals een Git-opslagplaats voor Azure-opslagplaatsen.
	In de externe Git-opslagplaats kunnen makers van inhoud inhoud wijzigingen bijhouden en beheren met behulp van broncodebeheer en inhoud vertakken en samenvoegen om samenwerking te vergemakkelijken.
	Makers van inhoud synchroniseren een vertakking van de externe opslagplaats met een privéwerkruimte. Na het synchroniseren zijn de meest recente wijzigingen die een maker doorvoert en pusht naar de vertakking zichtbaar in die privéwerkruimte. Verschillende makers van inhoud werken zelfstandig, afzonderlijke vertakkingen wanneer ze wijzigingen aanbrengen.
	In de privéwerkruimten kunnen makers van inhoud inhoud ontwikkelen met behulp van webcreatie en hun eigen wijzigingen valideren. Wijzigingen in inhoud die door webcreatie zijn aangebracht, kunnen worden gesynchroniseerd met de vertakking in de Git-opslagplaats wanneer de maker van de inhoud deze wijzigingen doorvoert en pusht vanuit de werkruimte. Verschillende makers van inhoud werken in hun eigen, afzonderlijke privéwerkruimten.
	Wanneer ze klaar zijn, voeren makers van inhoud een pull-aanvraag uit om hun wijzigingen samen te voegen in de hoofdbranch van de oplossing.
	Nadat wijzigingen zijn samengevoegd, wordt de hoofdbranch gesynchroniseerd met de ontwikkelwerkruimte.
	In de ontwikkelwerkruimte kunnen makers van inhoud inhoud ontwikkelen die niet wordt ondersteund door Fabric Git-integratie, zoals dashboards. Makers van inhoud valideren ook de geïntegreerde oplossing die alle meest recente wijzigingen bevat.
	Wanneer inhoudsmakers klaar zijn, implementeren ze inhoud in een testwerkruimte. In de testwerkruimte voeren gebruikers acceptatietests van inhoud uit.
	Wanneer ze klaar zijn, implementeren makers van inhoud inhoud in een productiewerkruimte. In de productiewerkruimte distribueren makers van inhoud inhoud door een Power BI-app te publiceren of inhoud uit de werkruimte te delen.

Ondersteunende resources voor werkruimten

Wanneer u afzonderlijke omgevingen gebruikt, moet u ook overwegen hoe dit van invloed is op verschillende ondersteunende resources die u in deze omgevingen gebruikt. Voor deze ondersteunende resources moet u overwegen of u ze ook moet scheiden in hetzelfde aantal fasen, of anders hoe u het gebruik in deze omgevingen coördineert.

• Gateways: Overweeg het gebruik van afzonderlijke on-premises gegevensgatewayclusters en VNet-gateways voor productieworkloads. Dit is handig om onderbrekingen te voorkomen, maar ook om de uptime te garanderen wanneer u deze gateways moet bijwerken.
• Apps: Overweeg om afzonderlijke apps te gebruiken voor test- en productiewerkruimten. Het is niet mogelijk om apps tussen fasen te implementeren of te kopiëren. Apps in de testwerkruimte zijn bedoeld om u te helpen bij het testen van inhoud en de app-ervaring voordat u wijzigingen in de productiewerkruimte implementeert. Apps in de productiewerkruimte zijn bedoeld om inhoud te leveren aan eindgebruikers in een gestructureerde en ervaring.
• Azure DevOps: Als u Azure DevOps wilt gebruiken om samen te werken en broncodebeheer en implementatie te organiseren, kunt u overwegen hoe u vertakkingen en Azure Pipelines gebruikt om inhoud tussen deze omgevingen te implementeren. Zie fase 4: Inhoud implementeren voor meer informatie over het gebruik van Azure Pipelines voor het implementeren van inhoud.

Zodra u hebt besloten hoe u werkruimten gaat instellen en gebruiken, is de volgende stap het bepalen hoe u versiebeheer uitvoert om inhoudswijzigingen bij te houden en te beheren.

Bepalen hoe u versiebeheer gaat gebruiken

In Power BI kunt u versiebeheer uitvoeren met SharePoint/OneDrive of met behulp van een externe Git-opslagplaats, zoals Azure-opslagplaatsen, een onderdeel van Azure DevOps. In beide benaderingen voegt u lokale inhoudsbestanden toe aan een externe opslaglocatie om wijzigingen bij te houden en te beheren. U wordt aangeraden SharePoint of OneDrive alleen te gebruiken voor kleinere en eenvoudigere projecten, omdat deze niet beschikt over de functies en robuustheid om grotere of complexere scenario's te ondersteunen.

Hier volgen enkele algemene overwegingen om u te helpen bij het instellen en gebruiken van versiebeheer.

• Waarschuwingen: u moet waarschuwingen instellen voor wanneer anderen kritieke bestanden toevoegen, verwijderen of wijzigen.
• Bereik: Definieer duidelijk het bereik van de externe opslaglocatie. In het ideale voorbeeld is het bereik van de externe opslaglocatie identiek aan het bereik van de downstreamwerkruimten en apps die u gebruikt om inhoud aan consumenten te leveren.
• Toegang: U moet toegang tot de externe opslaglocatie 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 externe opslaglocatie.
• Documentatie: Voeg tekstbestanden toe aan de externe opslaglocatie om de externe opslaglocatie en het doel, eigendom, toegang en gedefinieerde processen te beschrijven.

In de volgende secties worden elke benadering en belangrijke overwegingen beschreven om te bepalen welke u moet gebruiken.

Versiebeheer met SharePoint of OneDrive voor Werk en School

SharePoint heeft ingebouwd versiebeheer voor bestanden. Makers van inhoud kunnen semantische modellen of rapporten lokaal ontwikkelen en hun wijzigingen worden gesynchroniseerd met een Documentbibliotheek van SharePoint of OneDrive voor Werk en School.

Tip

Gebruik SharePoint of OneDrive alleen voor versiebeheer in eenvoudigere, kleinere scenario's, zoals het publiceren van selfservice-inhoud. Voor grotere of complexere scenario's moet u overwegen om broncodebeheer uit te voeren met behulp van een externe Git-opslagplaats.

In het volgende diagram ziet u een algemeen overzicht van hoe u versiebeheer uitvoert met SharePoint of OneDrive.

In het diagram worden de volgende processen en onderdelen beschreven.

Artikel	Beschrijving
	Makers van inhoud ontwikkelen semantische modellen en rapporten in hun lokale omgeving en slaan deze modellen en rapporten op als PBIX-bestanden.
	Wanneer ze klaar zijn, slaan makers van inhoud hun wijzigingen op, die ze synchroniseren met een externe SharePoint- of OneDrive for Work- en School-bibliotheek.
	In de externe bibliotheek houden makers van inhoud wijzigingen op bestandsniveau bij die het versiebeheer mogelijk maken.
	Makers van inhoud kunnen een gepubliceerd semantisch model of rapport koppelen aan een PBIX-bestand om het vernieuwen van OneDrive te vergemakkelijken. In OneDrive wordt elke uur automatisch inhoudswijzigingen gepubliceerd.
	In de werkruimte Fabric zien makers van inhoud de wijzigingen in Power BI-inhoud nadat OneDrive-vernieuwing is voltooid.

Belangrijk

U kunt versiebeheer alleen uitvoeren met SharePoint- of OneDrive voor Power BI Desktop-bestanden die semantische modellen of rapporten bevatten. U kunt versiebeheer niet eenvoudig uitvoeren met SharePoint of OneDrive voor andere Power BI-itemtypen, zoals gegevensstromen, of voor Fabric-itemtypen, zoals notitieblokken. Voor deze andere itemtypen moet u versiebeheer uitvoeren met behulp van een externe Git-opslagplaats, zoals Azure-opslagplaatsen.

Samenvattend kunnen makers van inhoud een gepubliceerd semantisch model of rapport koppelen aan een PBIX-bestand dat is opgeslagen in een SharePoint- of OneDrive for Work and School-bibliotheek. Met deze methode hoeven makers van inhoud het semantische model niet meer te publiceren om wijzigingen te zien. In plaats daarvan zijn de wijzigingen zichtbaar na een automatische oneDrive-vernieuwing, die elk uur plaatsvindt. Hoewel dit handig is, wordt deze aanpak geleverd met enkele overwegingen en kan deze niet eenvoudig worden omgekeerd.

Hoewel u versiebeheer met SharePoint of OneDrive eenvoudig kunt instellen en beheren, gelden er meer beperkingen. Het is bijvoorbeeld niet mogelijk om wijzigingen in de inhoud weer te geven en het is ook niet mogelijk om versies te vergelijken. Daarnaast is het niet mogelijk om geavanceerdere processen in te stellen om deze wijzigingen te beheren (zoals vertakkingen of pull-aanvragen, zoals verderop in dit artikel).

Overweeg om SharePoint of OneDrive te gebruiken om wijzigingen in de volgende scenario's bij te houden en te beheren:

• Inhoud bestaat uit alleen semantische modellen of rapporten die zijn opgeslagen als PBIX-bestanden.
• Selfservicegebruikers maken en beheren de inhoud.
• Makers van inhoud werken samen met Behulp van Microsoft Teams.
• Makers van inhoud zijn onervaren met Git- en broncodebeheer.
• Makers van inhoud beheren één item met beperkte complexiteit en samenwerking.
• Op de PBIX-bestanden is een vertrouwelijkheidslabel toegepast waarmee de inhoud wordt versleuteld.

Notitie

OneDrive en SharePoint ondersteunen inhoud waarop vertrouwelijkheidslabels zijn toegepast, met uitzondering van bepaalde beperkte scenario's. Git-integratie van Fabric biedt daarentegen geen ondersteuning voor vertrouwelijkheidslabels.

Vermijd het gebruik van SharePoint of OneDrive om wijzigingen in de volgende scenario's bij te houden en te beheren:

• Inhoud bestaat uit andere itemtypen dan semantische modellen en rapporten.
• Inhoud is complex of groot binnen het bereik.
• Makers van inhoud moeten samenwerken aan hetzelfde item tegelijk.

In de volgende secties worden aanvullende overwegingen beschreven voor het effectief gebruik van versiebeheer met SharePoint of OneDrive met Power BI.

Microsoft Teams-integratie

U kunt de documentbibliotheken van Microsoft Teams gebruiken als makers van inhoud deze gebruiken voor hun samenwerking. Documentbibliotheken zijn SharePoint-sites en het gebruik van de documentbibliotheken (in plaats van een afzonderlijke SharePoint-site of OneDrive-map) zorgt voor centralisatie van inhoud, bestanden en samenwerking.

Bestanden inchecken en uitchecken

U moet bestanden uitchecken waaraan u werkt om mogelijke wijzigingsconflicten te voorkomen. Zodra de wijzigingen zijn voltooid, checkt u de bestanden in met opmerkingen die de wijziging beschrijven. Door bestanden in en uit te checken kunt u de samenwerking tussen makers van inhoud verbeteren wanneer u SharePoint of OneDrive voor Werk en School gebruikt voor versiebeheer. Als u bestanden met meerdere makers van inhoud incheckt en uitcheckt, kunt u de SharePoint-sitebibliotheek wijzigen om de laatste update en de opmerkingen van de laatste check-in te bekijken.

Versiegeschiedenis

Zorg ervoor dat u een back-up maakt van inhoud naar een afzonderlijke locatie in het geval van onverwachte onderbrekingen in de documentbibliotheek van uw SharePoint-site. U moet ook limieten instellen voor het aantal versies dat op de SharePoint-site wordt bewaard en oude versies verwijderen. Dit zorgt ervoor dat de versiegeschiedenis zinvol blijft en niet te veel ruimte in beslag neemt.

Voor geavanceerdere versiebeheer kunt u bestanden opslaan in een externe opslagplaats, zoals Azure-opslagplaatsen en wijzigingen beheren met behulp van broncodebeheer.

Broncodebeheer met behulp van een externe Git-opslagplaats

Een externe Git-opslagplaats faciliteert broncodebeheer van bestanden, waardoor makers van inhoud meer opties kunnen bijhouden en beheren van wijzigingen. Kortom, makers van inhoud kunnen inhoud lokaal of in de Power BI-service ontwikkelen en deze wijzigingen doorvoeren en pushen naar een externe Git-opslagplaats, zoals Azure-opslagplaatsen

Notitie

U kunt ook broncodebeheer van uw inhoud uitvoeren zonder Git-integratie te gebruiken. In dit scenario kunt u nog steeds inhoudswijzigingen bijhouden en beheren in een externe Git-opslagplaats, maar u implementeert inhoud met behulp van de REST API's of XMLA-eindpunten voor lezen/schrijven. Zie fase 4: Inhoud implementeren voor meer informatie over deze methoden voor het implementeren van inhoud.

In het volgende diagram ziet u een algemeen overzicht van hoe u broncodebeheer uitvoert door

In het diagram worden de volgende processen en onderdelen beschreven.

Artikel	Beschrijving
	Makers van inhoud ontwikkelen semantische modellen en rapporten in hun lokale omgeving en slaan deze modellen en rapporten op als PBIP-bestanden. Makers van inhoud kunnen ook semantische modellen ontwikkelen en modelmetagegevens opslaan.
	Wanneer ze klaar zijn, slaan makers van inhoud hun wijzigingen op, die ze met regelmatige tussenpozen doorvoeren en pushen naar een externe Git-opslagplaats.
	In de externe Git-opslagplaats houden makers van inhoud wijzigingen op objectniveau bij, waardoor versiebeheer mogelijk is. Makers van inhoud kunnen ook vertakkingen maken om aan inhoud te werken en hun wijzigingen samen te voegen in één vertakking met behulp van pull-aanvragen.
	Makers van inhoud kunnen inhoud vanuit de externe opslagplaats synchroniseren met behulp van Git-integratie. Ze kunnen ook inhoud implementeren met behulp van andere benaderingen, zoals Azure Pipelines, samen met de REST API's.
	In de werkruimte Fabric zien makers van inhoud de wijzigingen in Power BI-inhoud nadat de synchronisatie of implementatie is voltooid. Makers van inhoud kunnen inhoud maken, zoals gegevensstromen of notebooks in de werkruimte. Als ze Git-integratie gebruiken, koppelen makers van inhoud deze werkruimte aan een specifieke vertakking van de externe opslagplaats.
	Makers van inhoud kunnen wijzigingen van een werkruimte doorvoeren en pushen naar de externe opslagplaats met behulp van Git-integratie. Met deze wijzigingen kunnen itemdefinities worden geïmporteerd voor ondersteunde inhoud die is geschreven in de werkruimte, zoals gegevensstromen en notebooks.

Samengevat slaan makers van inhoud PBIP-bestanden, metagegevensbestanden en documentatie op in een centrale externe opslagplaats van 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 geavanceerdere opties voor het bijhouden en beheren van wijzigingen in vergelijking met SharePoint en OneDrive. Het onderhouden van een goed gecureerde, gedocumenteerde opslagplaats is essentieel omdat het de basis vormt van alle inhoud en samenwerking.

Overweeg om broncodebeheer te gebruiken om wijzigingen in de volgende scenario's bij te houden en te beheren:

• Gecentraliseerde of gedecentraliseerde teams maken en beheren de inhoud.
• Makers van inhoud werken samen met behulp van Azure DevOps.
• Makers van inhoud zijn bekend met Git, broncodebeheer of DataOps-principes.
• Makers van inhoud beheren complexe of belangrijke inhoud of verwachten dat de inhoud wordt geschaald en groter wordt in complexiteit en urgentie.

Hier volgen enkele vereisten en overwegingen waarmee u broncodebeheer effectief kunt gebruiken met Azure DevOps.

• Git: Als u wijzigingen wilt doorvoeren en pushen naar een externe opslagplaats, moeten makers van inhoud Git downloaden en installeren. Git is een gedistribueerd versiebeheersysteem waarmee wijzigingen in uw bestanden worden bijgehouden. Zie Wat is Git?voor meer informatie over de basisprincipes van Git.
• Hulpprogramma's: Voor het gebruik van Git moeten makers van inhoud een opdrachtregelinterface (CLI) of een GUI-client (grafische gebruikersinterface) gebruiken voor SCM, zoals Visual Studio of Visual Studio Code.
• Licenties en machtigingen: Als u een Git-opslagplaats voor Azure-opslagplaatsen wilt maken en gebruiken, moeten makers van inhoud het volgende hebben:
  • Toegangsniveau ingesteld op Basic (in tegenstelling tot Belanghebbende).
  • Behoort tot een organisatie en een project.
  • Juiste opslagplaatsmachtigingen.
• Infrastructuur git-integratie: inhoud synchroniseren in een externe opslagplaats met een Microsoft Fabric-werkruimte, maken makers van inhoud gebruik van Fabric Git-integratie. Dit is belangrijk voor het bijhouden en beheren van wijzigingen in inhoud die is gemaakt in de Fabric-portal, zoals gegevensstromen.

Tip

Voor het vergemakkelijken van broncodebeheer met lokale ontwikkeling raden we u aan een clienttoepassing zoals Visual Studio Code te gebruiken. U gebruikt Power BI Desktop om inhoud te ontwikkelen. Vervolgens kunt u Visual Studio Code gebruiken om broncodebeheer van die inhoud uit te voeren door wijzigingen in uw externe opslagplaats te faseren, doorvoeren en pushen.

Waarschuwing

Infrastructuur git-integratie heeft enkele beperkingen met de ondersteunde items en scenario's. Zorg ervoor dat u eerst controleert of De Git-integratie van Fabric het beste past bij uw specifieke scenario of dat u een andere benadering moet nemen om broncodebeheer te implementeren.

Daarnaast worden vertrouwelijkheidslabels niet ondersteund met Fabric Git-integratie en kunnen items met vertrouwelijkheidslabels worden uitgeschakeld. Als uw inhoud vertrouwelijkheidslabels bevat, moet u plannen hoe u versiebeheer kunt bereiken terwijl u nog steeds uw beleid voor preventie van gegevensverlies nakomt.

Een belangrijk voordeel van het gebruik van broncodebeheer met Azure-opslagplaatsen is een verbeterde samenwerking tussen makers van inhoud en meer aanpassing en toezicht op inhoudswijzigingen en -implementatie.

In het volgende diagram ziet u een algemeen overzicht van hoe Azure DevOps samenwerking met broncodebeheer mogelijk maakt.

Notitie

In het vorige diagram ziet u een voorbeeld van hoe u kunt samenwerken met behulp van Azure DevOps. Kies een aanpak die het beste past bij de behoeften en de manier van werken van uw team.

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.

In de volgende secties worden aanvullende overwegingen beschreven voor het effectief gebruik van broncodebeheer met behulp van Azure DevOps en Power BI.

Belangrijk

Effectief gebruik van vertakkingen, doorvoeringen, pull-aanvragen en samenvoegingen zijn essentieel om het meeste te profiteren van broncodebeheer wanneer u de levenscyclus van uw Power BI-inhoud beheert.

Vertakkingen gebruiken

Makers van inhoud kunnen samenwerken met behulp van een vertakkingsstrategie. Met een vertakkingsstrategie kunnen afzonderlijke makers van inhoud geïsoleerd werken 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 hun lokale oplossing en gepusht naar een versie van de vertakking in de externe opslagplaats met een beschrijvend doorvoerbericht. In een doorvoerbericht worden de wijzigingen beschreven die in die doorvoering zijn aangebracht.

Wanneer u een vertakkingsstrategie gebruikt om Fabric-inhoud te beheren, moet u rekening houden met de volgende factoren.

• Welke makers van vertakkingsinhoud moeten klonen voor hun eigen werk. Als deze vertakkingen bijvoorbeeld een kloon zijn van de hoofdbranch (ook wel trunk-ontwikkeling genoemd) of als het andere vertakkingen zijn, zoals releasebranches voor specifieke, geplande versies van inhoud.
• Of u specifiek werk wilt toepassen op afzonderlijke inhoudsreleases met behulp van releasebranches.
• Met welke vertakkingen verbinding wordt gemaakt met welke werkruimte u Git-integratie van Fabric gebruikt.

Tip

Zie Een Git-vertakkingsstrategie gebruiken voor specifieke richtlijnen en aanbevelingen over het beste gebruik van een vertakkingsstrategie om samenwerking effectief te vergemakkelijken.

Batchwijzigingen in doorvoeringen

Tijdens het ontwikkelen van inhoud moeten makers regelmatig wijzigingen in batches (of groepen) fasering geven. Deze wijzigingen moeten betrekking hebben op een specifiek werkitem voor de oplossing (zoals een functie of probleem). Wanneer ze klaar zijn, voeren makers van inhoud deze gefaseerde wijzigingen door.

Batchwijzigingen op deze manier hebben verschillende voordelen.

• Het helpt bij het structuren van de ontwikkeling en biedt makers van inhoud een kans om de wijzigingen die ze hebben gegroepeerd te bekijken en te documenteren.
• Het verbetert de afstemming tussen planning en ontwikkeling, waardoor het eenvoudiger is om functies en problemen te koppelen en transparantie te krijgen over hoe het werk doorgaat.
• Technische eigenaren kunnen pull-aanvragen van makers van inhoud eenvoudiger controleren als wijzigingen op de juiste wijze worden gebatcheerd en duidelijke doorvoerberichten hebben.

Houd rekening met de volgende factoren wanneer u wijzigingen in Power BI-inhoud faseren en doorvoert.

• Of u nu wijzigingen wilt faseren en doorvoeren vanuit een lokale opslagplaats of vanuit de Infrastructuurwerkruimte.
• Plaats PBIP-bestanden in mappen op het hoogste niveau wanneer u meerdere modellen of rapporten opslaat in één opslagplaats. Hierdoor kunt u gemakkelijker wijzigingen identificeren en groeperen die u aanbrengt.
• Negeer onschuldige of onhandige metagegevenswijzigingen met behulp van een gitignore-bestand of een .gitattributes-bestand. Dit zorgt ervoor dat alle wijzigingen die u doorvoert zinvol zijn.

Tip

Zie Uw werk opslaan met doorvoeringen voor specifieke richtlijnen en aanbevelingen over het faseren en doorvoeren van uw werk in een Git-opslagplaats.

Pull-aanvragen maken om wijzigingen samen te voegen

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.

Wanneer u pull-aanvragen gebruikt om wijzigingen in Power BI-inhoud samen te voegen, moet u rekening houden met de volgende factoren.

• Welke standaarden en procedures u gebruikt om uw beoordeling uit te voeren, indien van toepassing. U kunt bijvoorbeeld regels van Best Practice Analyzer gebruiken voor semantische modellen.
• Hoe u wijzigingen in rapportmetagegevens bekijkt, wat niet gemakkelijk te lezen en te begrijpen is zonder hulpprogramma's van derden te gebruiken.
• Hoe u samenvoegingsconflicten kunt oplossen en oplossen.

Tip

Zie Over pull-aanvragen en samenvoegstrategieën en samenvoeging voor specifieke richtlijnen en aanbevelingen over hoe u pull-aanvragen het beste kunt gebruiken om samenwerking te vergemakkelijken door wijzigingen in inhoud samen te voegen.

Controlelijst : wanneer u plant waar u bestanden opslaat, zijn belangrijke beslissingen en acties:

• Kies uw ontwikkelhulpprogramma's: Zorg ervoor dat uw benadering voor het ontwikkelen van inhoud overeenkomt met de manier waarop u samenwerkt met andere makers van inhoud en versiebeheer gebruikt.
• Kies tussen PBIP- en PBIX-indelingen voor modellen en rapporten: Meestal is de PBIP-indeling gunstiger voor broncodebeheer, maar selfservicegebruikers kunnen PBIX-bestanden gemakkelijker vinden.
• Afzonderlijke semantische modellen en rapportontwikkeling: Versiebeheer is het meest effectief wanneer u wijzigingen voor verschillende itemtypen afzonderlijk beheert. Het scheiden van model- en rapportontwikkeling wordt beschouwd als een goede gewoonte.
• Bepaal hoeveel werkruimten u nodig hebt: het gebruik van afzonderlijke omgevingen is essentieel voor het succes van het levenscyclusbeheer van inhoud. Zorg ervoor dat u hebt verduidelijkt hoeveel werkruimten u nodig hebt en voer de juiste planning op werkruimteniveau uit.
• Bepaal hoe u versiebeheer gaat implementeren: bepaal tussen een eenvoudigere benadering met SharePoint of OneDrive voor Bedrijven, of met behulp van Azure DevOps om broncodebeheer te vergemakkelijken.
• Uw externe opslagplaats instellen: Maak een gestructureerde ruimte in de OneDrive-map of Git-opslagplaats waar u inhoud opslaat om wijzigingen bij te houden en te beheren.
• Als u broncodebeheer gebruikt, stelt u .gitignore- en .gitattributes-bestanden in: Zorg ervoor dat u uw opslagplaats zo instelt dat u alleen zinvolle wijzigingen bijhoudt.
• Als u broncodebeheer gebruikt, definieert u vertakkings- en samenvoegstrategieën: Zorg ervoor dat u duidelijke processen definieert voor het instellen en gebruiken van broncodebeheer om de ontwikkeling het beste te ondersteunen. Vermijd het overcompliceren van uw proces. Probeer in plaats daarvan de huidige manier van werken in uw ontwikkelteams aan te vullen.

Gerelateerde inhoud

In het volgende artikel in deze reeks leert u hoe u inhoud kunt valideren als onderdeel van het beheren van de levenscyclus van inhoud.