Del via

Organiser dine løsninger

Før du opretter løsninger, skal du bruge lidt tid på at planlægge din miljøstrategi og din løsningsstrategi forud. Overvej følgende aspekter:

Aspekt Overvejelse
Programområde Strækker din implementering sig over flere programmer, f.eks. Sales, Customer Service, Field Service, Finance osv.?
Versionshyppighed Hvor ofte planlægger du at udrulle opdateringer til produktion?
Er din leveringsmetode baseret på agile praksisser som sprintcyklusser?
Produktionssupport Hvordan håndterer du presserende rettelser i produktionen uden at introducere nye funktioner for tidligt?
Løsningsarkitektur Hvor mange løsninger administrerer du?
Deler disse løsninger komponenter eller er afhængige af hinanden?
Miljøplanlægning Hvor mange Microsoft Dataverse-miljøer har du brug for for at understøtte din udviklingslivscyklus?
Har du brug for separate miljøer til udvikling, test og produktion?
Arbejder udviklere sammen i et delt miljø, eller kræver de isolerede miljøer for at arbejde uafhængigt af hinanden?

I de følgende afsnit beskrives tre strategier, der er arrangeret fra den nemmeste til den mest komplekse, og fremhæver deres respektive fordele og ulemper.

Strategi for en enkelt løsning

Alle tilpasninger er grupperet i én ikke-administreret løsning under udvikling, som senere eksporteres som en enkelt administreret løsning til udrulning.

Anbefalet til:

  • Implementeringer i lille målestok
  • Scenarier, hvor fremtidig modularisering er usandsynlig
Fordel Ulempe
Forenklet konfiguration og administration af miljø. Kræver en større indsats for at skalere eller modularisere senere, hvis det er nødvendigt.
Forenklet udrulning. Med kun én løsning til administration er eksport og import på tværs af miljøer ligetil og mindre fejlbehæftet. En enkelt løsning, der indeholder et stort antal tilpasninger, kan resultere i længere udrulningstider. Hvis du vil reducere løsningsstørrelsen, skal du bruge tabelsegmentering. Hvis du vil reducere importtider, skal du gå til anbefalinger til ydeevne.
Nemmere at finde, overvåge og administrere ændringer. Når flere udviklere arbejder i det samme udviklingsmiljø, risikerer de at overskrive hinandens ændringer. Denne risiko kan reduceres ved at implementere versionsstyring af kildekoden, vedtage en forgreningsstrategi og bruge et dedikeret udviklingsmiljø for hver forgrening. Versionsstyring og forgreningsstrategi for kildekode giver mulighed for ændringssporing, samarbejdsunderstøttelse og konfliktløsningsmekanismer. Flere oplysninger: Brug en Git-forgreningsstrategi.

Bemærk!

De seneste forbedringer af Microsoft Power Platform har reduceret importtiderne for administrerede løsninger, herunder dem, der bruger opgraderingsindstillingen. Disse optimeringer omfatter bedre håndtering af komponentafhængigheder og reduceret spild af uændrede komponenter. Du kan få mere at vide om, hvordan du kan drage fordel af disse forbedringer, ved at gå til anbefalinger til ydeevne.

Flere løsninger i det samme udviklingsmiljø

Flere ikke-administrerede løsninger vedligeholdes i et enkelt udviklingsmiljø, der hver især er dedikeret til ikke-relaterede funktioner eller moduler.

Anbefalet til:

  • Implementeringer i små mellemstore skalaer med særskilte og uafhængige funktionelle områder, der ikke deler komponenter.
Fordel Ulempe
Forenklet konfiguration og administration af miljø. Hvis du vedligeholder flere ikke-administrerede løsninger i det samme udviklingsmiljø, øges sandsynligheden for afhængighedskonflikter. Du kan f.eks. støde på en situation, hvor Løsning A ikke kan importeres, fordi den afhænger af Løsning B, mens Løsning B ikke kan importeres, fordi den afhænger af Løsning A.
Funktionelle områder kan udrulles uafhængigt af hinanden. Flere udviklere, der arbejder på det samme udviklingsmiljø, kan overskrive hinandens ændringer. Arbejde i en ikke-administreret løsning giver ikke isolation. Alle ændringer anvendes direkte på miljøet, uanset hvilken løsning der redigeres.

Bemærk!

Når du har flere løsninger i det samme udviklingsmiljø, opretter du ofte lag, når du har importeret de administrerede løsninger i dit destinationsmiljø. Flere oplysninger: Løsningslag og fletningsadfærd

