Miljøstrategi for ALM
Hvis du vil følge ALM-principperne (Application Lifecycle Management), skal du have separate miljøer for udvikling og produktion af apps. Selvom du kan udføre grundlæggende ALM med kun separate udviklings- og produktionsmiljøer, anbefaler vi, at du også har mindst ét testmiljø, der er adskilt fra dit udviklings- og produktionsmiljøer. Når du har et separat testmiljø, kan du udføre komplet validering, der omfatter løsningsinstallation og applikationstest. Nogle organisationer har måske også brug for flere miljøer til test af brugeraccept (UAT), test af systemintegration (SIT) og træning.
Særskilte udviklingsmiljøer kan være en hjælp til at isolere ændringer fra en arbejdsindsats, der indføres, før den fuldføres. Separate udviklingsmiljøer kan også være en god ide til at reducere de situationer, hvor en person har negativ indvirkning på en anden, samtidig med at der foretages ændringer.
Alle organisationer er unikke, så du skal nøje overveje, hvad organisationens miljøbehov er.
Udviklingsmiljøer
Du skal besvare spørgsmål, f.eks.:
- Hvor mange udviklingsmiljøer skal jeg bruge?
- Du kan finde flere oplysninger i: Oversigt over miljøer
- Hvordan kan jeg automatisk klargøre miljøer fra kildekode?
- Flere oplysninger: Microsoft Power Platform Build Tools til Azure DevOps
- Hvad er afhængighederne i mine miljøer?
- Flere oplysninger: Flere lag og afhængigheder i løsninger
Andre miljøer
Du skal også besvare spørgsmålet "Hvilke typer af ikke-udviklingsmiljøer skal jeg bruge?"
Ud over produktionsmiljøet kan du f.eks. have brug for separate test-, UAT-, SIT- og førproduktionsmiljøer. Vær opmærksom på, at der som minimum skal inkluderes en sund ALM-øvelse ved hjælp af et testmiljø, inden du installerer alt i produktionsmiljøet. Dette sikrer, at du har et sted, hvor du kan teste din app, men den sikrer også, at selve installationen kan testes.
Flere oplysninger: Oprettelse af en miljøstrategi til Microsoft Power Platform
Flere geografiske overvejelser
Power Platform-miljøer følger en bestemt tidsplan for serviceopdateringer, da miljøer opdateres i hele verden. Der findes i alt seks stationer, som primært defineres ud fra en geografisk placering. Serviceopdateringer anvendes i rækkefølge for hver station. Så station 2-serviceopdateringer anvendes før station 3. Det er derfor almindeligt, at miljøer på forskellige stationer har forskellige versioner på et bestemt tidspunkt. Du kan finde flere oplysninger om tidsplanen for opdatering af miljøservice ved at gå til Udgivne versioner af Microsoft Dataverse
Løsningsimport og miljøversion
Når du har flere miljøer i forskellige geografiske områder, er det vigtigt at forstå følgende, når du importerer en løsning:
- Du kan importere en løsning til et miljø, der er en nyere version end det miljø, løsningen blev eksporteret til.
- Du kan ikke importere en løsning sikkert til et miljø, der er en ældre version end det miljø, løsningen blev eksporteret til. Det skyldes, at der muligvis mangler komponenter eller påkrævede funktioner i det ældre miljø.
Eksempel på en vellykket tilpasning af miljøer med serviceopdateringsstationer
Forestil dig, at du har produktionsmiljøer i Canada og USA. I det tilfælde skal dine udviklingsmiljøer være i Nordamerika (station 5) og ikke i Canada (station 2). Udviklingsmiljøerne vil derefter altid være de samme eller en tidligere version end produktionsmiljøerne, hvilket vil begrænse konflikter i løsningsimportversioner.
