Overzicht van Dataverse Git-integratie (preview)
[Dit artikel maakt deel uit van de voorlopige documentatie en kan nog veranderen.]
Dankzij integratie van broncodebeheer kunnen ontwikkelteams oplossingen en oplossingsobjecten synchroniseren in één of meerdere Microsoft Dataverse-omgevingen met behulp van een Azure DevOps Git-opslagplaats. De functionaliteit voor integratie van broncodebeheer is standaard beschikbaar binnen de oplossingen, zodat burgerontwikkelaars, code-first ontwikkelaars en beheerders kunnen profiteren van versiebeheer, wijzigingsregistratie en naadloze samenwerking tussen teams in verschillende tools en omgevingen. Git-integratie is bedoeld voor gebruik in ontwikkelomgevingen en niet in uw test- of productieomgevingen, waar implementaties kunnen worden uitgevoerd met behulp van builds om oplossingsartefacten en pijplijnen voor implementatie te maken.
Belangrijk
- Dit is een preview-functie.
- Preview-functies zijn niet bedoeld voor productiegebruik en bieden mogelijk beperkte functionaliteit. Deze functies zijn beschikbaar vóór een officiële release zodat klanten vroeg toegang kunnen krijgen en feedback kunnen geven.
- Deze functie is momenteel alleen beschikbaar voor omgevingen die zijn gemaakt voor vroege releasecycli in Australië, Canada en Europa. Ga naar Omgevingen voor vroege releasecyclus
In dit artikel vindt u enkele belangrijke concepten en voordelen van het gebruik van Git-broncodebeheer met uw Dataverse-omgevingen en oplossingen. Ga voor informatie over Git in Azure DevOps naar Azure DevOps Git-opslagplaats.
ALM in Power Platform en Dataverse
Power Platform biedt veel kant-en-klare functies waarmee organisaties Application Lifecycle Management (ALM) voor hun oplossingen kunnen beheren. Hieronder vallen de mogelijkheid om oplossingen te verpakken als containers voor de vele verschillende typen componenten op het platform, omgevingen te beheren die betrokken zijn bij de levenscyclus van de toepassing en oplossingen te implementeren met behulp van pijplijnen in Power Platform. Er zijn ook verschillende manieren om Git-opslagplaatsen te integreren met Power Platform met behulp van ontwikkelaarshulpmiddelen. Dankzij de native integratie van Git in Dataverse wordt het proces vereenvoudigd en gestroomlijnd, zodat makers op een vertrouwde manier met hun oplossingen kunnen werken en via vereenvoudigde interfaces in Power Apps (make.powerapps.com) met broncodebeheer kunnen communiceren.
Voordelen
- Broncodebeheer als bron van waarheid: binnen sommige organisaties is de bron van waarheid voor implementaties in Dataverse de makeromgevingen waarin oplossingen worden gebouwd. De belangrijkste reden voor dit gedrag is dat de niet-native Git-integratie geavanceerde technieken en hulpmiddelen gebruikt, waarvoor professionele IT-expertise nodig is om aan de slag te kunnen. Dankzij de native integratie van Git in Dataverse kan broncodebeheer in slechts een paar stappen worden ingeschakeld en krijgen makers een vertrouwde interface om met hun oplossingen te werken.
- Veiligheid, auditing en naleving met behulp van SDLC-best practices: Best practices voor de levenscyclus van softwareontwikkeling (SDLC) zijn een reeks richtlijnen en processen waarmee u uw softwareontwikkelingsprojecten effectief kunt beheren. Door Git-integratie in Dataverse te gebruiken, volgt u de SDLC-praktijken zoals versiebeheer, codebeoordelingen en statische broncodeanalyse om de kwaliteit, betrouwbaarheid en veiligheid van uw oplossingen te garanderen. Git-integratie in Dataverse biedt ook functies zoals auditing, naleving en traceerbaarheid waarmee u wijzigingen in uw oplossingen kunt bijhouden en effectief kunt samenwerken met andere teamleden.
- Kortdurende ontwikkelomgevingen: door een kopie van de aanpassingen en configuraties van uw omgevingen op te slaan in broncodebeheer, kunt u ontwikkelomgevingen snel en eenvoudig herstellen vanuit broncodebeheer in Dataverse. Hiermee kunt u kortdurende omgevingen creëren voor ontwikkelings- en testdoeleinden. Met kortdurende omgevingen kunt u opslagruimte vrijmaken, experimenteren met nieuwe functies, uw oplossingen testen en er iteraties op uitvoeren zonder dat u afhankelijk bent van permanente omgevingen.
- Fusion-ontwikkelingsteams: Fusion-ontwikkelingsteams zijn teams die bestaan uit zowel ontwikkelaars als makers die samenwerken om oplossingen te bouwen. Door Git-integratie in Dataverse te gebruiken, kunnen deze gebruikers onafhankelijk van elkaar in afzonderlijke omgevingen bouwen en met anderen samenwerken door te synchroniseren met een gemeenschappelijke opslagplaats voor broncodebeheer. Met integratie van broncodebeheer kunt u de vaardigheden en expertise van zowel ontwikkelaars als makers gebruiken om hoogwaardige oplossingen te bouwen die voldoen aan de behoeften van uw organisatie.
- Bescherming: Als u broncodebeheer gebruikt als bron van waarheid voor uw oplossingen, kunt u snel en eenvoudig herstellen van onbedoelde wijzigingen in uw oplossingen. Door uw oplossingen in broncodebeheer op te slaan, kunt u ze terugzetten naar een eerdere status of versie.
Belangrijke concepten
Onbeheerde versus beheerde oplossingen
Wanneer u Git-integratie met Dataverse gebruikt, komen de oplossingen die in broncodebeheer zijn opgeslagen, uit onbeheerde oplossingen in de omgeving van een maker. Met onbeheerde oplossingen kunnen makers onderdelen toevoegen, verwijderen en bijwerken die gesynchroniseerd zijn met broncodebeheer wanneer u doorvoert. Beheerde oplossingen worden gebouwd op basis van broncodebeheer en geïmplementeerd in downstreamomgevingen, zoals test of productie, en kunnen in die omgevingen niet worden bewerkt. Beheerde oplossingen worden gebruikt om ervoor te zorgen dat de bron van de waarheid voor uw oplossingen altijd broncodebeheer is en dat wijzigingen alleen in de omgeving van een maker worden doorgevoerd voordat ze aan broncodebeheer worden toegevoegd en elders worden geïmplementeerd.
Bestandsopmaak voor oplossingsonderdelen
Met de introductie van Git-integratie in Dataverse zijn er wijzigingen in de manier waarop oplossingen en oplossingsonderdelen worden weergegeven in broncodebeheer. Wanneer u wijzigingen doorvoert naar broncodebeheer, worden de onderdelen van de oplossing opgeslagen in een specifieke indeling die compatibel is met Git. Deze indeling wordt gebruikt om de oplossingsonderdelen op een leesbare en begrijpelijke manier weer te geven. Bovendien kunt u hiermee wijzigingen in de oplossingsonderdelen in de loop van de tijd bijhouden. De bestandsindeling voor oplossingsonderdelen is ontworpen om leesbaar te zijn voor mensen en kan worden gebruikt om wijzigingen in de oplossingsonderdelen in broncodebeheer te bekijken. Bovendien worden de oplossingscomponenten in versiebeheer niet langer voor elke oplossing gedupliceerd, zodat meerdere oplossingen in dezelfde opslagplaats en map kunnen worden opgeslagen. In plaats daarvan worden de oplossingsonderdelen op één locatie opgeslagen en kunnen ze worden gedeeld met meerdere oplossingen in dezelfde opslagplaats en map.
Code-first ontwikkeling met Git
Code-first ontwikkeling in het Power Platform wordt mogelijk gemaakt door ontwikkelingshulpmiddelen zoals de Power Platform CLI, Visual Studio en Visual Studio Code-extensies. Het betrekken van code-first ontwikkelaars bij het proces van oplossingsontwikkeling is lastig zonder integratie van broncodebeheer, omdat onderdelen zoals Power Apps Component Framework en Dataverse-invoegtoepassingen worden geïmplementeerd in oplossingen als verpakte assets die zijn opgebouwd uit broncode en niet rechtstreeks kunnen worden bewerkt in Power Apps (make.powerapps.com). Zonder broncodebeheer als onderdeel van het ontwikkelingsproces voor zowel onderdelen met weinig code of code-first onderdelen, is het lastig om wijzigingen in de oplossing te beheren en ervoor te zorgen dat wijzigingen op een gecontroleerde manier worden bijgehouden en geïmplementeerd.
Door Git-integratie in Dataverse in te schakelen, kunt u tegemoetkomen aan de behoeften van code-first ontwikkelaars en een naadloze ervaring bieden voor zowel low-code- als code-first-ontwikkelaars. Er zijn echter een aantal overwegingen waarmee u rekening moet houden bij het beheren van code-first onderdelen in een omgeving met weinig code.
Fusion-ontwikkeling met Dataverse Git-integratie
Power Platform biedt mogelijkheden voor zowel low-code als code-first ontwikkeling. In dit artikel worden code-first ontwikkelingsprocessen besproken die verband houden met Dataverse en Git-integratie. Ook vindt u richtlijnen voor het beheren van code-first- en low-code-componenten in één omgeving. Onderdelen zoals Power Apps Component Framework-besturingselementen, Dataverse-invoegtoepassingen en aangepaste werkstroomactiviteiten zijn voorbeelden van code-first onderdelen die in broncodebeheer kunnen worden beheerd.
Code-first onderdelen en onderdelen met weinig code in één omgeving
Code-first onderdelen kunnen in oplossingen worden opgenomen via een bouwproces dat een beheerde of onbeheerde oplossing genereert die in een Dataverse-omgeving kan worden geïmporteerd. Code-first onderdelen kunnen echter ook direct in een onbeheerde oplossing in een makersomgeving worden geïmplementeerd zodra ze zijn gebouwd, zonder dat het oplossingsbouwproces hoeft te worden gebruikt om ze te implementeren. Gezien deze flexibiliteit moet u rekening houden met het bouwproces.
Als u code-first onderdelen rechtstreeks implementeert in een onbeheerde oplossing in een makeromgeving, en deze onderdelen worden vastgelegd in broncodebeheer, wordt alleen de gecompileerde (gebouwde) versie ervan opgeslagen in broncodebeheer. Bijvoorbeeld de binaire DLL als invoegtoepassing, of de getranspileerde en geoptimaliseerde bundel JavaScript voor een Power Apps Component Framework-besturingselement. Het resultaat is dat u twee kopieën van het onderdeel in broncodebeheer krijgt: één die wordt vertegenwoordigd door de gebouwde versie en de andere die wordt vertegenwoordigd door de broncode. Het opslaan van binaire bestanden in uw opslagplaats kan leiden tot verwarring en mogelijke conflicten als de broncode en de gebouwde versie niet synchroon worden gehouden. Deze praktijk wordt niet aanbevolen omdat de broncode de enige bron van waarheid voor het onderdeel zou moeten zijn en er slechts één kopie zou moeten worden opgeslagen.
De aanbevolen aanpak is om code-first-onderdelen te bouwen als onderdeel van een oplossingsbouwproces en de gegenereerde, onbeheerde oplossing te importeren in de makersomgeving. Deze aanpak zorgt ervoor dat de broncode en de gebouwde versie synchroon blijven en dat de broncode de enige bron van waarheid is voor het onderdeel. Voor deze aanpak is echter wel een bouwproces nodig om de beheerde of onbeheerde oplossing te genereren voor gebruik in het import- en implementatieproces. U kunt bijvoorbeeld Azure Pipelines of GitHub-werkstromen maken die artefacten voor pijplijnen in Power Platform maken en voor de Git-synchronisatieprocessen om te consumeren.