Det er vigtigt, at du:

  • Medtag ikke den samme ikke-administrerede komponent i mere end én løsning.
  • Har kun én løsning, der indeholder alle dine tabeller. Har ikke to forskellige løsninger, hvor begge indeholder tabeller. Det skyldes, at der ofte er risici ved en enkelt relation mellem tabeller, hvor der oprettes en afhængighed på tværs af løsninger, og som medfører problemer med løsningsopgradering eller sletning i destinationsmiljøet på et senere tidspunkt.
  • Brug kun én løsningsudgiver. Løsningsudgiveren ejer komponenterne i en administreret løsning, og dens tilknytning kan ikke ændres senere. Hvis en brugerdefineret tabel f.eks. importeres som administreret via Løsning A med Publisher X, kan du ikke senere flytte tabellen til Løsning B med Publisher Y. Den eneste mulighed er at slette tabellen, opgradere Løsning A for at fjerne tabellen fra destinationssystemet og derefter genoprette tabellen i Løsning B med Publisher Y og importere Løsning B. Denne proces medfører tab af alle data, der er gemt i den brugerdefinerede tabel, medmindre den er migreret på forhånd.
  • Undgå at oprette afhængigheder mellem løsninger. Afhængigheder gennemtvinger en importordre og kan forårsage problemer. Hvis du f.eks. har én løsning til tabeller og en anden til cloudflows, og et flow er afhængig af en brugerdefineret kolonne, fungerer det under udvikling, fordi kolonnen findes. Men hvis det kun er cloudflowløsningen, der importeres til destinationsmiljøet, genkender importprocessen muligvis ikke afhængigheden af den brugerdefinerede kolonne. Flowløsningen installeres derfor korrekt, men selve flowet fungerer ikke. Flere oplysninger: Eksempler på afhængigheder, der er oprettet af flere løsninger

Eksempler på afhængigheder, der er oprettet af flere løsninger

  • Programbånd. Når flere løsninger ændrer programbåndet eller oversigten over webstedet for den samme app.
  • Plug-ins eller cloudflow. Hvis plug-in'en eller flowet udløser en brugerdefineret kolonne eller opdaterer en brugerdefineret tabel, afhænger objektet af disse brugerdefinerede tabeller.
  • Sikkerhedsroller. Når der findes brugerdefinerede tabeller, afhænger sikkerhedsroller typisk af disse tabeller for brugeradgang.

Flere løsninger med dedikerede udviklingsmiljøer

Denne strategi omfatter udvikling af hver enkelt ikke-administreret løsning i sit eget isolerede Dataverse-udviklingsmiljø. Denne strategi bruges ofte i modulopbyggede arkitekturer, hvor f.eks. forskellige programmer – f.eks. Salg, Kundeservice eller Field Service – bygges og vedligeholdes uafhængigt af hinanden. En basisløsning, der indeholder almindelige komponenter (f.eks. tabeller over konti og kontakter), oprettes og udrulles som en administreret løsning i hvert app-specifikke udviklingsmiljø. Hver app har derefter sin egen ikke-administrerede løsning, der er placeret oven på den basisadministrerede løsning, så teams kan udvide funktionaliteten uden at ændre grundgrundlaget.

Anbefalet til:

  • Store virksomhedsprojekter.
  • Teams med flere udviklere eller partnere
  • Scenarier, der kræver streng styring og CI/CD-pipelines.
Fordel Ulempe
Nemmere at udvide og udvikle dit system ved at tilføje eller opdatere moduler uden at påvirke andre. Højere infrastruktur- og vedligeholdelsesomkostninger.
Flere teams kan arbejde parallelt på forskellige moduler uden at være i konflikt med hinandens ændringer. Kræver robust miljøstrategi og styring.
Nemmere at implementere automatiserede test og DevOps-fremgangsmåder. Mere kompleks udrulning.
Mindre løsninger er hurtigere at udrulle, især i CI/CD-pipelines, hvis du kun skal udrulle en bestemt app.
Fejl eller regressioner er lettere at spore, når ændringer er isoleret til bestemte moduler.

Sådan opretter du dine løsningslag

Bemærk!

Før du opretter løsningerne i følgende trin, skal du bruge den samme udgiver til alle dine løsninger på tværs af dine miljøer. Flere oplysninger: Løsningsudgiver

  1. I udviklingsmiljøet "basis" har du din basisløsning med de almindelige ikke-administrerede tabeller og ingen andre tabeller. Eksportér derefter denne løsning som administreret.
  2. Du konfigurerer endnu et udviklingsmiljø for udvidelses- eller "app"-laget, der senere placeres oven på basislaget.
  3. Du importerer det administrerede basislag til applagets udviklingsmiljø og opretter en ikke-administreret løsning til applaget. Korrekt lagdeling af løsninger ved hjælp af flere løsninger med flere miljøer.
  4. Du kan nu udvide datamodellen ved at føje yderligere tabeller, kolonner, tabelrelationer, plug-ins, flow osv. til den specifikke "app"-løsning. Du kan derefter eksportere app-løsningen som administreret. Bemærk, at appløsningen stadig afhænger af basislagsløsningen, men det er en bedre tilgang at administrere flere løsninger på denne måde. Overvej det tidligere nævnte eksempel på flowet, der er baseret på en brugerdefineret kolonne. I de fleste tilfælde er både den brugerdefinerede kolonne og flowet placeret i den samme appløsning. Men selvom den brugerdefinerede kolonne er en del af basisløsningen, skal du fuldføre og udrulle basisløsningen som administreret først, ellers kan flowet i appløsningen ikke engang oprettes.
  5. I produktionsmiljøet skal du importere det administrerede basislag og derefter importere det administrerede applag. Dette opretter to administrerede lag i miljøet med tydelige afhængigheder mellem de administrerede løsninger.
  6. Gentag dette mønster for at have lige så mange forskellige løsninger, som du skal vedligeholde. Det anbefales, at du opbevarer så få løsninger som muligt for at holde løsningslaget overskueligt.

Brug tabelsegmentering
Scenarie 5: Understøttelse af teamudvikling

  • Last updated on