Miljöstrategi för ALM
Om du vill följa ALM-policyer (hantering av programlivscykel) måste du ha olika miljöer för programutveckling och -produktion. Du kan utföra grundläggande ALM med endast separata utvecklings- och produktionsmiljöer, men vi rekommenderar att du även bibehåller minst en testmiljö som är separat från utvecklings- och produktionsmiljöerna. Om du har en separat testmiljö kan du utföra en komplett validering som omfattar lösningsdistribution och programtestning. Vissa organisationer kan också behöva fler miljöer för testning av användargodkännande (UAT), systemintegrationstestning (SIT) och utbildning.
Separata utvecklingsmiljöer kan vara till hjälp för att hjälpa till att isolera ändringar från en arbetsinsats som checkas in innan den har slutförts. Det kan också vara bra att ha separata utvecklingsmiljöer i syfte att minimera antalet situationer då en enda person negativt påverkar en annan när de utför ändringar.
Alla organisationer är unika, och du bör därför noggrant överväga vad organisationens miljö verkligen behöver.
Utvecklingsmiljöer
Du bör kunna besvara frågor som exempelvis:
- Hur många utvecklingsmiljöer behöver jag?
- Mer information: Miljö, översikt
- Hur gör jag för att automatiskt tillhandahålla miljöer från källkod?
- Mer information: Microsoft Power Platform Build Tools för Azure DevOps
- Vilka är beroendena i mina miljöer?
- Mer information: Flera lösningslager och beroenden
Andra miljöer
Du bör också besvara frågan: "Vilka typer av miljöer som inte ska kunna utvecklas behöver jag?"
Utöver produktionsmiljön kan du till exempel behöva separata test-, UAT-, SIT- och förproduktionsmiljöer. Observera att en felfri ALM-praxis åtminstone bör omfatta användning av en test miljö innan du distribuerar någonting till produktionsmiljön. Detta säkerställer att du har någonstans att testa ditt program, men även att själva distributionen kan testas.
Mer information: Skapa en miljöstrategi för Microsoft Power Platform
Multigeografiska överväganden
Power Platform miljöer följer ett specifikt schema för tjänst uppdatering när miljöer uppdateras över hela världen. Det finns totalt sex stationer som i första hand definieras av geografiskt läge. Serviceuppdateringar tillämpas i följd för varje station. Så, station 2 serviceuppdateringar tillämpas före station 3. Därför är det vanligt att miljöer som finns i olika stationer har olika versioner vid en viss tidpunkt. Mer information om uppdateringsschemat för miljötjänsten finns i Släppta versioner av Microsoft Dataverse
Import- och miljöversion av lösningar
När du har flera miljöer i olika regioner är det viktigt att förstå följande när du importerar en lösning:
- Du kan importera en lösning till en miljö som är en nyare version än miljön där lösningen exporterades.
- Du kan inte tillförlitligt importera en lösning till en miljö som är en äldre version än miljön där lösningen exporterades. Detta beror på att det kan saknas komponenter eller nödvändiga funktioner i den äldre miljön.
Exempel på att anpassa miljöer till tjänstuppdateringsstationer
Föreställ dig att du har produktionsmiljöer i Kanada och USA. I så fall bör dina utvecklingsmiljöer vara i Nordamerika (station 5) och inte i Kanada (station 2). Sedan kommer dina utvecklingsmiljöer alltid att vara desamma eller en tidigare version än dina produktionsmiljöer, vilket kommer att minska konflikter för lösningsimportversion.
