Delen via

Uw oplossingen ordenen

Voordat u oplossingen maakt, moet u enige tijd nemen om uw omgevingsstrategie en uw oplossingsstrategie vooruit te plannen. Houd rekening met de volgende aspecten:

Aspect Overweging
Toepassingsbereik Omvat uw implementatie meerdere toepassingen, zoals Verkoop, Klantenservice, Field Service, Finance, enzovoort?
Uitgiftefrequentie Hoe vaak wilt u updates implementeren in productie?
Is uw leveringsmethodologie gebaseerd op agile-procedures zoals sprintcycli?
Productieondersteuning Hoe kunt u urgente oplossingen in productie afhandelen zonder dat u voortijdig nieuwe functies introduceert?
Oplossingsarchitectuur Hoeveel oplossingen beheert u?
Delen deze oplossingen onderdelen of zijn ze afhankelijk van elkaar?
Omgevingsplanning Hoeveel Microsoft Dataverse-omgevingen moet u uw ontwikkelingslevenscyclus ondersteunen?
Hebt u afzonderlijke omgevingen nodig voor ontwikkeling, testen en productie?
Werken ontwikkelaars gezamenlijk in een gedeelde omgeving of moeten geïsoleerde omgevingen onafhankelijk werken?

In de volgende secties worden drie strategieën beschreven, gerangschikt van het eenvoudigste tot het meest complexe, en worden hun respectieve voor- en nadelen gemarkeerd.

Strategie voor één oplossing

Alle aanpassingen worden tijdens de ontwikkeling gegroepeerd in één onbeheerde oplossing, die later wordt geëxporteerd als één beheerde oplossing voor implementatie.

Aanbevolen voor:

  • Klein- tot middelgrote implementaties
  • Scenario's waarbij toekomstige modularisatie onwaarschijnlijk is
Voordeel Nadeel
Vereenvoudigde omgevingsinstellingen en -beheer. Vereist meer inspanning om later te schalen of te modulariseren, indien nodig.
Vereenvoudigde implementatie. Met slechts één oplossing voor het beheren, exporteren en importeren in omgevingen is eenvoudig en minder foutgevoelig. Eén oplossing met een groot aantal aanpassingen kan leiden tot langere implementatietijden. Als u de oplossingsgrootte wilt verkleinen, gebruikt u tabelsegmentatie. Als u de importtijden wilt verminderen, gaat u naar aanbevelingen voor prestaties.
Eenvoudiger om wijzigingen te vinden, te controleren en te beheren. Wanneer meerdere ontwikkelaars in dezelfde ontwikkelomgeving werken, riskeren ze elkaars wijzigingen te overschrijven. Dit risico kan worden verminderd door broncodeversiebeheer te implementeren, een vertakkingsstrategie te gebruiken en een toegewezen ontwikkelomgeving te gebruiken voor elke vertakking. Broncodeversiebeheer en vertakkingsstrategie bieden mechanismen voor het bijhouden van wijzigingen, samenwerking en conflictoplossing. Meer informatie: Een Git-vertakkingsstrategie aannemen.

Opmerking

Recente verbeteringen in Microsoft Power Platform hebben lagere importtijden voor beheerde oplossingen, waaronder oplossingen die gebruikmaken van de upgradeoptie. Deze optimalisaties omvatten een betere verwerking van onderdeelafhankelijkheden en verminderde overhead voor ongewijzigde onderdelen. Als u wilt weten hoe u van deze verbeteringen kunt profiteren, gaat u naar aanbevelingen voor prestaties.

Meerdere oplossingen in dezelfde ontwikkelomgeving

Er worden meerdere onbeheerde oplossingen onderhouden binnen één ontwikkelomgeving, die doorgaans worden toegewezen aan niet-gerelateerde functies of modules.

Aanbevolen voor:

  • Kleinschalige implementaties met afzonderlijke en onafhankelijke functionele gebieden die geen onderdelen delen.
