Grundlæggende om ALM med Microsoft Power Platform
I denne artikel beskrives de komponenter, værktøjer og processer, der er nødvendige for at implementere ALM (Application Lifecycle Management).
Miljøer
Miljøer er et område til at gemme, administrere og dele din organisations forretningsdata, apps og forretningsprocesser. De fungerer også som objektbeholdere, der kan adskille apps, der kan have forskellige roller, sikkerhedskrav eller målgrupper. De enkelte miljøer kan kun have én Microsoft Dataverse-database. Du kan finde flere oplysninger i: Oversigt over miljøer
Vigtigt
Når du opretter et miljø, kan du vælge at installere Dynamics 365-apps, f.eks. Dynamics 365 Sales og Dynamics 365 Marketing. Det er vigtigt at finde ud af, om disse apps er påkrævede, fordi de kan ikke fjernes og geninstalleres på et senere tidspunkt. Hvis du ikke er afhængig på disse apps, og du ikke har brug for dem fremover, anbefales det, at du ikke installerer dem i dine miljøer. Det hjælper med at undgå afhængighedskomplikationer, når du distribuerer løsninger mellem forskellige miljøer.
Typer af miljøer, der bruges i ALM
Ved hjælp af Power Platform Administration kan du oprette disse typer Power Platform-miljøer:
Sandkasse Et sandkassemiljø er et hvilket som helst ikke-produktionsmiljø i Dataverse. Et sandkassemiljø, der er isoleret fra produktionen, er et sikkert sted at udvikle og teste programændringer. Sandkassemiljøer inkluderer funktioner, som ville være skadelige i et produktionsmiljø, f.eks. nulstillings-, sletnings- og kopieringshandlinger. Du kan få flere oplysninger under Administrere sandkassemiljøer
Produktion Det miljø, hvor apps og anden software implementeres i overensstemmelse med deres hensigt.
Udvikler (formelt kaldet Community). Power Apps-udviklerplan giver dig adgang til premium Power Apps-funktionalitet, Dataverse og Power Automate til individuel brug. Planen er primært beregnet til opbygning og test med Power Apps, Power Automate og Microsoft Dataverse eller med henblik på læring. Et udviklermiljø er et miljø for en enkelt bruger og kan ikke bruges til at køre eller dele produktionsapps.
Standard Der oprettes automatisk et enkelt standardmiljø for hver lejer, og det deles af alle brugere i denne lejer. Lejeren identificerer kunden, som kan have et eller flere Microsoft-abonnementer og -tjenester knyttet til den. Hver gang en ny bruger tilmelder sig Power Apps, føjes den pågældende automatisk til rollen Opretter i standardmiljøet. Standardmiljøet oprettes i det område, der er nærmest standardområdet for Microsoft Entra-lejeren og navngives: "{navn på Microsoft Entra-lejer} (standard)"
Opret og brug det rette miljø til et bestemt formål, for eksempel udvikling, test eller produktion.
Der er flere oplysninger om miljøer i Oversigt over miljøer.
Hvem skal have adgang?
Definer og administrer sikkerheden for dine ressourcer og data i Microsoft Dataverse. Microsoft Power Platform tildeler administratorroller på miljøniveau for at udføre opgaver. Dataverse indeholder sikkerhedsroller, der definerer det adgangsniveau til apps, appkomponenter og ressourceapps, som producenter og brugere har i Dataverse.
| Miljøformål | Roller, der har adgang | Kommentarer |
|---|---|---|
| Udvikling | App-producenter og -udviklere. | Appbrugere skal ikke have adgang. Udviklere skal som minimum kræve sikkerhedsrollen som miljøopretter for at oprette ressourcer. |
| Test | Administratorer og personer, der tester. | App-producenter og -udviklere samt brugere af produktionsapps skal ikke have adgang. Testbrugere skal have tilstrækkelige rettigheder til at udføre testen. |
| Produktion | Administratorer og appbrugere. Brugere skal have tilstrækkelig adgang til at udføre deres opgaver for de apps, de bruger. | App-producenter og -udviklere skal ikke have adgang, eller de bør kun have rettigheder på brugerniveau. |
| Standard | Som standard kan alle brugere i lejeren oprette og redigere apps i et Dataverse-standardmiljø, der har en database. | Vi anbefaler på det kraftigste, at du opretter miljøer til bestemte formål og kun tildeler de nødvendige roller og rettigheder til de personer, der har brug for dem. |
Flere oplysninger:
- Oversigt over miljøer
- Styre brugeradgang til miljøer: sikkerhedsgrupper og licenser
- Oprette brugere og tildele sikkerhedsroller
- Oprette miljøer
Løsninger
Løsninger bruges til transportere apps og komponenter fra et miljø til et andet eller til at anvende et sæt tilpasninger på eksisterende apps.
Løsningerne indeholder følgende funktioner:
De indeholder metadata og visse objekter med konfigurationsdata. Løsninger indeholder ingen virksomhedsdata.
De kan indeholde mange forskellige Microsoft Power Platform-komponenter, f.eks. modelbaserede apps, lærredsapps, oversigter over websted, flow, objekter, formularer, brugerdefinerede forbindelser, webressourcer, gruppede indstillinger, diagrammer og felter. Bemærk, at det ikke er alle objekter, der kan inkluderes i en løsning. Systemtabellerne Programbruger, Brugerdefineret API og Organisationsindstilling kan f.eks. ikke føjes til en løsning.
De pakkes sammen som en enhed, der skal eksporteres og importeres i andre miljøer, eller de kan dekonstrueres og indføres i kildekontrol som kildekode for aktiver. Løsninger bruges også til at anvende ændringer på eksisterende løsninger.
Administrerede løsninger bruges til at installere i alle miljøer, der ikke er et udviklingsmiljø for den pågældende løsning. Dette omfatter test, brugeraccepttest (UAT), test af systemintegration (SID) og produktionsmiljøer. Administrerede løsninger kan betjenes (opgradres, fejlrettes og slettes) uafhængigt af andre administrerede løsninger i et miljø. Som en bedste praksis for ALM bør administrerede løsninger genereres af en build-server og betragtes som en build-artefakt.
Opdateringer til en administreret løsning installeres på den tidligere version af den administrerede løsning. Derved oprettes der ikke et ekstra løsningslag. Du kan ikke slette komponenter ved hjælp af en opdatering.
En programrettelse indeholder kun ændringerne for en overordnet administreret løsning. Du skal kun bruge programrettelser, når du foretager mindre opdateringer (i stil med et hotfix), og du skal have mulighed for at fjerne dem. Når programrettelser importeres, placeres de i lag oven på den overordnede løsning. Du kan ikke slette komponenter ved hjælp af en programrettelse.
Hvis du opgraderer en løsning, installeres der et nyt løsningslag umiddelbart over det basislag og eventuelle eksisterende programrettelser.
Hvis du anvender løsningsopgraderinger, skal du slette alle eksisterende programrettelser og basislaget.
Løsningsopgraderinger sletter de komponenter, der fandtes, men som ikke længere er inkluderet i den opgraderede version.
Flere oplysninger: Løsningskoncepter
Kildekontrol
Kildekontrol, der også kaldes versionskontrol, er et system, som vedligeholder og på en sikker måde lagrer aktiver til softwareudvikling og sporer ændringer af disse aktiver. Ændringssporing er især vigtig, når flere app-producenter og -udviklere arbejder på det samme sæt filer. Et kildekontrolsystem giver dig også mulighed for at annullere ændringer eller gendanne slettede filer.
Et kildekontrolsystem hjælper organisationer med at opnå en sund ALM, da de aktiver, der vedligeholdes i kildekontrolsystemet, er en "faktakilde" - eller med andre ord det eneste adgangs- eller ændringspunkt for dine løsninger.
Forgrenings- og flettestrategi
Næsten alle kildekontrolsystemer understøtter en form for forgrening og fletning. Forgrening betyder, at du afviger fra det primære udviklingsområde og fortsætter med at arbejde uden at ændre det primære område. Fletningsprocessen består i at kombinere én gren med en anden, f.eks. fra en udviklingsgren til en primær områdeforgrening. Nogle af de almindelige forgreningsstrategier er trunk-baseret forgrening, versionforgrening og funktionsforgrening. Flere oplysninger: Indføre Git-forgreningsstrategi
Kildekontrolproces, der bruger en løsning
Du kan bruge to hovedforløb, når du arbejder med løsninger i et kildekontrolsystem:
- Eksportér den ikke-administrerede løsning, og anbring den upakket i kildekontrolsystemet. I buildprocessen importeres den pakkede løsning som ikke-administreret til et midlertidigt buildmiljø (sandkassemiljø). Eksportér derefter løsningen som administreret, og gem den som en buildartefakt i kildekontrolsystemet.
- Eksportér løsningen som ikke-administreret, og eksportér løsningen som administreret, og anbring dem begge i kildekontrolsystemet. Selvom denne metode ikke kræver et buildmiljø, kræver det, at der opretholdes to kopier af alle komponenter (en kopi af alle ikke-administrerede komponenter fra den ikke-administrerede løsning og en kopi af alle administrerede komponenter fra den administrerede løsning).
Flere oplysninger: Build-værktøjsopgaver
Automatisering
Automatisering er en vigtig del af programmets livscyklus, som øger produktiviteten, pålideligheden, kvaliteten og effektiviteten af ALM. Automatiseringsværktøjer og -opgaver bruges til at validere, eksportere, pakke, udpakke og eksportere løsninger samt til at oprette og nulstille sandkassemiljøer.
Flere oplysninger: Hvad er Microsoft Power Platform Build Tools?
Teamudvikling ved hjælp af delt kildekontrol
Det er vigtigt, at du overvejer, hvordan du og dit udviklingsteam kan arbejde sammen om at bygge projektet. Hvis du opdeler siloer og opfordrer til visninger og samtaler, kan det give dit team mulighed for at levere bedre software. Nogle værktøjer og arbejdsprocesser - f.eks. dem, der findes i Git, GitHub og Azure DevOps - er udviklet med henblik på at forbedre kvaliteten af kommunikation og software. Bemærk, at arbejdet med konfigurationer i et løsningssystem kan skabe udfordringer for teamets udvikling. Organisationer skal organisere ændringer fra flere udviklere for at undgå at flette konflikter så meget som muligt, da kildekontrolsystemer har begrænsninger på, hvordan fletninger finder sted. Det anbefales, at du undgår situationer, hvor flere personer foretager ændringer af komplekse komponenter - f.eks. formularer, flow og lærredsapps - på samme tid.
Flere oplysninger: Scenarie 5: Understøttelse af teamudvikling
Kontinuerlig integration og udrulning
Du kan bruge et hvilket som helst kildekontrolsystem og oprette en pipeline for at komme i gang med kontinuerlig integration og kontinuerlig distribution (CI/CD). I denne vejledning fokuseres der dog på GitHub og Azure DevOps. GitHub er en udviklingsplatform, der bruges af millioner af udviklere. Azure DevOps tilbyder udviklingstjenester til supportteams, så de kan planlægge arbejde, samarbejde om kodeudvikling samt opbygge og installere applikationer.
Du skal bruge følgende for at komme i gang:
En GitHub-konto, hvor du kan oprette et lager. Hvis du ikke har en, kan du oprette en gratis.
En Azure DevOps-organisation. Hvis du ikke har en, kan du oprette en gratis.
Flere oplysninger: Oprette din første pipeline
Licenser
For at oprette eller redigere apps og flow ved hjælp af henholdsvis Power Apps og Power Automate skal brugere have en licens pr. bruger til Power Apps eller Power Automate eller en relevant Dynamics 365-programlicens. Du kan finde flere oplysninger i Licensoversigt for Microsoft Power Platform. Vi anbefaler også, at du kontakter din Microsoft-salgsrepræsentant for at diskutere dine licensbehov.
Overvejelser om ALM
Når du overvejer ALM som en integreret del af udvikling af apps på Microsoft Power Platform, kan det betyde en stor forbedring af hastigheden, pålideligheden og brugeroplevelsen af appen. Det er også med til at sikre, at flere udviklere – både traditionelle udviklere, der skriver kode, og borgerudviklere – sammen kan bidrage sammen til det program, der bygges.
Se følgende artikler, der indeholder en gennemgang af flere ting, du kan overveje som udgangspunkt for udvikling af programmer: