Organisere løsninger

Før du oppretter løsninger, må du ta deg tid til å planlegge miljøstrategien og løsningsstrategien. Vurder følgende aspekter:

Aspekt	Vurdering
Programomfang	Strekker implementeringen seg over flere programmer, for eksempel Salg, Kundeservice, Felttjeneste, Økonomi osv.?
Lanseringsfrekvens	Hvor ofte planlegger du å distribuere oppdateringer til produksjon? Er leveringsmetodikken basert på smidige praksiser som sprintsykluser?
Produksjonsstøtte	Hvordan håndterer du presserende løsninger i produksjonen uten å introdusere nye funksjoner for tidlig?
Løsningsarkitektur	Hvor mange løsninger administrerer du? Deler disse løsningene komponenter eller avhenger av hverandre?
Miljøplanlegging	Hvor mange Microsoft Dataverse-miljøer trenger du for å støtte utviklingslivssyklusen? Trenger du separate miljøer for utvikling, testing og produksjon? Samarbeider utviklere i et delt miljø, eller krever de at isolerte miljøer fungerer uavhengig?

De følgende avsnittene skisserer tre strategier, ordnet fra det enkleste til det mest komplekse, og fremhever deres respektive fordeler og ulemper.

Strategi for én enkelt løsning

Alle tilpasninger grupperes i én uadministrert løsning under utvikling, som senere eksporteres som én enkelt administrert løsning for distribusjon.

Anbefales for:

• Implementeringer av små og mellomstore skalaer
• Scenarier der fremtidig modulærisering er usannsynlig

Fordel	Ulempe
Forenklet miljøoppsett og -administrasjon.	Krever mer innsats for å skalere eller modularisere senere om nødvendig.
Forenklet distribusjon. Med bare én løsning å administrere, er eksport og import på tvers av miljøer enkel og mindre feilutsatt.	Én enkelt løsning som inneholder et stort antall tilpasninger, kan føre til lengre distribusjonstider. Hvis du vil redusere løsningsstørrelsen, kan du bruke tabellsegmentering. Hvis du vil redusere importtider, kan du gå til ytelsesanbefalinger.
Enklere å finne, overvåke og behandle endringer.	Når flere utviklere arbeider i samme utviklingsmiljø, risikerer de å overskrive hverandres endringer. Denne risikoen kan reduseres ved å implementere versjonskontroll av kildekode, ta i bruk en forgreningsstrategi og bruke et dedikert utviklingsmiljø for hver gren. Versjonskontroll av kildekode og forgreningsstrategi gir endringssporing, samarbeidsstøtte og konfliktløsningsmekanismer. Mer informasjon: Vedta en Git-forgreningsstrategi.

Obs!

Nylige forbedringer i Microsoft Power Platform har redusert importtider for administrerte løsninger, inkludert de som bruker oppgraderingsalternativet. Disse optimaliseringene inkluderer bedre håndtering av komponentavhengigheter og redusert indirekte kostnad for uendrede komponenter. Hvis du vil lære hvordan du drar nytte av disse forbedringene, kan du gå til ytelsesanbefalinger.

Flere løsninger i samme utviklingsmiljø

Flere uadministrerte løsninger vedlikeholdes i ett enkelt utviklingsmiljø, som hver vanligvis er dedikert til ikke-relaterte funksjoner eller moduler.

Anbefales for:

• Implementeringer av små og mellomstore skalaer med distinkte og uavhengige funksjonsområder som ikke deler komponenter.

Fordel	Ulempe
Forenklet miljøoppsett og -administrasjon.	Hvis du opprettholder flere uadministrerte løsninger i samme utviklingsmiljø, øker sannsynligheten for avhengighetskonflikter. Du kan for eksempel støte på en situasjon der løsning A ikke kan importeres fordi det avhenger av løsning B, mens løsning B ikke kan importeres fordi det avhenger av løsning A.
Funksjonelle områder kan distribueres uavhengig av hverandre.	Flere utviklere som arbeider på samme utviklingsmiljø, kan overskrive hverandres endringer. Det å arbeide i en uadministrert løsning gir ikke isolasjon. Hver endring brukes direkte på miljøet, uavhengig av hvilken løsning som redigeres.

Obs!

Når du har flere løsninger i samme utviklingsmiljø, oppretter du ofte lag når du har importert de administrerte løsningene til målmiljøet. Mer informasjon: Løsningslag og virkemåte for fletting

Det er viktig at du:

• Ikke inkluder den samme uadministrerte komponenten i mer enn én løsning.
• Har bare én løsning som inneholder alle tabellene. Ikke ha to forskjellige løsninger der begge inneholder tabeller. Dette skyldes at det ofte er risiko for én enkelt relasjon mellom tabeller, noe som oppretter en avhengighet på tvers av løsninger og forårsaker løsningsoppgradering eller sletting av problemer i målmiljøet på et senere tidspunkt.
• Bruk bare én løsningsutgiver. Løsningsutgiveren eier komponentene i en administrert løsning, og tilknytningen kan ikke endres senere. Hvis en egendefinert tabell for eksempel importeres som administrert gjennom løsning A med Publisher X, kan du ikke senere flytte tabellen til løsning B med Publisher Y. Det eneste alternativet er å slette tabellen, oppgradere løsning A for å fjerne tabellen fra målsystemet, og deretter gjenopprette tabellen i løsning B med Publisher Y og importere løsning B. Denne prosessen fører til tap av alle data som er lagret i den egendefinerte tabellen, med mindre de overføres på forhånd.
• Unngå å opprette avhengigheter mellom løsninger. Avhengigheter fremtvinger en importrekkefølge og kan forårsake problemer. Hvis du for eksempel har én løsning for tabeller og en annen for skyflyter, og en flyt er avhengig av en egendefinert kolonne, fungerer den under utvikling fordi kolonnen finnes. Hvis bare skyflytløsningen importeres til målmiljøet, gjenkjenner kanskje ikke importprosessen avhengigheten av den egendefinerte kolonnen. Som et resultat av dette installeres flytløsningen, men selve flyten fungerer ikke. Mer informasjon: Eksempler på avhengigheter opprettet av flere løsninger

Eksempler på avhengigheter opprettet av flere løsninger

• Verktøyribber. Når flere løsninger endrer programbåndet eller områdekartet for den samme appen.
• Programtillegg eller skyflyter. Hvis plugin- eller flytutløseren utløser på en egendefinert kolonne eller oppdaterer en egendefinert tabell, er objektet avhengig av de egendefinerte tabellene.
• Sikkerhetsroller. Når det finnes egendefinerte tabeller, avhenger sikkerhetsroller vanligvis av disse tabellene for brukertilgang.

Flere løsninger med dedikerte utviklingsmiljøer

Denne strategien innebærer å utvikle hver uadministrert løsning i sitt eget isolerte dataverse utviklingsmiljø. Denne strategien brukes ofte i modulære arkitekturer der for eksempel ulike programmer, for eksempel salg, kundeservice eller felttjeneste, bygges og vedlikeholdes uavhengig av hverandre. En basisløsning som inneholder vanlige komponenter (for eksempel konto- og kontakttabeller) opprettes og distribueres som en administrert løsning i hvert appspesifikke utviklingsmiljø. Hver app har deretter sin egen uadministrerte løsning, lagdelt på toppen av den grunnleggende administrerte løsningen, slik at team kan utvide funksjonaliteten uten å endre grunngrunnlaget.

Anbefales for:

• Store virksomhetsprosjekter.
• Teams med flere utviklere eller partnere
• Scenarioer som krever streng styring og CI/CD-datasamlebånd.

Fordel	Ulempe
Enklere å vokse og utvikle systemet ved å legge til eller oppdatere moduler uten å påvirke andre.	Høyere infrastruktur og vedlikeholdskostnader.
Flere team kan arbeide parallelt med forskjellige moduler uten å komme i konflikt med hverandres endringer.	Krever robust miljøstrategi og styring.
Enklere å implementere automatiserte test- og DevOps-fremgangsmåter.	Mer kompleks distribusjon.
Mindre løsninger er raskere å distribuere, spesielt i CI/CD-datasamlebånd hvis du bare må distribuere en bestemt app.
Feil eller regresjoner er enklere å spore når endringer er isolert til bestemte moduler.

Slik bygger du løsningslagene

Obs!

Før du oppretter løsningene i trinnene nedenfor, kan du bruke samme utgiver for alle løsningene dine på tvers av miljøene. Mer informasjon: Løsningsutgiver

1. I utviklingsmiljøet «basis» har du den grunnleggende løsningen med de vanlige uadministrerte tabellene og ingen andre tabeller. Eksporter deretter denne løsningen som administrert.
2. Du konfigurerer et nytt utviklingsmiljø for utvidelses- eller applaget som senere befinner seg oppå basislaget.
3. Du importerer det administrerte basislaget til utviklingsmiljøet for applag og oppretter en uadministrert løsning for applaget.
4. Du kan nå utvide datamodellen ved å legge til flere tabeller, kolonner, tabellrelasjoner, plugin-moduler, flyter og så videre, til den spesifikke «app»-løsningen. Deretter eksporterer du appløsningen som administrert. Legg merke til at appløsningen fortsatt avhenger av den grunnleggende lagløsningen, men det er en bedre tilnærming å administrere flere løsninger på denne måten. Vurder eksemplet nevnt før flyten som er avhengig av en egendefinert kolonne. I de fleste tilfeller ligger både den egendefinerte kolonnen og flyten i den samme appløsningen. Men selv om den egendefinerte kolonnen er en del av den grunnleggende løsningen, må du fullføre og distribuere den grunnleggende løsningen som administrert først, ellers kan ikke flyten i appløsningen opprettes.
5. I produksjonsmiljøet importerer du det administrerte basislaget og importerer deretter det administrerte applaget. Dette oppretter to administrerte lag i miljøet med klare avhengigheter mellom de administrerte løsningene.
6. Gjenta dette mønsteret for å ha så mange forskjellige løsninger som du trenger for å opprettholde. Vi anbefaler likevel at du holder antallet løsninger så lavt som mulig slik at løsningslag blir håndterbare.

Relaterte artikler

Bruk tabellsegmentering
Scenario 5: Støtte for teamutvikling