Voordeel Nadeel
Vereenvoudigde omgevingsinstellingen en -beheer. Het onderhouden van meerdere onbeheerde oplossingen binnen dezelfde ontwikkelomgeving verhoogt de kans op afhankelijkheidsconflicten. U kunt bijvoorbeeld een situatie tegenkomen waarbij oplossing A niet kan worden geïmporteerd omdat deze afhankelijk is van oplossing B, terwijl oplossing B niet kan worden geïmporteerd omdat deze afhankelijk is van oplossing A.
Functionele gebieden kunnen onafhankelijk van elkaar worden geïmplementeerd. Meerdere ontwikkelaars die aan dezelfde ontwikkelomgeving werken, kunnen elkaars wijzigingen overschrijven. Werken in een onbeheerde oplossing biedt geen isolatie. Elke wijziging wordt rechtstreeks toegepast op de omgeving, ongeacht welke oplossing wordt bewerkt.

Opmerking

Wanneer u meerdere oplossingen in dezelfde ontwikkelomgeving hebt, maakt u na het importeren van de beheerde oplossingen in uw doelomgeving vaak lagen. Meer informatie: Oplossingslagen en samenvoeggedrag

Het is belangrijk dat u:

  • Neem niet hetzelfde onbeheerde onderdeel op in meer dan één oplossing.
  • U hebt slechts één oplossing die al uw tabellen bevat. Er zijn geen twee verschillende oplossingen waarbij beide tabellen bevatten. Dit komt omdat er vaak risico's van een enkele relatie tussen tabellen bestaan, wat tot afhankelijkheid tussen verschillende oplossingen leidt en op een later tijdstip problemen met het upgraden of verwijderen van de oplossing in de doelomgeving veroorzaakt.
  • Gebruik slechts één oplossingsuitgever. De uitgever van de oplossing is eigenaar van de onderdelen van een beheerde oplossing en de bijbehorende koppeling kan later niet meer worden gewijzigd. Als een aangepaste tabel bijvoorbeeld wordt geïmporteerd als beheerd via Oplossing A met Publisher X, kunt u deze tabel later niet verplaatsen naar Oplossing B met Publisher Y. De enige optie is om de tabel te verwijderen, Oplossing A bij te werken om de tabel uit het doelsysteem te verwijderen en vervolgens de tabel opnieuw te maken in Oplossing B met Publisher Y en Oplossing B te importeren. Dit proces leidt tot verlies van alle gegevens die zijn opgeslagen in de aangepaste tabel, tenzij deze vooraf worden gemigreerd.
  • Vermijd het maken van afhankelijkheden tussen oplossingen. Afhankelijkheden dwingen een importorder af en kunnen problemen veroorzaken. Als u bijvoorbeeld één oplossing voor tabellen en een andere voor cloudstromen hebt en een stroom afhankelijk is van een aangepaste kolom, werkt deze in ontwikkeling omdat de kolom bestaat. Als echter alleen de cloudstroomoplossing wordt geïmporteerd in de doelomgeving, herkent het importproces de afhankelijkheid van de aangepaste kolom mogelijk niet. Als gevolg hiervan wordt de workflow-oplossing succesvol geïnstalleerd, maar de workflow zelf werkt niet. Meer informatie: Voorbeelden van afhankelijkheden die door meerdere oplossingen zijn gemaakt

Voorbeelden van afhankelijkheden die zijn gemaakt door meerdere oplossingen

  • Toepassingslinten. Wanneer meerdere oplossingen het toepassingslint of het siteoverzicht van dezelfde app wijzigen.
  • Invoegtoepassingen of cloudstromen. Als de invoegtoepassing of stroom wordt geactiveerd in een aangepaste kolom of een aangepaste tabel bijwerkt, is het object afhankelijk van die aangepaste tabellen.
  • Beveiligingsrollen. Wanneer er aangepaste tabellen bestaan, zijn beveiligingsrollen doorgaans afhankelijk van die tabellen voor gebruikerstoegang.

Meerdere oplossingen met toegewezen ontwikkelomgevingen

