Grundläggande ALM med Microsoft Power Platform
I den här artikeln beskrivs de komponenter, verktyg och processer som krävs för att implementera hantering av programlivscykel (ALM).
Miljöer
Miljöer är ett utrymme där du lagrar, hanterar och delar din organisations verksamhetsdata, program och verksamhetsprocesser. De fungerar också som behållare för olika program som kan ha olika roller, säkerhetskrav eller målgrupper. Det kan bara finnas en enda Microsoft Dataverse-databas i respektive miljö. Mer information: Miljö, översikt
Viktigt!
När du skapar en miljö kan du välja att installera Dynamics 365-program, till exempel Dynamics 365 Sales och Dynamics 365 Marketing. Det är viktigt att fastställa vid den tidpunkten om programmen är obligatoriska eller inte eftersom de inte kan avinstalleras eller installeras senare. Om du inte bygger på de här programmen och inte behöver dem i framtiden, rekommenderar vi att du inte installerar dem i dina miljöer. Detta bidrar till att undvika problem med beroenden när du distribuerar lösningar mellan miljöer.
Typer av miljöer som används i ALM
Med administrationscentret för Power Platform kan du skapa följande typer av Power Platform-miljöer:
Sandbox-miljö En sandbox-miljö är en icke-produktionsmiljö av Dataverse. Eftersom en miljö i begränsat läge är isolerad från produktionen är den en bra plats för att utveckla och testa ändringar i programmet på ett säkert sätt. Sandbox-miljöer omfattar funktioner som skulle vara skadliga i produktionsmiljön, t.ex. återställnings-, borttagnings- och kopieringsåtgärder. Mer information finns i: Hantera sandbox-miljöer
Produktion Miljön där program och andra program sätts i drift för avsedd användning.
Utvecklare (kallas för Community). Med Power Apps utvecklarplan får du åtkomst till Power Apps förstklassiga funktioner Dataverse och Power Automate för individuell användning. Den här planen är främst avsedd att bygga och testa Power Apps, Power Automate och Microsoft Dataverse eller för utbildningssyften. En utvecklarmiljö är en miljö med endast en användare, och kan inte användas för att köra eller dela produktionsappar.
Standard En enda standardmiljö skapas automatiskt av för varje klientorganisation och delas av alla användare i klientorganisationen. Klientorganisationen identifierar kunden, som kan ha en eller flera Microsoft-prenumerationer och tjänster associerade med den. När en ny användare registrerar sig för Power Apps får denne automatiskt rollen Utvecklare för standardmiljön. Standardmiljön skapas i det närmaste området till standardområdet för Microsoft Entra-klientorganisationen och erhåller namnet: "{Microsoft Entra klientorganisation} (standard)"
Skapa och använda rätt miljö för ett specifikt syfte, till exempel utveckling, test eller produktion.
Mer information om hur du arbetar med miljöer, se Översikt över miljöer.
Vem ska ha åtkomst?
Definiera och hantera säkerheten för dina resurser och data i Microsoft Dataverse. Microsoft Power Platform tillhandahåller administrativa roller på miljönivå för att utföra uppgifter. Dataverse innehåller säkerhetsroller som definierar den åtkomstnivå för program, appkomponenter och resurser som programutvecklare och användare har inom Dataverse.
| Miljösyfte | Roller som har åtkomst | Kommentarer |
|---|---|---|
| Utveckling | Apputvecklare och utvecklare. | Program-användare bör inte ha åtkomst. För utvecklare krävs minst säkerhetsroll som miljöutvecklare för att kunna skapa resurser. |
| Testa | Administratörer och personer som testar. | Apputvecklare, utvecklare och användare av produktionsappen bör inte ha åtkomst. Testanvändarna bör ha endast tillräcklig behörighet för att utföra testning. |
| Produktion | Administratörer och programanvändare. Användarna bör endast ha tillräcklig behörighet för att utföra sina uppgifter för de program de använder. | Apputvecklare och -utvecklare bör inte ha åtkomst, eller bör endast ha privilegier på användarnivå. |
| Standardvärde | Som standard kan alla användare i din klientorganisation skapa och redigera program i en Dataverse-standardmiljö som har en databas. | Vi rekommenderar starkt att du skapar miljöer för ett specifikt syfte, samt att du beviljar lämpliga roller och privilegier enbart till de personer som behöver dem. |
Mer information:
- Miljöer: översikt
- Styra användarnas åtkomst till miljöer: säkerhetsgrupper och licenser
- Skapa användare och tilldela säkerhetsroller
- Skapa miljöer
Lösningar
Lösningar används för att transportera program och komponenter från en miljö till en annan eller för att tillämpa en uppsättning anpassningar på befintliga program.
Lösningar har följande funktioner:
De innehåller metadata och vissa entiteter med konfigurationsdata. Lösningar innehåller inte några verksamhetsdata.
De kan innehålla många olika Microsoft Power Platform-komponenter, t.ex. modell drivna program, arbetsyteappar, webbplatsöversikter, flöden, entiteter, formulär, anpassade anslutningsprogram, webbresurser, alternativuppsättningar, diagram och fält. Observera att alla entiteter inte kan ingå i en lösning. Systemtabeller för programanvändare, anpassat API och organisationsinställningar kan till exempel inte läggas till i en lösning.
De paketeras som en enhet för export och import till andra miljöer, eller dekonstrueras och checkas in i källkontrollen som källkod för tillgångar. Lösningar används också för att tillämpa ändringar i befintliga lösningar.
Hanterade lösningar används för att distribuera till alla miljöer som inte är utvecklingsmiljöer för just den lösningen. Detta omfattar miljöer för testning, användaracceptans (UAT), systemintegrering (SIT) och produktion. Hanterade lösningar kan betjänas (uppgradera, korrigera och ta bort) oberoende av andra hanterade lösningar i en miljö. Som en ALM-metod bör de hanterade lösningarna skapas av en versionsserver och betraktas som ett versionsobjekt.
Uppdateringar till en hanterad lösning distribueras till den tidigare versionen av den hanterade lösningen. Detta innebär inte att ett ytterligare lösningslager skapas. Du kan inte ta bort komponenter med hjälp av en uppdatering.
En korrigeringsfil innehåller endast ändringar för en överordnad hanterad lösning. Du bör endast använda korrigeringsfiler när du gör små uppdateringar (påminner om en snabbkorrigering) och behöver den för att kunna avinstallera. När korrigeringsfiler importeras läggs de ovanpå den överordnade lösningen. Du kan inte ta bort komponenter med hjälp av en korrigering.
Om du uppgraderar en lösning installeras ett nytt lösningslager omedelbart ovanför baslagret och eventuella befintliga korrigeringsfiler.
Om du tillämpar lösningsuppgraderingar måste du ta bort alla befintliga korrigeringsfiler och grundlagret.
Uppgraderingar av lösningar innebär att komponenter som fanns men som inte längre ingår i den uppgraderade versionen tas bort.
Mer information: Lösningskoncept
Källkontroll
Källkontroll (kallas även versionskontroll) är ett system som underhåller och lagrar resurser för programvaruutveckling och spårar förändringar för dessa tillgångar. Ändringsspårning är särskilt viktigt när flera programutvecklare och -utvecklare arbetar med samma uppsättning filer. Ett källkontrollssystem gör det också möjligt att återställa ändringar eller att återställa borttagna filer.
Ett källkontrollsystem hjälper organisationer att uppnå felfria ALM eftersom de tillgångar som hanteras i källkontrollsystemet är "den enda källan till sanningen" eller, med andra ord, den enda åtkomst- och ändringspunkten för dina lösningar.
Strategi för förgrening och sammanslagning
Nästan alla källkontrollsystem har någon form av stöd för förgrening och sammanslagning. Föregrening innebär att man avviker från utvecklingens huvudlinje och fortsätter att arbeta utan att förändra huvudlinjen. Sammanslagningsprocessen består av att kombinera en gren med en annan, t.ex. från en utvecklingsgren till en huvudlinjegren. Vissa vanliga förgreningsstrategier är trunkbaserad förgrening, versionsförgrening och funktionsförgrening. Mer information: Implementera en strategi för git-förgrening
Källkontrollprocess med hjälp av en lösning
Du kan använda två huvudsakliga sätt för att arbeta med lösningar i ett källkontrollssystem:
- Exportera den icke-hanterade lösningen och placera den som uppackad i källkontrollsystemet. Framställningsprocessen importerar den komprimerade lösningen som icke-hanterad till en tillfällig Framställningsmiljö (sandbox-miljö). Exportera sedan lösningen som hanterad och spara den som ett framställningsobjekt i källkontrollsystemet.
- Exportera lösningen som icke-hanterad även som hanterad, och lägg båda i källkontrollsystemet. Även om den här metoden inte kräver en Framställningsmiljö, så kräver den att du behåller två kopior av alla komponenter (en kopia av alla icke-hanterade komponenter från den icke-hanterade lösningen och en kopia av alla hanterade komponenter i hanterad lösning).
Mer information: Uppgifter för framställningsverktyg
Automatisering
Automatisering är en viktig del av programmets livscykel som förbättrar produktiviteten, tillförlitligheten, kvaliteten och effektiviteten hos ALM. Automatiseringsverktyg och -uppgifter används för att validera, exportera, komprimera, packa upp och exportera lösningar, förutom att skapa och återställa sandbox-miljöer.
Mer information: Vad är Microsoft Power Platform Build Tools?
Teamutveckling med hjälp av delad källkontroll
Det är viktigt att du funderar på hur du och utvecklingsteamet kommer att arbeta tillsammans för att skapa projektet. Om du bryter upp silor och främjar vyer och konversationer kan ditt team leverera bättre program. Vissa verktyg och arbets flöden t.ex. de som tillhandahålls i Git, GitHub och Azure DevOps har utformats uttryckligen för att kunna förbättra kommunikations- och programvarukvaliteten. Observera att arbete med konfigurationer i ett lösningssystem kan skapa utmaningar för teamutvecklingen. Organisationer måste leda ändringar från flera utvecklare i syfte att undvika sammanslagningskonflikter så mycket som möjligt, detta eftersom källkontrollsystemen har begränsningar i fråga om hur sammanslagningar ska utföras. Vi rekommenderar att du undviker situationer där flera personer utför ändringar i komplexa komponenter t.ex. formulär, flöden och arbetsyteappar på samma gång.
Mer information: Scenario 5: Support för teamutveckling
Löpande integrering och distribution
Du kan använda alla källstyrsystem och skapa upp en pipeline för att börja med fortlöpande integrering och distribution (CI/CD). Den här guiden fokuserar emellertid på GitHub och Azure DevOps. GitHub är en utvecklingsplattform som används av miljoner utvecklare. Azure DevOps tillhandahåller utvecklingstjänster till supportteam som låter dessa planera arbete, samarbeta med kodutveckling, samt skapa och distribuera program.
Du behöver följande för att komma igång:
Ett GitHub-konto där du kan skapa en lagringsplats. Om du inte har någon sådan nu kan du skapa en kostnadsfritt.
En Azure DevOps-organisation. Om du inte har någon sådan nu kan du skapa en kostnadsfritt.
Mer information: Skapa din första pipeline
Licensiering
För att kunna skapa eller redigera program och flöden med hjälp av Power Apps och Power Automate måste användarna ha en användarlicens för Power Apps eller Power Automate, eller en lämplig Dynamics 365-programlicens. Mer information finns i Licensöversikt för Microsoft Power Platform. Vi rekommenderar också att du kontaktar din representant för Microsoft-kontot och diskuterar dina licensbehov.
ALM-överväganden
När du betraktar ALM som en vital del av att skapa program i Microsoft Power Platform kan det drastiskt förbättra programmets hastighet, pålitlighet och användarupplevelse. Det ser också till att flera utvecklare, både traditionella utvecklare som skriver kod och civila utvecklare, kan bidra till det program som byggs.
I följande artiklar diskuteras flera saker som du bör tänka på när en programutveckling påbörjas: