Grunnleggende om ALM med Microsoft Power Platform
Denne artikkelen beskriver komponentene, verktøyene og prosessene som kreves for å implementere behandling av applivssyklus (ALM).
Miljøer
Et miljø er et sted der du kan lagre, behandle og dele organisasjonens forretningsdata, apper og forretningsprosesser. De fungerer også som beholdere for å skille apper som kan ha ulike roller, sikkerhetskrav eller målgrupper. Hvert miljø kan bare ha én Microsoft Dataverse-database. Mer informasjon: Oversikt over miljøer
Viktig
Når du oppretter et miljø, kan du velge å installere Dynamics 365-apper, for eksempel Dynamics 365 Sales og Dynamics 365 Marketing. Det er viktig å finne ut om disse appene kreves eller ikke, fordi de ikke kan avinstalleres eller installeres senere. Hvis du ikke bygger på disse appene og ikke trenger dem i fremtiden, anbefaler vi at du ikke installerer dem i miljøene dine. Dette vil hjelpe deg med å unngå avhengighetskomplikasjoner når du distribuerer løsninger mellom miljøer.
Typer miljøer som brukes i ALM
Ved hjelp av Power Platform-administrasjonssenteret kan du opprette disse typene Power Platform-miljøer:
Sandkasse Et sandkassemiljø er et hvilket som helst ikke-produksjons miljø i Dataverse. Sandkassemiljøet er isolert fra produksjon og er stedet der du trygt kan utvikle og teste programendringer med lav risiko. Sandkassemiljøer inneholder funksjoner som kan være skadelige i et produksjonsmiljø, for eksempel tilbakestilling, sletting og kopieringsoperasjoner. Mer informasjon: Administrere sandkassemiljøer
Produksjon Miljøet der apper og annen program vare befinner seg for den tiltenkte bruken.
Utvikler (formelt kalt Community). Power Apps-utviklerplanen gir deg tilgang til førsteklasses Power Apps-funksjonalitet, Dataverse og Power Automate for individuell bruk. Denne planen er primært ment for å bygge og teste med Power Apps, Power Automate og Microsoft Dataverse eller for læringsformål. Et utviklingsmiljø er et miljø med én bruker, og det kan ikke brukes til å kjøre eller dele produksjonsapper.
Standard Ett enkelt standardmiljø blir automatisk opprettet av for hver tenant og deles av alle brukerne i denne leietakeren. Leieren identifiserer kunden, som kan ha ett eller flere Microsoft-abonnementer og -tjenester tilknyttet seg. Når en ny bruker registrerer seg for Power Apps, legges vedkommende til automatisk med rollen Oppretter for standardmiljøet. Standardmiljøet opprettes i det nærmeste området til standardområdet for Microsoft Entra-leieren og får følgende navn: "{Microsoft Entra-leiernavn} (standard)"
Opprett og bruk det riktige miljø for et bestemt formål, for eksempel utvikling, testing eller produksjon.
Hvis du vil ha mer informasjon om miljøer, kan du se Oversikt over miljøer.
Hvem skal ha tilgang?
Definer og administrer sikkerheten til ressurser og data i Microsoft Dataverse. Microsoft Power Platform inneholder administratorroller på miljønivå for å utføre oppgaver. Dataverse inneholder sikkerhetsroller som definerer tilgangsnivået til apper, appkomponenter og ressurser som apputviklere og brukere har i Dataverse.
| Miljøformål | Roller som har tilgang | Kommentarer |
|---|---|---|
| Utvikling | Appskrivere og -utviklere. | Appbrukere skal ikke ha tilgang. Utviklere må ha minst sikkerhetsrollen som miljøoppretter for å opprette ressurser. |
| Test | Administratorer og personer som tester. | Appopprettere, -utviklere og produksjonsappbrukere skal ikke ha tilgang. Testbrukere bør ha akkurat tilstrekkelige rettigheter til å utføre testing. |
| Produksjon | Administratorer og appbrukere. Brukere bør ha akkurat nok tilgang til å utføre oppgavene sine for appene de bruker. | Appopprettere og -utviklere bør ikke ha tilgang, eller de bør bare ha rettigheter på brukernivå. |
| Standard | Hver bruker i leieren din kan som standard opprette og redigere apper i et Dataverse-standardmiljø som har en database. | Vi anbefaler på det sterkeste at du oppretter miljøer for et bestemt formål og gir de aktuelle rollene og rettighetene bare til de som har behov for dem. |
Mer informasjon:
- Oversikt over miljøer
- Styre brukertilgangen til miljøer: sikkerhetsgrupper og lisenser
- Opprett brukere og tilordne sikkerhetsroller
- Opprette miljøer
Løsninger
Løsninger brukes til å transportere apper og komponenter fra ett miljø til et annet, eller for å bruke et sett med tilpassinger til eksisterende apper.
Løsninger har disse egenskapene:
De inkluderer metadata og bestemte enheter med konfigurasjonsdata. Løsninger inneholder ikke forretningsdata.
De kan inneholde mange ulike Microsoft Power Platform-komponenter, for eksempel modelldrevne apper, lerretsapper, områdekart, flyter, enheter, skjemaer, egendefinerte koblinger, webressurser, alternativsett, diagrammer og felt. Vær oppmerksom på at ikke alle enheter kan tas med i en løsning. Systemtabellene Programbruker, Egendefinert API og Organisasjonsinnstilling kan for eksempel ikke legges til i en løsning.
De er pakket som en enhet som skal eksporteres og importeres til andre miljøer, eller demonteres og sjekkes inn i kildekontrollen som kildekode for aktiva. Løsninger brukes også til å gjøre endringer i eksisterende løsninger.
Administrerte løsninger brukes til å distribuere til et hvilket som helst miljø som ikke er et utviklingsmiljø for den løsningen. Dette inkluderer test, brukergodkjenningstesting (UAT), testing av systemintegrering (SIT) og produksjonsmiljøer. Administrerte løsninger kan betjenes (oppgradering, patching og sletting) uavhengig av andre administrerte løsninger i et miljø. Som en ALM beste praksis bør administrerte løsninger genereres av en Build-server og anses som en Build-artefakt.
Oppdateringer til en administrert løsning distribueres til den forrige versjonen av den administrerte løsningen. Dette oppretter ikke et ekstra løsningslag. Du kan ikke slette komponenter ved hjelp av en oppdatering.
En patch inneholder bare endringene for en overordnet administrertløsning. Du bør bare bruke patcher når du utfører små oppdateringer (på samme måte som en hurtigreparasjon), og den må kanskje avinstalleres. Når reparasjoner importeres, blir de lagt lagvis oppå den overordnede løsningen. Du kan ikke slette komponenter ved hjelp av en patch.
Oppgradering av en løsning installerer et nytt løsningslag umiddelbart over bakgrunnslaget og eventuelle eksisterende patcher.
Bruk av løsningsoppgraderinger omfatter sletting av alle eksisterende patcher og bakgrunnslaget.
Løsningsoppgraderinger vil slette komponenter som eksisterte, men som ikke lenger er inkludert i den oppgraderte versjonen.
Mer informasjon: Løsningskonsepter
Kildekontroll
Kildekontroll, også kjent som versjonskontroll, er et system som vedlikeholder og sikkert lagrer ressurser for programvareutvikling, og som sporer endringer for disse ressursene. Sporing av endringer er spesielt viktig når flere appopprettere og -utviklere arbeider med samme filsett. Et kildekontrollsystem gir deg også muligheten til å rulle tilbake endringer eller gjenopprette slettede filer.
Et kildekontrollsystem hjelper organisasjoner med å oppnå sunn ALM fordi ressursene som opprettholdes i kildekontrollsystemet, er den "eneste sannhetskilden", eller med andre ord det eneste tilgangspunktet og den eneste endringen for løsningene.
Forgrenings- og sammenslåingsstrategi
Omtrent hvert eneste kildekontrollsystem har en form for forgrening og sammenslåing av støtte. Forgrening betyr at du går bort fra hovedutviklingslinjen og fortsetter å arbeide uten å endre hovedlinje. Sammenslåing består av å kombinere én gren med en annen, for eksempel fra en utviklingsgren til en hovedgren i en hovedlinje. Noen vanlige grener for forgrening er stammebasert forgrening, frigivelse av forgrening og funksjonsforgrening. Mer informasjon: Ta i bruk en Git-forgreningsstrategi
Kildekontrollprosess ved hjelp av en løsning
Du er to hovedbaner som du kan bruke når du arbeider med løsninger i et kildekontrollsystem:
- Eksporter den uadministrerte løsningen, og plasser den som utpakket i kildekontrollsystemet. Byggeprosessen importerer den pakkede løsningen som uadministrert til et midlertidig byggemiljø (sandkassemiljø). Deretter kan du eksportere løsningen som administrert og lagre den som en byggartefakt i kildekontrollsystemet.
- Eksporter løsningen som uadministrert, og eksporter også løsningen som administrert, og plasser begge i kildekontrollsystemet. Selv om denne metoden ikke krever et byggmiljø, krever den at to kopier av alle komponenter beholdes (én kopi av alle uadministrerte komponenter fra den uadministrerte løsningen og én kopi av alle administrerte komponenter fra den administrerte løsningen).
Mer informasjon: Oppgaver for byggverktøy
Automatisering
Automatisering er en viktig del av applivssyklusen som forbedrer produktiviteten, påliteligheten, kvaliteten og effektiviteten til ALM. Automatiseringsverktøy og -oppgaver brukes til å validere, eksportere, pakke, pakke ut og eksportere løsninger, i tillegg til å opprette og tilbakestille sandkassemiljøer.
Mer informasjon: Hva er Microsoft Power Platform Build Tools?
Teamutvikling med delt kildekontroll
Det er viktig å vurdere hvordan du og utviklingsteamet skal jobbe sammen for å bygge prosjektet. Hvis du bryter ned siloer og fremmer visninger og diskusjoner, kan teamet levere bedre programvare. Enkelte verktøy og arbeidsflyter, for eksempel de som finnes i Git, GitHub og Azure DevOps, er utformet utelukkende for forbedret kommunikasjon og programvarekvalitet. Vær oppmerksom på at arbeid med konfigurasjoner i et løsningssystem kan skape utfordringer for teamutvikling. Organisasjoner må arrangere endringer fra flere utviklere for å unngå sammenslåingskonflikter så mye som mulig, siden kildekontrollsystemer har begrensninger for hvordan sammenslåinger foregår. Vi anbefaler at du unngår situasjoner der flere personer gjør endringer i komplekse komponenter, for eksempel skjemaer, flyter og arbeidsområder, samtidig.
Mer informasjon: Scenario 5: Støtte teamutvikling
Kontinuerlig integrasjon og distribusjon
Du kan bruke et hvilket som helst kildekontrollsystem og bygge et datasamlebånd for å starte med kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD). Denne veiledningen fokuserer imidlertid på GitHub og Azure DevOps. GitHub er en utviklingsplattform som brukes av millioner av utviklere. Azure DevOps inneholder utviklingstjenester for støtteteam for å planlegge arbeid, samarbeide på kodeutvikling og utvikle og distribuere apper.
Du trenger følgende for å komme i gang:
En GitHub-konto, der du kan opprette et repositorium. Hvis du ikke har en, kan du opprette en gratis.
En Azure DevOps-organisasjon. Hvis du ikke har en, kan du opprette en gratis.
Mer informasjon: Opprette ditt første datasamlebånd
Lisensiering
Hvis du vil opprette eller redigere apper og flyter ved hjelp av henholdsvis Power Apps og Power Automate, må brukerne ha en per-bruker-lisens for Power Apps eller Power Automate eller en passende Dynamics 365-applisens. For mer informasjon, se Lisensieringsoversikt for Microsoft Power Platform. Vi anbefaler også at du kontakter representanten for Microsoft-kontoen din for å diskutere lisensieringsbehovene dine.
ALM-vurderinger
Når du vurderer ALM som en integrert del av utvikling av apper på Microsoft Power Platform, kan dette drastisk forbedre hastigheten, påliteligheten og brukeropplevelsen til appen. Det sikrer også at flere utviklere, både tradisjonelle utviklere som skriver kode og offentlige utviklere, kan bidra til appen som utvikles.
Se følgende artikler som drøfter flere elementer som må vurderes ved begynnelsen av utviklingen av enhver app: