Miljøstrategi for ALM
For å følge ALM-prinsipper (behandling av applivssyklus) trenger du separate miljøer for apputvikling og -produksjon. Selv om du kan utføre grunnleggende ALM med bare separate utviklings- og produksjonsmiljøer, anbefaler vi at du også vedlikeholder minst ett testmiljø som er atskilt fra utviklings- og produksjonsmiljøene. Når du har et separat testmiljø, kan du utføre en total validering som inkluderer løsningsdistribusjon og apptesting. Noen organisasjoner kan også trenge flere miljøer for testing av brukeraksept (UAT), systemintegreringstesting (SIT) og opplæring.
Separate utviklingsmiljøer kan være nyttig for å isolere endringer fra én arbeidsøkt som sjekkes før den fullføres. Separate utviklingsmiljøer kan også være nyttig for å redusere situasjoner der én person har negativ innvirkning på en annen når de gjør endringer.
Hver organisasjon er unik, så du bør vurdere hvilke behov miljøet i organisasjonen din har.
Utviklingsmiljøer
Du må svare på spørsmål som:
- Hvor mange utviklingsmiljøer trenger jeg?
- Mer informasjon: Oversikt over miljøer
- Hvordan kan jeg automatisk klargjøre miljøer fra kildekoden?
- Mer informasjon: Microsoft Power Platform Build Tools for Azure DevOps
- Hva er avhengighetene i miljøene mine?
- Mer informasjon: Lagdeling og avhengigheter for flere løsninger
Andre miljøer
Du bør også svare på spørsmålet: "Hvilke typer ikke-utviklingsmiljøer trenger jeg?"
I tillegg til produksjonsmiljøet kan du for eksempel trenge separate miljøer for test, UAT, SIT og forhåndsproduksjon. Legg merke til at som et minimum bør enhver sunn ALM-praksis inkludere et testmiljø før noe som helst distribueres til produksjonsmiljøet. Dette sikrer at du har et sted å teste appen, men sikrer også at selve distribusjonen kan testes.
Mer informasjon: Etablere en miljøstrategi for Microsoft Power Platform
Multi-geografiske hensyn
Power Platform-miljøer følger en bestemt tidsplan for tjenesteoppdatering etter hvert som miljøer oppdateres over hele verden. Det er totalt seks stasjoner som primært er definert etter geografisk plassering. Tjenesteoppdateringer brukes i rekkefølge for hver stasjon. Så stasjon 2 serviceoppdateringer brukes før stasjon 3. Derfor er det vanlig at miljøer som er på forskjellige stasjoner, har forskjellige versjoner på et bestemt tidspunkt. Hvis du vil ha mer informasjon om oppdateringsplanen for miljøtjenesten, kan du gå til Utgitte versjoner av Microsoft Dataverse
Løsningsimport og miljøversjon
Når du har flere miljøer i forskjellige områder, er det viktig å forstå følgende når du importerer en løsning:
- Du kan importere en løsning til et miljø som er en nyere versjon enn miljøet der løsningen ble eksportert.
- Du kan ikke på en pålitelig måte importere en løsning til et miljø som er en gamlere versjon enn miljøet der løsningen ble eksportert. Dette er fordi det kan være manglende komponenter eller nødvendig funksjonalitet i det eldre miljøet.
Eksempel på vellykket justering av miljøer med serviceoppdateringsstasjoner
Tenk deg at du har produksjonsmiljøer i Canada og USA. I så fall bør utviklingsmiljøene dine være i Nord-Amerika (stasjon 5) og ikke i Canada (stasjon 2). Deretter vil utviklingsmiljøene alltid være de samme eller en tidligere versjon enn produksjonsmiljøene, noe som vil begrense versjonskonflikter for løsningsimport.