Deze strategie omvat het ontwikkelen van elke onbeheerde oplossing in een eigen geïsoleerde Dataverse-ontwikkelomgeving. Deze strategie wordt vaak gebruikt in modulaire architecturen, waarbij bijvoorbeeld verschillende toepassingen, zoals Verkoop, Klantenservice of Field Service, onafhankelijk van elkaar worden gebouwd en onderhouden. Een basisoplossing met algemene onderdelen (bijvoorbeeld account- en contacttabellen) wordt gemaakt en geïmplementeerd als een beheerde oplossing in elke app-specifieke ontwikkelomgeving. Elke app heeft vervolgens een eigen onbeheerde oplossing, gelaagd boven op de beheerde basisoplossing, zodat teams functionaliteit kunnen uitbreiden zonder de basisbasis te wijzigen.

Aanbevolen voor:

  • Grootschalige ondernemingsprojecten.
  • Teams met meerdere ontwikkelaars of partners
  • Scenario's waarvoor strikte governance- en CI/CD-pijplijnen zijn vereist.
Voordeel Nadeel
Eenvoudiger om uw systeem te laten groeien en ontwikkelen door modules toe te voegen of bij te werken zonder dat dit van invloed is op anderen. Hogere infrastructuur- en onderhoudsoverhead.
Meerdere teams kunnen parallel aan verschillende modules werken zonder dat er conflicten zijn met elkaars wijzigingen. Hiervoor zijn robuuste omgevingsstrategie en governance vereist.
Eenvoudiger om geautomatiseerde tests en DevOps-procedures te implementeren. Complexere implementatie.
Kleinere oplossingen zijn sneller te implementeren, met name in CI/CD-pijplijnen als u alleen een specifieke app moet implementeren.
Bugs of verslechteringen zijn gemakkelijker te achterhalen wanneer wijzigingen worden geïsoleerd in specifieke modules.

Uw oplossingslagen bouwen

Opmerking

Voordat u de oplossingen in de volgende stappen maakt, gebruikt u dezelfde uitgever voor al uw oplossingen in uw omgevingen. Meer informatie: Oplossingsuitgever

  1. In de 'basis'-ontwikkelomgeving hebt u uw basisoplossing met de algemene niet-beheerde tabellen en geen andere tabellen. Exporteer deze oplossing vervolgens als beheerd.
  2. U stelt een tweede ontwikkelomgeving in voor de extensie- of app-laag die zich later boven op de basislaag bevindt.
  3. U importeert de beheerde basislaag in de ontwikkelomgeving van de app-laag en maakt een onbeheerde oplossing voor de app-laag. Juiste oplossingslagen met meerdere oplossingen met meerdere omgevingen.
  4. U kunt het gegevensmodel nu uitbreiden door extra tabellen, kolommen, tabelrelaties, invoegtoepassingen, stromen enzovoort toe te voegen aan de specifieke app-oplossing. Vervolgens exporteert u de app-oplossing als beheerd. U ziet dat de app-oplossing nog steeds afhankelijk is van de basislaagoplossing, maar het op deze manier beheren van meerdere oplossingen is een betere aanpak. Bekijk het voorbeeld dat eerder wordt vermeld van de stroom die afhankelijk is van een aangepaste kolom. In de meeste gevallen bevinden zowel de aangepaste kolom als de stroom zich in dezelfde app-oplossing. Maar zelfs als de aangepaste kolom deel uitmaakt van de basisoplossing, moet u die basisoplossing eerst voltooien en beheren als een beheerde oplossing, anders kan de flow binnen de app-oplossing niet eens worden aangemaakt.
  5. In uw productieomgeving importeert u de beheerde basislaag en vervolgens importeert u de beheerde app-laag. Hiermee worden twee beheerde lagen in de omgeving gemaakt met duidelijke afhankelijkheden tussen de beheerde oplossingen.
  6. Herhaal dit patroon om zoveel verschillende oplossingen te creëren als nodig voor onderhoud. We raden u echter aan het aantal oplossingen zo klein mogelijk te houden om uw oplossingslagen beheersbaar te houden.

Tabelsegmentatie gebruiken
Scenario 5: Ontwikkeling in teams ondersteunen

  • Last updated on