Aanbevolen procedures voor levenscyclusbeheer
Dit artikel bevat richtlijnen voor makers van gegevens en analyses die hun inhoud gedurende de gehele levenscyclus in Microsoft Fabric beheren. Het artikel richt zich op het gebruik van Git-integratie voor broncodebeheer en implementatiepijplijnen als een releasehulpprogramma. Voor algemene richtlijnen voor het publiceren van enterprise-inhoud, enterprise-inhoud publiceren.
Belangrijk
Deze functie is beschikbaar als preview-versie.
Het artikel is onderverdeeld in vier secties:
Inhoudsvoorbereiding : bereid uw inhoud voor op levenscyclusbeheer.
Ontwikkeling : meer informatie over de beste manieren om inhoud te maken in de ontwikkelingsfase van implementatiepijplijnen.
Test - Inzicht in het gebruik van een testfase voor implementatiepijplijnen om uw omgeving te testen.
Productie : gebruik een productiefase voor implementatiepijplijnen om uw inhoud beschikbaar te maken voor gebruik.
Inhoudsvoorbereiding
Bekijk de informatie in deze sectie voordat u uw inhoud het beste voorbereidt op continu beheer gedurende de gehele levenscyclus:
Inhoud vrijgeven aan productie.
Begin met het gebruik van een implementatiepijplijn voor een specifieke werkruimte.
Ontwikkeling tussen teams scheiden
Verschillende teams in de organisatie hebben meestal verschillende expertise, eigendom en werkmethoden, zelfs wanneer ze aan hetzelfde project werken. Het is belangrijk om grenzen in te stellen en elk team hun onafhankelijkheid te geven om te werken zoals ze willen. Overweeg afzonderlijke werkruimten te hebben voor verschillende teams. Met afzonderlijke werkruimten kan elk team verschillende machtigingen hebben, werken met verschillende opslagplaatsen voor broncodebeheer en inhoud verzenden naar productie in een andere frequentie. De meeste items kunnen verbinding maken met en gegevens gebruiken in werkruimten, zodat samenwerking op dezelfde gegevens en hetzelfde project niet wordt geblokkeerd.
Uw machtigingsmodel plannen
Voor zowel Git-integratie- als implementatiepijplijnen zijn andere machtigingen vereist dan alleen de werkruimtemachtigingen. Lees meer over de machtigingsvereisten voor Git-integratie- en implementatiepijplijnen.
Als u een veilige en eenvoudige werkstroom wilt implementeren, moet u plannen wie toegang krijgt tot elk deel van de omgevingen die worden gebruikt, zowel de Git-opslagplaats als de fasen dev/test/prod in een pijplijn. Enkele van de overwegingen waarmee u rekening moet houden, zijn:
Wie moet toegang hebben tot de broncode in de Git-opslagplaats?
Welke bewerkingen moeten gebruikers met pijplijntoegang in elke fase kunnen uitvoeren?
Wie inhoud bekijkt in de testfase?
Moeten de revisoren van de testfase toegang hebben tot de pijplijn?
Wie moet toezicht houden op de implementatie in de productiefase?
Welke werkruimte wijst u toe aan een pijplijn of maakt u verbinding met Git?
Met welke vertakking verbindt u de werkruimte? Wat is het beleid dat is gedefinieerd voor die vertakking?
Wordt de werkruimte gedeeld door meerdere teamleden? Moeten ze rechtstreeks wijzigingen aanbrengen in de werkruimte of alleen via pull-aanvragen?
Aan welke fase wijst u uw werkruimte toe?
Moet u wijzigingen aanbrengen in de machtigingen van de werkruimte die u toewijst?
Verbinding maken verschillende fasen voor verschillende databases
Een productiedatabase moet altijd stabiel en beschikbaar zijn. Het is raadzaam deze niet te overbelasten met query's die zijn gegenereerd door BI-makers voor hun ontwikkeling of het testen van semantische modellen. Bouw afzonderlijke databases voor ontwikkeling en testen om productiegegevens te beveiligen en de ontwikkelingsdatabase niet te overbelasten met het volledige volume aan productiegegevens.
Parameters gebruiken voor configuraties die tussen fasen veranderen
Voeg waar mogelijk parameters toe aan elke definitie die kan veranderen tussen dev/test/prod-fasen. Met behulp van parameters kunt u de definities eenvoudig wijzigen wanneer u uw wijzigingen naar productie verplaatst. Hoewel er nog steeds geen uniforme manier is om parameters in Fabric te beheren, raden we u aan deze te gebruiken voor items die ondersteuning bieden voor elk type parameterisatie.
Parameters hebben verschillende toepassingen, zoals het definiëren van verbindingen met gegevensbronnen of met interne items in Fabric. Ze kunnen ook worden gebruikt om wijzigingen aan te brengen in query's, filters en de tekst die voor gebruikers wordt weergegeven.
In implementatiepijplijnen kunt u parameterregels configureren om verschillende waarden in te stellen voor elke implementatiefase.
Ontwikkeling
Deze sectie bevat richtlijnen voor het werken met de implementatiepijplijnen en het gebruik van de vereisten voor uw ontwikkelfase.
Een back-up maken van uw werk in een Git-opslagplaats
Met Git-integratie kan elke ontwikkelaar een back-up van hun werk maken door het door te voeren in Git. Hier volgen enkele basisregels om een back-up te maken van uw werk in Fabric:
Zorg ervoor dat u een geïsoleerde omgeving hebt waarin u kunt werken, zodat anderen uw werk niet overschrijven voordat deze wordt doorgevoerd. Dit betekent dat u werkt in een bureaubladprogramma (zoals VS Code, Power BI Desktop of anderen) of in een afzonderlijke werkruimte waartoe andere gebruikers geen toegang hebben.
Voer een door u gemaakte vertakking door en er wordt geen andere ontwikkelaar gebruikt. Als u een werkruimte als ontwerpomgeving gebruikt, leest u meer over het werken met vertakkingen.
Wijzigingen doorvoeren die samen moeten worden geïmplementeerd. Dit advies is van toepassing op één item of meerdere items die zijn gerelateerd aan dezelfde wijziging. Het doorvoeren van alle gerelateerde wijzigingen kan u later helpen bij het implementeren naar andere fasen, het maken van pull-aanvragen of het terugdraaien van wijzigingen.
Grote doorvoeringen kunnen een maximale doorvoergroottelimiet bereiken. Houd rekening met het aantal items dat u samen doorvoert of de algemene grootte van een item. Rapporten kunnen bijvoorbeeld groot worden bij het toevoegen van grote afbeeldingen. Het is slecht om grote items op te slaan in broncodebeheersystemen, zelfs als het werkt. Overweeg manieren om de grootte van uw items te verkleinen als ze veel statische resources hebben, zoals afbeeldingen.
Wijzigingen terugdraaien
Nadat u een back-up van uw werk hebt gemaakt, zijn er mogelijk gevallen waarin u wilt terugkeren naar een eerdere versie en deze in de werkruimte wilt herstellen. Er zijn een aantal manieren om terug te keren naar een eerdere versie:
Knop Ongedaan maken: de bewerking Ongedaan maken is een eenvoudige en snelle manier om de directe wijzigingen terug te zetten die u hebt aangebracht, zolang ze nog niet zijn doorgevoerd. U kunt elk item ook afzonderlijk ongedaan maken. Lees meer over de bewerking ongedaan maken .
Terugkeren naar oudere doorvoeringen: er is geen directe manier om terug te gaan naar een vorige doorvoering in de gebruikersinterface. De beste optie is om een oudere doorvoering te promoten als head met behulp van git revert of git reset. Als u dit doet, ziet u dat er een update is in het deelvenster broncodebeheer en dat u de werkruimte kunt bijwerken met die nieuwe doorvoering.
Omdat gegevens niet zijn opgeslagen in Git, moet u er rekening mee houden dat het terugzetten van een gegevensitem naar een oudere versie de bestaande gegevens kan verbreken en dat u de gegevens mogelijk moet verwijderen of dat de bewerking kan mislukken. Controleer dit vooraf voordat u de wijzigingen terugdraait.
Werken met een privéwerkruimte
Als u geïsoleerd wilt werken, gebruikt u een afzonderlijke werkruimte als een geïsoleerde omgeving. Lees meer over het isoleren van uw werkomgeving in het werken met vertakkingen. Houd rekening met de volgende punten voor een optimale werkstroom voor u en het team:
De werkruimte instellen: voordat u begint, moet u ervoor zorgen dat u een nieuwe werkruimte kunt maken (als u er nog geen hebt), dat u deze kunt toewijzen aan een Infrastructuurcapaciteit en dat u toegang hebt tot gegevens om in uw werkruimte te werken.
Een nieuwe vertakking maken: maak een nieuwe vertakking vanuit de hoofdvertakking, zodat u de meest recente versie van uw inhoud hebt. Zorg er ook voor dat u verbinding maakt met de juiste map in de vertakking, zodat u de juiste inhoud in de werkruimte kunt ophalen.
Kleine, frequente wijzigingen: het is een best practice voor Git om kleine incrementele wijzigingen aan te brengen die eenvoudig kunnen worden samengevoegd en minder waarschijnlijk conflicten ondervinden. Als dat niet mogelijk is, moet u ervoor zorgen dat u uw vertakking bijwerkt van de hoofdserver, zodat u eerst conflicten zelf kunt oplossen.
Configuratiewijzigingen: wijzig indien nodig de configuraties in uw werkruimte zodat u productiever kunt werken. Sommige wijzigingen kunnen betrekking hebben op de verbinding tussen items of op verschillende gegevensbronnen of wijzigingen in parameters voor een bepaald item. Vergeet niet dat alles wat u doorvoert deel uitmaakt van de doorvoering en per ongeluk kan worden samengevoegd in de hoofdbranch.
Clienthulpprogramma's gebruiken om uw werk te bewerken
Voor items en hulpprogramma's die dit ondersteunen, is het misschien eenvoudiger om te werken met clienthulpprogramma's voor creatie, zoals Power BI Desktop voor semantische modellen en rapporten, VSCode voor notebooks, enzovoort. Deze hulpprogramma's kunnen uw lokale ontwikkelomgeving zijn. Nadat u uw werk hebt voltooid, pusht u de wijzigingen naar de externe opslagplaats en synchroniseert u de werkruimte om de wijzigingen te uploaden. Zorg ervoor dat u werkt met de ondersteunde structuur van het item dat u ontwerpt. Als u het niet zeker weet, kloont u eerst een opslagplaats met inhoud die al is gesynchroniseerd met een werkruimte en begint u daar met ontwerpen, waar de structuur al aanwezig is.
Werkruimten en vertakkingen beheren
Omdat een werkruimte slechts met één vertakking tegelijk kan worden verbonden, is het raadzaam om deze te behandelen als een toewijzing van 1:1. Houd echter rekening met de volgende opties om de hoeveelheid werkruimte te verminderen die het met zich meebrengt:
Als een ontwikkelaar een privéwerkruimte met alle vereiste configuraties instelt, kan deze die werkruimte blijven gebruiken voor toekomstige vertakkingen die ze maken. Wanneer een sprint voorbij is, worden uw wijzigingen samengevoegd en start u een nieuwe taak. U hoeft alleen de verbinding over te schakelen naar een nieuwe vertakking in dezelfde werkruimte. U kunt dit ook doen als u plotseling een bug in het midden van een sprint moet oplossen. U kunt het beschouwen als een werkmap op internet.
Ontwikkelaars die een clienthulpprogramma gebruiken (zoals VS Code, Power BI Desktop of andere), hebben niet noodzakelijkerwijs een werkruimte nodig. Ze kunnen vertakkingen maken en wijzigingen in die vertakking lokaal doorvoeren, die naar de externe opslagplaats pushen en een pull-aanvraag maken naar de hoofdvertakking, allemaal zonder werkruimte. Een werkruimte is alleen nodig als testomgeving om te controleren of alles in een praktijkscenario werkt. Het is aan u om te beslissen wanneer dat moet gebeuren.
Een item dupliceren in een Git-opslagplaats
Een item in een Git-opslagplaats dupliceren:
- Kopieer de hele itemmap.
- Wijzig de logicalId in iets unieks voor die verbonden werkruimte.
- Wijzig de weergavenaam om deze te onderscheiden van het oorspronkelijke item en om dubbele weergavenaamfouten te voorkomen.
- Werk indien nodig de logicalId en/of weergavenamen bij in afhankelijkheden.
Testen
Deze sectie bevat richtlijnen voor het werken met een testfase voor implementatiepijplijnen.
Uw productieomgeving simuleren
Het is belangrijk om te zien hoe uw voorgestelde wijziging van invloed is op de productiefase. Met een testfase voor implementatiepijplijnen kunt u een echte productieomgeving simuleren voor testdoeleinden. U kunt dit ook simuleren door Git te verbinden met een andere werkruimte.
Zorg ervoor dat deze drie factoren in uw testomgeving worden aangepakt:
Gegevensvolume
Gebruiksvolume
Een vergelijkbare capaciteit als in productie
Bij het testen kunt u dezelfde capaciteit gebruiken als de productiefase. Als u dezelfde capaciteit gebruikt, kan de productie echter instabiel worden tijdens het testen van de belasting. Om instabiele productie te voorkomen, test u het gebruik van een andere capaciteit die vergelijkbaar is met resources in de productiecapaciteit. Als u extra kosten wilt voorkomen, gebruikt u een capaciteit waar u alleen voor de testtijd kunt betalen.
Implementatieregels gebruiken met een echte gegevensbron
Als u de testfase gebruikt om het werkelijke gegevensgebruik te simuleren, kunt u het beste de ontwikkelings- en testgegevensbronnen scheiden. De ontwikkelingsdatabase moet relatief klein zijn en de testdatabase moet zo vergelijkbaar mogelijk zijn met de productiedatabase. Gebruik regels voor gegevensbronnen om te schakelen tussen gegevensbronnen in de testfase of om de verbinding te parameteriseren als deze niet werkt via implementatiepijplijnen.
Gerelateerde items controleren
Wijzigingen die u aanbrengt, kunnen ook van invloed zijn op de afhankelijke items. Controleer tijdens het testen of uw wijzigingen niet van invloed zijn op de prestaties van bestaande items, die afhankelijk kunnen zijn van de bijgewerkte items.
U kunt de gerelateerde items eenvoudig vinden met behulp van impactanalyse.
Gegevensitems bijwerken
Gegevensitems zijn items die gegevens opslaan. De definitie van het item in Git bepaalt hoe de gegevens worden opgeslagen. Wanneer u een item in de werkruimte bijwerkt, importeren we de definitie ervan in de werkruimte en passen we dit toe op de bestaande gegevens. De werking van het bijwerken van gegevensitems is hetzelfde voor Git- en implementatiepijplijnen.
Aangezien verschillende items verschillende mogelijkheden hebben bij het behouden van gegevens wanneer wijzigingen in de definitie worden toegepast, moet u rekening houden met het toepassen van de wijzigingen. Enkele procedures waarmee u de wijzigingen op de veiligste manier kunt toepassen:
Weet van tevoren wat de wijzigingen zijn en wat hun invloed kan zijn op de bestaande gegevens. Gebruik doorvoerberichten om de aangebrachte wijzigingen te beschrijven.
Als u wilt zien hoe dat item de wijziging verwerkt met testgegevens, uploadt u eerst de wijzigingen naar een ontwikkel- of testomgeving.
Als alles goed gaat, is het raadzaam om het ook te controleren op een faseringsomgeving, met echte gegevens (of zo dicht mogelijk bij het proces), om het onverwachte gedrag in de productie te minimaliseren.
Houd rekening met de beste timing bij het bijwerken van de Prod-omgeving om de schade te minimaliseren die fouten kunnen veroorzaken voor uw zakelijke gebruikers die de gegevens gebruiken.
Na de implementatie worden tests na de implementatie in Prod uitgevoerd om te controleren of alles werkt zoals verwacht.
Sommige wijzigingen worden altijd beschouwd als belangrijke wijzigingen. Hopelijk helpen de voorgaande stappen u deze bij te houden vóór de productie. Bouw een plan voor het toepassen van de wijzigingen in Prod en herstel de gegevens om terug te keren naar de normale status en downtime voor zakelijke gebruikers te minimaliseren.
Uw app testen
Als u inhoud distribueert naar uw klanten via een app, controleert u de nieuwe versie van de app voordat deze in productie is. Aangezien elke implementatiepijplijnfase een eigen werkruimte heeft, kunt u eenvoudig apps publiceren en bijwerken voor ontwikkelings- en testfasen. Door apps te publiceren en bij te werken, kunt u de app testen vanuit het oogpunt van een eindgebruiker.
Belangrijk
Het implementatieproces omvat niet het bijwerken van de app-inhoud of -instellingen. Als u wijzigingen wilt toepassen op inhoud of instellingen, werkt u de app handmatig bij in de vereiste pijplijnfase.
Productie
Deze sectie bevat richtlijnen voor de productiefase van implementatiepijplijnen.
Beheren wie kan implementeren in productie
Omdat de implementatie in productie zorgvuldig moet worden afgehandeld, is het raadzaam om alleen specifieke personen deze gevoelige bewerking te laten beheren. U wilt echter waarschijnlijk dat alle BI-makers voor een specifieke werkruimte toegang hebben tot de pijplijn. Gebruik machtigingen voor een productiewerkruimte om toegangsmachtigingen te beheren. Andere gebruikers kunnen een rol van viewer voor een productiewerkruimte hebben om inhoud in de werkruimte te bekijken, maar geen wijzigingen aan te brengen vanuit Git- of implementatiepijplijnen.
Beperk bovendien de toegang tot de opslagplaats of pijplijn door alleen machtigingen in te schakelen voor gebruikers die deel uitmaken van het proces voor het maken van inhoud.
Regels instellen om de beschikbaarheid van productiefasen te garanderen
Implementatieregels zijn een krachtige manier om ervoor te zorgen dat de gegevens in productie altijd zijn verbonden en beschikbaar zijn voor gebruikers. Wanneer implementatieregels zijn toegepast, kunnen implementaties worden uitgevoerd terwijl u de zekerheid hebt dat klanten de relevante informatie zonder verstoring kunnen zien.
Zorg ervoor dat u regels voor productie-implementatie instelt voor gegevensbronnen en parameters die zijn gedefinieerd in het semantische model.
De productie-app bijwerken
Implementatie in een pijplijn via de gebruikersinterface werkt de inhoud van de werkruimte bij. Als u de bijbehorende app wilt bijwerken, gebruikt u de API voor implementatiepijplijnen. Het is niet mogelijk om de app bij te werken via de gebruikersinterface. Als u een app gebruikt voor inhoudsdistributie, vergeet dan niet om de app bij te werken na de implementatie in productie, zodat eindgebruikers onmiddellijk de nieuwste versie kunnen gebruiken.
Implementeren in productie met behulp van Git-vertakkingen
Als de opslagplaats fungeert als de 'single-source-of-truth', willen sommige teams mogelijk updates rechtstreeks vanuit Git implementeren in verschillende fasen. Dit is mogelijk met Git-integratie, met enkele overwegingen:
We raden u aan release-vertakkingen te gebruiken. Voor elke implementatie moet u de verbinding van de werkruimte met de nieuwe release-vertakkingen continu wijzigen.
Als u voor uw build- of release-pijplijn de broncode moet wijzigen of scripts moet uitvoeren in een buildomgeving voordat de implementatie naar de werkruimte wordt uitgevoerd, helpt het verbinden van de werkruimte met Git u niet.
Nadat u de implementatie in elke fase hebt uitgevoerd, moet u alle configuraties wijzigen die specifiek zijn voor die fase.
Snelle oplossingen voor inhoud
Soms zijn er problemen in productie waarvoor een snelle oplossing is vereist. Het implementeren van een oplossing zonder eerst te testen, is een slechte gewoonte. Implementeer daarom altijd de oplossing in de ontwikkelingsfase en push deze naar de rest van de implementatiepijplijnfasen. Als u implementeert in de ontwikkelingsfase, kunt u controleren of de oplossing werkt voordat deze in productie wordt geïmplementeerd. Het implementeren in de pijplijn duurt slechts enkele minuten.
Als u implementatie van Git gebruikt, raden we u aan de procedures te volgen die worden beschreven in Een Git-vertakkingsstrategie aannemen.
Gerelateerde inhoud
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor