Organisera dina lösningar
Se till att ta dig tid att planera framåt innan du börjar skapa lösningar. Fundera till exempel över hur många lösningar du vill släppa, och om lösningarna delar komponenter.
Kontrollera också hur många Microsoft Dataverse-miljöer du behöver för att utveckla dina lösningar. Du kan använda en enda utvecklingsmiljö för de flesta strategier som beskrivs i den här artikeln. Om du väljer att ha endast en (1) miljö och senare inser att du behöver fler kan det emellertid bli svårt att ändra lösningarna om dessa redan har installerats. Om du använder flera miljöer kan detta ge en bättre flexibilitet, även om du då samtidigt också tvingas hantera mer komplexitet.
I följande avsnitt beskrivs olika strategier för att hantera lösningar listade i ordning från enkla till mer komplexa.
Enskild lösning
Genom att skapa en lösning skapar du en fungerande uppsättning anpassningar. En enskild lösning gör det lättare att hitta objekt som du har anpassat.
Den här metoden rekommenderas om du endast vill skapa en enskild hanterad lösning. Om du tror att du kan komma att behöva dela upp lösningen i framtiden bör du överväga att använda flera lösningar.
Flera lösningar
Om du har två icke-relaterade lösningar som inte delar komponenter är det mest direkta sättet att skapa två icke-hanterade lösningar.
Obs
Att ändra programmets menyfliksområden eller webbplatsöversikt är mycket vanligt i lösningar. Om båda lösningarna ändrar dessa komponenter, delas komponenterna. I följande avsnitt finns information om hur du arbetar med delade komponenter.
Flera lösningsskikt och beroenden
När du importerar olika lösningar till din målmiljö skapar du ofta lager där den befintliga lösningen ligger under den som importeras. När det gäller lösningsskiktning är det viktigt att du inte har beroenden mellan olika lösningar. Att ha flera lösningar i samma miljö med samma icke-hanterade komponent bör undvikas. Det här beroendeproblemet mellan lösningar gäller särskilt för tabeller.
Segmentera dina lösningar efter komponenttyp när det inte finns några korsberoende risker. Har till exempel en lösning som innehåller alla dina tabeller, en annan lösning som har alla dina plugin-program och en tredje lösning som har alla dina flöden. Dessa olika komponenter har inga risker för beroenden mellan olika lösningar. Därför är det säkert att ha flera lösningar utformade på samma sätt i samma miljö.
Har inte två olika lösningar i en miljö där båda innehåller tabeller. Detta beror på att det ofta finns risker för ett enda förhållande mellan tabeller, vilket skapar ett beroende av olika lösningar och orsakar lösningsuppgradering eller borttagning av problem i målmiljön vid en senare tidpunkt.
När du utformar dina lösningsskikt och vill ha en strukturerad inställning för program bör du börja med ett baslager. Senare importerar du ytterligare lösningar som ligger ovanpå baslagret. Därefter har du ett baslager och förlängningsskikt ovanpå som sträcker det baslagret.
När du hanterar dina projekt på det här sättet rekommenderar vi att du använder en separat miljö för varje lager. Bygg din lösningsskiktning med hjälp av dessa steg.
Innan du skapar lösningarna i följande steg, använd en enda utgivare för alla dina lösningar i dina miljöer. Mer information: lösningsutgivare
I ”bas” -miljön har du din baslösning med de ohanterade tabellerna från den miljön och inga andra tabeller. Du exporterar sedan den här lösningen som hanterad.
Du skapar en andra miljö för tillägget eller ”app” -skiktet som senare kommer att ligga ovanpå baslagret.
Du importerar det hanterade baslagret till applagermiljön och skapar en ohanterad lösning för applagret.
Du kan nu utöka datamodellen genom att lägga till ytterligare tabeller, kolumner, tabellrelationer och så vidare i applösningen. Exportera sedan applösningen som hanterad. Observera att applösningen kommer att bero på baslagerlösningen.
I din produktionsmiljö importerar du det hanterade baslagret och sedan importerar det hanterade programlagret. Detta skapar två hanterade lager i miljön med tydliga beroenden mellan de två hanterade lösningarna. Att hantera flera lösningar på detta sätt skapar inte beroenden mellan olika lösningar, vilket kan orsaka problem med underhåll av lösningar, som att ta bort det övre lagret vid behov.
Upprepa detta segmenteringsmönster för att ha så många olika lösningar som du behöver behålla. Även om vi rekommenderar att du håller antalet lösningar så små som möjligt för att hålla din lösningsskikt hanterbar.
Se även
Använda segmenterade lösningar
Scenario 5: Stödja teamutveckling