Utvikle en miljøstrategi for leieren for å ta i bruk Power Platform i stor skala
Enhver organisasjons reise for å ta i bruk Microsoft Power Platform er unik. En leiermiljøstrategi legger grunnlaget for å fremskynde bruken på en håndterlig og sikker måte.
Dette tekniske dokumentet viser deg hvordan du justerer Power Platform-leiermiljøstrategien etter produktfunksjonene og visjonen. Du lærer hvordan du best kan bruke de nyeste funksjonene på plattformen til å implementere en strategi som kan bidra til at innføringen din av Power Platform når bedriftsskalaen.
Merk
Du kan lagre eller skrive ut dette tekniske dokumentet ved å velge Skriv ut fra nettleseren og deretter velge Lagre som PDF.
Innledning
Power Platform gir organisasjoner mulighet til å bygge lavkodeløsninger for rask nyskapning. Disse løsningene kan fokusere på produktivitet for enkeltpersoner og små team, eller gjelde på tvers av organisasjonen. De kan også utvides til forretningsprosesser, inkludert eksterne kunder og partnere. Disse løsningene støttes av Power Platform-miljøer, der lavkoderessurser bygges, testes og brukes. Etter hvert som en organisasjon øker bruken av Power Platform, er det viktig å implementere en god leiermiljøstrategi for å gjøre det håndterbart og sikkert etter hvert som antallet miljøer vokser.
Denne artikkelen hjelper deg med å lykkes best mulig ved å bruke funksjonene som er tilgjengelige, til å etablere din første miljøstrategi eller utvikle de gjeldende planene dine. Vi har også skissert vår visjon på hvordan disse funksjonene er ment å fungere sammen, og hvordan de vil utvikle seg for administrasjon av Power Platform i stor skala. I denne veiledningen fastsetter vi hvordan nye brukere skal rutes riktig til miljøer og gruppemiljøer, slik at de konsekvent kan bruke styring, sikkerhetsregler og andre viktige aspekter ved en leiermiljøstrategi. Vi viser også detaljerte trinn for å sikre standardmiljøet, som er et viktig første trinn i implementeringen av en miljøstrategi.
Selv om mange Perspektiver er tilgjengelige for administrasjon Power Platform av miljøer, er tilnærmingen i denne artikkelen i tråd med Microsoft den nyeste produktretningen og bruker gjeldende funksjoner og planlagte forbedringer på kort sikt. Denne oppdaterte veiledningen kan hjelpe deg med å sikre at du bare bruker miljøfunksjonene og -alternativene som er strategiske for hvordan Microsoft du har tenkt å administrere miljøer i stor skala.
Microsofts strategi for leietakermiljø
Mange organisasjoner starter Power Platform-reisen med personlige produktivitetsapper og automatiseringer som er bygd og kjører i et delt sentralt miljø, kalt for standardmiljøet. Disse ressursene bruker ofte bare de grunnleggende funksjonene som følger med Microsoft 365, og de bruker ikke alle funksjonene i Power Platform. Etter hvert som denne første innføringen akselererer, Microsoft gir organisasjoner en rampe til en miljøstrategi for innføring av alle Power Platform funksjonene i bedriftsskala. Disse Premium-styringsfunksjonene blir tilgjengelige når brukere har en Premium-lisens for Power Platform (Power Apps, Power Automate Microsoft Copilot Studio og Dynamics 365). Modenhetsmodellen for Power Platform-innføring kan gi mer innsikt for å hjelpe organisasjoner med å definere veikartet for å oppnå innføring i bedriftsskala utover miljøstrategien. Denne tilnærmingen kan hjelpe organisasjoner med å modne fra grunnleggende personlig produktivitet til innføring av Power Platform i bedriftsskala.
Power Platform-funksjoner for administrasjon, styring og sikkerhet gjør det mulig for organisasjoner å ta i bruk og administrere Power Platform for bedriftsproduktivitet og bruk av bedriftsapper i stor skala. Bruk av administrerte miljøer aktiverer et sett med Premium-funksjoner som gir bedre synlighet og kontroll og reduserer den manuelle innsatsen for å administrere og sikre miljøer. Ved hjelp av disse funksjonene kan du sikre konsekvent bruk av styrings- og sikkerhetspolicyer. Administratorer kan gå over til en miljøstrategi i bedriftsskala ved hjelp av disse funksjonene. Mindre tid og innsats brukt på administrasjon bidrar til å redusere de totale totale eierkostnadene for plattformen etter hvert som organisasjonen skalerer bruken.
Et viktig element i overgang til bedriftsskala er å forbedre den delte, sentrale miljøstrategien for opprettere ved å gjøre det enklere for dem å bruke personlige utviklingsmiljøer. I en delt, sentral miljøstrategi bygger, bruker og deler opprettere apper i standardmiljøet. Denne strategien kan føre til mangel på isolasjon og at opprettere kommer for tett inn på hverandre. Tenk deg om alle i firmaet delte én OneDrive-mappe for alle dokumentene sine. I stedet kan du bruke miljøfunksjoner til å veilede opprettere til sitt eget personlige miljø, der de trygt kan bygge apper beskyttet mot opprettere som arbeider med urelaterte ressurser, med forenklet styring for administratorer. Kolleger kan legges til som flere opprettere i disse miljøene for å samarbeide om å bygge løsninger.
Figur: Illustrasjon av et delt, sentralt miljø (til venstre) og en miljørutingsstrategi (til høyre).
Nylig opprettede opprettermiljøer kan legges til automatisk i en gruppe som bruker regler for å sikre at miljøene har konsekvente styrings- og sikkerhetspolicyer. Administratorer kan håndtere unntak ved å flytte en oppretters miljø til en gruppe med mindre strenge regler.
Lavkoderessurser som opprettes av oppretterne, representerer den første fasen i administrasjonen av programlivssyklus (ALM) for en ressurs. Som en del av denne innledende fasen er det viktig å registrere hver versjon av en ressurs og kunne opprette den på nytt om nødvendig. Når ressursen er klar til å deles, kan oppretteren bruke den kontinuerlige integrasjonen som er knyttet til utviklermiljøet, til å forfremme den til et produksjonsmiljø, der brukerne kan kjøre ressursen isolert fra alle pågående oppretteraktiviteter.
Du bør prioritere de innebygde funksjonene i plattformen for administrasjon av miljøer når det er mulig, i stedet for å bygge dine egne verktøy. Hvis de innebygde funksjonene ikke oppfyller de unike kravene til organisasjonen, kan du bruke plattformadministrasjonsverktøy til å opprette egendefinerte verktøy. Du bør evaluere eventuelle egendefinerte verktøy mot nye funksjoner etter hvert som de blir tilgjengelige. Å holde øye med Microsoft plattformens veikart og vedlikeholde ditt eget veikart kan bidra til å gjøre dette enklere.
Du bør etablere miljøstrategien ved hjelp av de anbefalte miljøfunksjonene som er skreddersydd for organisasjonens spesielle behov. Ikke tenk på å opprette miljøstrategien som en engangsaktivitet. Den bør utvikles over tid for å innlemme nye miljøfunksjoner etter hvert som de blir tilgjengelige.
Funksjoner som støtter en miljøstrategi i bedriftsskala
Miljøer er en byggeblokk for Power Platform administrasjon, styring og sikkerhet. En fullstendig funksjonsoversikt er utenfor omfanget til dette dokumentet. Denne delen fremhever imidlertid funksjonene som støtter implementering av en miljøstrategi i bedriftsskala.
Miljøtyper beskriver de ulike bruksområdene for miljøer som en del av strategien.
administrerte miljøer gir et sett med førsteklasses funksjoner som gjør miljøer enklere å administrere i stor skala.
Automatisk lisenskrav forenkler lisenstilordning ved å la brukere gjøre krav Power Apps på per bruker-lisenser når de er nødvendige, i stedet for å kreve at en administrator identifiserer brukere som trenger lisenser på forhånd.
Miljøgrupper og -regler forklarer hvordan du administrerer miljøer som grupper og bruker regler på grupper for å automatisere konsekvente styringspolicyer.
Standard miljøruting flytter automatisk utviklere bort fra å opprette ressurser i standardmiljøet til sitt eget, personlige miljø.
Microsoft Dataverse gir forbedret sikkerhet og ALM.
Foretrukne løsninger hjelper utviklere med å sikre at alle ressursene de bygger, er i en Dataverse løsning, noe som gjør det enklere å heve nivå dem til andre miljøer.
Pipeliner i Power Platform gir en forenklet prosess for å promotere ressurser fra utviklings- til test- og produksjonsmiljøer, noe som gjør kontinuerlig integrasjon og distribusjon (CI/CD) tilgjengelig for alle utviklere.
Katalog i Power Platform gjør det mulig for utviklere å dele komponenter, for eksempel apper og flyter, og mer avanserte startpunkter, for eksempel maler.
Miljøtyper
Tabellen nedenfor beskriver hvilke typer miljøer du kan opprette, deres egenskaper og tiltenkte bruk.
| Type | Kjennetegn og bruksområder |
|---|---|
| Standard | Miljøet som følger med hver leier. Mange Microsoft 365-opplevelser bruker dette miljøet til tilpassinger og automatiseringer. Dette miljøet er ikke ment for langtidsarbeid eller permanent arbeid utover de personlige Microsoft 365-produktivitetsscenarioene. |
| Produksjon | Dette miljøet er ment å brukes for permanent arbeid i en organisasjon. Produksjonsmiljøer støtter utvidet sikkerhetskopioppbevaring, fra sju dager til opptil 28 dager. |
| Sandkasse | Disse ikke-produksjonsmiljøene støtter miljøhandlinger som kopier og tilbakestill. Sandkasser brukes best til testing og ALM-build-miljøer. |
| Developer | Disse spesielle miljøene er ment som oppretternes personlige arbeidsområder for utvikling, som isolerer lavkoderessurser fra brukere og andre opprettere. Opprettere kan ha opptil tre utviklermiljøer. De teller ikke med i leierkapasiteten. Utviklermiljøer som ikke har vært brukt på 90 dager, blir automatisk slått av og fjernet fra leieren hvis eieren ikke svarer på varsler. Dynamics 365-apper er ikke tilgjengelige i utviklermiljøer. |
| Prøveabonnement | Disse miljøene er ment å støtte kortsiktig testing og konseptgodkjenning. De er begrenset til ett per bruker. Prøvemiljøer fjernes automatisk fra leieren etter en kort tidsperiode. |
| Microsoft Dataverse for Teams | Disse miljøene opprettes automatisk når du oppretter en app i Teams eller installerer en app fra appkatalogen. Sikkerhetsmodellen for disse miljøene er tilpasset teamet de er knyttet til. |
| Støtte | Dette er spesielle miljøer opprettet av Microsoft kundestøtte for å tillate teknikere å feilsøke problemer. Disse miljøene teller ikke med i leierkapasiteten. |
Etter hvert som du setter sammen en generell leiermiljøstrategi, er de ulike typene relevante for å støtte strategianbefalingene.
Administrerte miljøer
Miljøer har et basissett med funksjoner og egenskaper avhengig av miljøtypen. Administrerte miljøer utvider basisfunksjonene for å gi en serie med Premium-funksjoner som gjør det mulig for administratorer å enklere administrere Power Platform i stor skala med mer kontroll, mindre innsats og mer innsikt. Disse funksjonene låses opp når du angir et miljø som administrert.
Følgende tabell viser funksjonene i administrerte miljøer som er tilgjengelige i skrivende stund. Nye funksjoner legges til ofte, så se i dokumentasjonen for den nyeste listen. Alle funksjonene kan hjelpe deg med å utvikle en miljøstrategi, men funksjonene i kursiv er mer relevante for strategien som beskrives i denne artikkelen.
| Mer synlighet | Mer kontroll | Mindre innsats |
|---|---|---|
| Innsikt i bruk Sammendrag av administratorer Lisens rapporter Datapolicyvisning Eksportere data til Azure Application Insights AI-genererte beskrivelser for alle apper |
Delingsgrenser Datapolicyer for skrivebordsflyter Kontroll av løsning Velkomstinnhold for skapere IP-brannmur Binding av IP-informasjonskapsler Kundeadministrerte nøkler Kundens nøkkelboks Utvidet sikkerhetskopiering |
Enkel aktivering Power Platform Rørledninger Ruting av miljø Miljøgrupper og regler Power Platform rådgiver |
Gjør krav på lisens automatisk
Policyer for automatisk krav automatiserer tildeling av Power Apps og Power Automate lisenser til brukere når de trenger lisenser for å bruke bestemte apper eller funksjoner. Automatisering kan bidra til å redusere antall lisenser som brukes og unngå at lisenser tilordnes manuelt.
Når en policy er konfigurert, får enhver bruker i organisasjonen som trenger en individuell Power Apps-lisens, en slik lisens under følgende betingelser:
Hvis en bruker uten en frittstående Power Apps-lisens åpner en app som krever en Premium-lisens, tilordner systemet automatisk brukeren en Power Apps per bruker-lisens.
Hvis en bruker uten en frittstående Power Apps-lisens åpner en app i et administrert miljø, tilordner systemet automatisk brukeren en Power Apps per bruker-lisens.
På samme måte når en policy er konfigurert, får enhver bruker i organisasjonen som trenger en individuell Power Automate-lisens, en slik lisens under følgende betingelser:
Brukeren utløser, lagrer eller aktiverer en Premium-skyflyt med overvåket RPA (robotautomatisering).
Brukeren ber om en Power Automate Premium-lisens.
Vi anbefaler at du konfigurerer automatisk lisenskrav hvis miljøstrategien omfatter administrerte miljøer. Brukere av apper og flyter opplever minst mulig lisensieringsfriksjon, og du bruker bare lisenser for brukere som aktivt kjører apper eller bruker Power Automate.
Miljøgrupper og regler
Etter hvert som Power Platform-innføringen i leieren økes, kan dette også gjelde for antallet miljøer som krever administrasjon og styring. Etter hvert som antall miljøer øker, jo mer utfordrende blir det å sikre at du har brukt konsekvente innstillinger og retningslinjer for styring av miljøene. Funksjonen for miljøgrupper gjør dette enklere ved at du kan opprette navngitte grupper og knytte miljøer til dem, for eksempel plassere relaterte dokumenter i en filmappe.
Husk på følgende når du tenker på bruk av miljøgrupper:
Et miljø må være administrert for å bli inkludert i en gruppe.
Et miljø kan bare være i én gruppe om gangen.
Et miljø kan flyttes fra én gruppe til en annen.
Miljøer i en gruppe kan komme fra flere geografiske områder.
Grupper kan ikke inneholde andre grupper.
Miljøgrupper kan ha én eller flere av følgende regler konfigurert og aktivert, slik at du kan bruke konsekvente innstillinger og styring:
Delingskontroller for lerretsapper
Innsikt i bruk
Velkomstinnhold for utvikler
Håndhevelse for løsningskontroll
Oppbevaring av sikkerhetskopier
Beskrivelser generert av kunstig intelligens
En regel blir aktiv når den publiseres. Aktive regler brukes på alle miljøer som er tilknyttet gruppen.
Når en grupperegel administrerer en innstilling, er individuelle miljøinnstillinger låst. Den eneste måten å endre dem på, er å endre regelen. Hvis miljøet fjernes fra gruppen, beholdes gruppeinnstillingene, men nå kan en miljøadministrator endre dem. Dette er viktig for en miljøstrategi fordi det sikrer at en miljøadministrator ikke kan overstyre policyene du angir for gruppen.
Ved hjelp av miljøgrupper kan du organisere miljøene på logiske måter, på samme måte som organisasjonsstrukturen, hierarkiet for produktservice eller andre rammeverk som vi utforsker senere. Følgende diagram er et begrepsmessig eksempel på hvordan Contoso-organisasjonen kan tenke på å organisere miljøgruppene.
Figur: Konseptualisering av en miljøstrategi for en Contoso-leier.
Når du skal planlegge reglene som skal konfigureres, må du tenke gjennom hva du kan bruke på hvert nivå i det begrepsmessige hierarkiet. Selv om du ikke kan konfigurere gruppehierarkiet ennå, kan du bruke en kombinasjon av navnekonvensjoner og regelkonfigurasjon til å implementere den begrepsmessige utformingen. Hvis for eksempel konseptualiseringen av Contoso-leieren vises tidligere, representerer illustrasjonen nedenfor miljøgruppene som organisasjonen kan bruke til å implementere utformingen.
Figur: Eksempel på implementering av de konseptuelle miljøgruppene i den faktiske leieren
Senere i denne artikkelen utforsker vi flere måter å bruke miljøgrupper på som en del av en leiermiljøstrategi.
Ruting av standardmiljø
En viktig del av miljøstrategien som vi skisserer i denne artikkelen, er å flytte opprettere bort fra å opprette ressurser i standardmiljøet. Funksjonen for miljøruting omdirigerer opprettere til et eget, personlig utviklingsmiljø og oppretter nye utviklermiljøer etter behov.
Figur: En utvikler omdirigeres automatisk til et personlig utviklermiljø i stedet for standardmiljøet når de bygger apper.
Utviklermiljøene som opprettes ved ruting, er administrerte som standard. Brukere med utviklerplanlisenser er begrenset til å opprette og forhåndsvise ressurser i miljøet. For å kjøre ressursene som en bruker, trenger de en egnet lisens.
Du kan bruke miljøruting separat, men den anbefalte måten er å bruke det med miljøgrupper. Når det brukes på denne måten, knyttes ethvert miljø som er opprettet, til gruppen du angir skal inneholde alle nye utviklermiljøer, noe som sikrer at det umiddelbart dekkes av dine styringspolicyer.
Opprettere får automatisk tilordnet en sikkerhetsrolle som gjør dem til miljøadministrator i utviklermiljøet. Når miljøet er en del av en miljøgruppe, kan ikke oppretteren – som miljøadministrator – endre miljøinnstillingene fordi de administreres av miljøgruppereglene. Bare administratorer, som kan endre gruppereglene, kan gjøre endringer.
Du kan pålegge enda mer kontroll på to måter. Først kan du nekte manuell oppretting av utviklermiljøer i leierinnstillingene. Når dette alternativet er angitt, kan ikke opprettere selv opprette miljøer i administrasjonsportalen. De får heller ikke opprettet automatisk et miljø av rutingsregelen. For det andre kan du angi en sikkerhetsgruppe i rutingsregelen for å begrense hvem som automatisk kan opprette et miljø.
Til å begynne med støtter miljøruting ruting av nye og eksisterende opprettere bort fra standardmiljøet når de bruker make.powerapps.com. Over tid vil andre Power Platform-tjenester støtte funksjonen for miljøruting.
Microsoft Dataverse
Dataverse lagrer og administrerer data som brukes av apper, på en sikker måte. I konteksten til en miljøstrategi er Dataverse-løsningsfunksjonen det du bruker til å transportere apper og komponenter fra ett miljø til et annet. Opprettere bygger ressurser i beholdere – løsninger – som sporer det de bygger. Løsninger kan enkelt transporteres til andre miljøer. Ved hjelp av denne metoden kan du skille utviklermiljøer, der opprettere bygger ressurser, fra produksjonsmiljøene der de brukes. Både opprettere og brukere drar nytte av dette. Opprettere kan fortsette å utvikle ressursene sine, og brukere blir ikke overrasket over plutselige endringer. Når oppretterne er klare til å publisere endringene, kan de be om å forfremme den oppdaterte ressursen til produksjonsmiljøet.
Dataverse-løsninger er mekanismen for implementering av ALM i Power Platform-produkter som Power Apps og Power Automate. Pipeliner i Power Platform bruker løsninger for å automatisere CI/CD av ressurser som opprettere bygger. Løsninger kan eksporteres fra Dataverse og lagres i et kildekontrollverktøy som Azure DevOps eller GitHub. Løsningen i kildekontrollen blir sannhetskilden hvis du må opprette utviklingsmiljøet på nytt. Hvis for eksempel en oppretter har bygd en populær app og deretter slettet utviklermiljøet, kan en eksportert løsning som er lagret i kildekontrollen, brukes til å opprette et aktuelt utviklingsmiljø på nytt.
En annen viktig vurdering når du oppretter et miljø med Dataverse, er om noen Dynamics 365-programmer skal distribueres til miljøet. Hvis det potensielle problemet finnes, må du aktivere Dynamics 365 når du oppretter miljøet, ellers kan du ikke installere Dynamics 365-apper senere.
Vi anbefaler at du klargjør Dataverse i alle miljøer der opprettere oppretter aktiva som vil bli delt med andre brukere. Dette gjør det enklere for aktivaene å være ALM-klare.
Foretrukne løsninger
Når en oppretter oppretter en Dataverse-ressurs i et Dataverse-miljø og ikke starter fra en tilpasset løsning, knyttes ressursen til standardløsningen og kanskje også Common Data Service-standardløsningen. Standardløsningen deles av alle opprettere som oppretter ressurser i miljøet. Det finnes ingen enkel måte å identifisere hvilken oppretter som opprettet hvilke komponenter eller hvilke ressurser som tilhører hvilke apper. Dette kan gjøre det vanskelig å forfremme en populær app til et annet miljø for deling med en større målgruppe. Du må forfremme alle ressurser i standardløsningen – ikke et ideelt scenario.
For å støtte miljøstrategien og gjøre det enklere å arbeide med den bør oppretter opprette en tilpasset løsning i utviklingsmiljøet og deretter angi den som den foretrukne løsningen i miljøet. Opprettere angir foretrukket løsning i et miljø for å angi hvilken løsning en ressurs de har opprettet, bør tilknyttes. Foretrukne løsninger kan bidra til å sikre at når opprettere bruker pipeliner til å forfremme ressursene sine til andre miljøer, inneholder den forfremmede løsningen alle de nødvendige ressursene. Tenk på dette som klargjøring av ressurser til å bli ALM-klar.
Pipeliner i Power Platform
Som vi har sett, er en viktig faktor i en god miljøstrategi å isolere der en ressurs bygges, fra der den distribueres og brukes. Denne separasjonen sikrer at brukere som prøver å bruke en ressurs, ikke opplever nedetid fordi en oppretter oppdaterer den. Dette krever imidlertid at ressurser forfremmes til et produksjonsmiljø – ideelt sett som en del av en Dataverse-løsning – før de kan brukes.
Dataverse-løsninger kan transporteres manuelt mellom miljøer. Du kan imidlertid automatisere prosessen – og aktivere policyer for å sikre at riktig endringsbehandling skjer – ved hjelp av pipeliner. Avhengig av miljøreglene du angir i løsningskontrollen, håndhever pipeliner automatisk alle reglene før løsningen distribueres, noe som hindrer ytterligere distribusjonsfeil. Følgende diagram illustrerer hvordan pipeliner kan automatisere forfremmelsen av en ressurs fra utvikling til produksjon.
Figur: Et datasamlebånd automatiserer promotering av et objekt som er lagret i kildekontroll fra utvikling, via test, til produksjon.
Du kan konfigurere antall miljøer og prosesser, for eksempel godkjenninger, som må inkluderes i en pipeline.
Pipeliner fungerer sammen med miljøgrupper. De kan forhåndskonfigureres for utviklingsmiljøer, slik at opprettere enkelt kan starte forfremmelsesprosessen ved å svare på en melding når de prøver å dele ressursene sine med andre brukere. Som en del av en distribusjonsforespørsel som bruker pipeliner, kan opprettere foreslå hvem de vil dele ressursene sine med, og de nødvendige sikkerhetsrollene. En pipeline-administrator kan godkjenne eller avvise forespørselen før distribusjon ved å sørge for minste rettigheter for oppretteren som forespørselen kommer fra.
Pipeliner i Power Platform lagrer definisjonene av hver pipeline i et vertsmiljø som Microsoft administreres som standard. Du kan imidlertid definere flere vertsmiljøer i leieren du administrerer, slik at du kan håndtere unike krav.
Katalog i Power Platform
Organisasjoner der utviklere og opprettere bygger og deler komponenter, for eksempel apper, flyter og maler, som er mer avanserte startpunkter, har en tendens til å få mer verdi fra Power Platform. Katalogen Power Platform gjør det enkelt for utviklere å dele komponentene og malene på tvers av miljøer mer effektivt.
Katalogen installeres i et miljø og kan installeres sammen med pipeline-verten i samme miljø. Det er også mulig å håndtere unike krav til ressurssegmentering ved å ha flere miljøer der en katalog er installert.
Funksjonsveikart
Etter hvert som Microsoft fortsetter å utvikle funksjonene Power Platform til denne støttestyringen og administrasjonen, kan du følge med ilanseringsplanleggeren. Du lærer hva som er planlagt, hva som er i den kommende lanseringsbølgen, og hva du kan prøve nå. Du kan til og med lage din egen utgivelsesplan ved å lagre elementene du vil følge.
Fundament for en miljøstrategi i bedriftsskala
Vi diskuterte vår visjon om en leiermiljøstrategi i bedriftsskala og viktige miljøfunksjoner som støtter den. Nå ser vi på hvordan du kan bruke disse funksjonene sammen som en del av en miljøstrategi. Strategien din bør være basert på de unike kravene til organisasjonen din, så la oss begynne med et grunnleggende eksempel før vi går over til hvordan du skreddersyr en strategi til å oppfylle dine behov.
I dette eksemplet vil Contoso-ledelsen gi ansatte muligheten til å dra nytte av Power Platform, og de har identifisert følgende krav på høyere nivå:
Ansatte må kunne bygge automatiserte prosesser for dokumentgodkjenning og andre Power Platform-tilpassinger med Microsoft 365.
Ansatte må kunne bygge Power Apps- og Power Automate-automatiseringer for å forbedre sin personlige produktivitet.
Oppretterne som arbeider med bedriftens app for samsvarssporing, må kunne utvikle og vedlikeholde den.
For å støtte disse kravene kom administrasjons- og ledelsesteamet hos Contoso opp med følgende miljøtopologi:
Figur: Foreslått miljøtopologi for Contosos Power Platform skaleringsprosjekt.
La oss se nærmere på dette miljøtopologidiagrammet.
Standardmiljøet brukes til å bygge produktivitetstilpassinger i Microsoft 365. Policyer for å hindre tap av data og begrensninger på deling begrenser andre typer oppretteraktiviteter og sørger for strenge rammer rundt hva opprettere kan bygge i dette miljøet.
Bare administratorer kan opprette prøveversjons-, sandkasse- og produksjonsmiljøer. Utviklere bruker et egendefinert Microsoft skjema eller en annen prosess til å be om et nytt miljø. Microsoft Power Platform CoE-startsettet (Center of Excellence) inkluderer en miljøforespørsel som kan brukes.
Fire miljøgrupper opprettes: Utvikling, Delt utvikling, UAT (testing av brukergodkjenning) og Produksjon.
En miljørutingspolicy angitt for utviklingsgruppen ruter opprettere bort fra standardmiljøet til deres egne utviklermiljøer. Etter hvert som det opprettes nye utviklingsmiljøer, knyttes de automatisk til utviklingsgruppen, og reglene brukes.
Gruppen Delt utvikling støtter miljøer som inneholder prosjekter med flere opprettere.
UAT-gruppen inneholder miljøer som brukes til å teste ressurser før de forfremmes til produksjon.
Produksjon-gruppen inneholder miljøer som er verter for apper, flyter og andre artefakter for produksjonsbruk.
Noe som mangler i denne foreslåtte topologien, er pipeliner for å automatisere forfremmelse mellom utviklings-, test- og produksjonsmiljøer. La oss legge dem til nå.
Figur: Den samme miljøtopologien med pipeliner som kobler et datasamlebåndvertsmiljø til utviklings-, test- og produksjonsmiljøer.
I det reviderte miljøtopologidiagrammet har vi lagt til et vertsmiljø for pipeline og to pipeliner. Den ene pipelinen flytter ressurser fra utviklings- til test- og deretter til produksjonsmiljøer. Pipeline-regelen i utviklingsgruppen endres til å bruke denne pipelinen. Den andre pipelinen flytter ressurser fra det delte utviklingsmiljøet til test og deretter til produksjon. Pipeline-regelen i den delte utviklingsgruppen endres til å bruke denne pipelinen.
Denne grunnleggende miljøstrategien gir et grunnlag som du kan bygge på for andre brukssaker, som vi utforsker videre.
Miljøstrategier for spesifikke scenarioer
Her er noen vanlige brukstilfeller som du kanskje må inkludere i den fundamentale leiermiljøstrategien.
Kontroller hvilke opprettere som kan opprette utviklermiljøer
Som standard kan alle som har en Power Platform Premium-lisens, en Utviklerplan-lisens eller en Power Platform-leieradministratorrolle, opprette et utviklermiljø fra administrasjonsportalen.
I den grunnleggende miljøstrategien sikrer miljøruting at opprettere blir dirigert bort fra standardmiljøet til et nytt utviklermiljø som er opprettet i den angitte gruppen. Opprettere kan imidlertid fremdeles opprette utviklermiljøer manuelt som ikke er plassert i en miljøgruppe, og der reglene ikke er brukt.
Hvis du vil finjustere hvilke opprettere som har rett til miljøruting, angir du en sikkerhetsgruppe i rutingskonfigurasjonen. Når en sikkerhetsgruppe er konfigurert, rutes bare medlemmer av sikkerhetsgruppen. Alle andre kommer tilbake til standardmiljøet.
Gi mer fleksibilitet til avanserte opprettere
I den grunnleggende miljøstrategien rutes alle nye opprettermiljøer til en angitt utviklermiljøgruppe. Denne gruppen av miljøer har vanligvis et ganske restriktivt sett med styringsregler.
Etter hvert som opprettere blir mer avanserte, kan du tillate at de ber om tilgang til flere funksjoner. I stedet for å fjerne dem fra den opprinnelige miljøgruppen og manuelt behandle unntaket kan du bruke en annen miljøgruppe til å spore disse avanserte oppretterne.
Figur: Legg til flere dyktige utviklere i et miljø som har avslappede styringsregler.
Organiser utviklermiljøer etter region eller forretningsenhet
I den nåværende implementeringen av miljøruting opprettes alle nye utviklermiljøer i én enkelt miljøgruppe. Hva skjer hvis du vil organisere oppretternes utviklermiljøer etter for eksempel region eller forretningsenhet?
Bruk ruting til å dirigere opprettere til et nytt utviklermiljø som er opprettet i den angitte gruppen. Deretter kan du flytte den til en annen gruppe som er basert på region, organisasjonsenhet eller andre vilkår, der du kan bruke mer detaljerte styringsregler.
Figur: Når miljøruting har opprettet utviklermiljøer i den angitte gruppen, flytter du dem til mer strukturelt spesifikke grupper.
Flytting av miljøer er en manuell handling i dag, men du kan automatisere den når Power Platform-administratorkoblingen støtter gruppefunksjonen i en fremtidig oppdatering.
Utvikle en app for virksomhetsbruk
Et team i organisasjonen utvikler kanskje en app for bruk i hele organisasjonen. Teamet kan være IT-drevet eller inkludere både IT- og forretningsbrukere (det som kalles en tverrfaglig gruppe).
I den enkleste miljøstrategien bygger prosjektteamet i et delt miljø som er enten sandkasse eller produksjon. En utviklermiljøtype er ikke den beste måten å støtte flere opprettere på som samarbeider om en ressurs. Oppretterne må imidlertid kommunisere med hverandre for å unngå kollisjoner og konflikter i det delte miljøet.
Dedikerte test- og produksjonsmiljøer er ikke nødvendig. Appen kan testes i og distribueres i test- og produksjonsmiljøer på organisasjonsnivå som er vert for flere programmer.
Figur: To bedriftsapper under utvikling i dedikerte miljøer, deretter testet og distribuert i miljøer som deles med andre apper.
I en mer avansert variant har hver enkelt oppretter et individuelt utviklermiljø. Dette gir fordelen med økt isolasjon for oppretteren, men kan gjøre det mer komplisert å kombinere individuelt arbeid i et integreringsmiljø. Selv om det kan være nyttig å arbeide isolert for større og avanserte team, kan det medføre unødvendig ekstraarbeid for mindre team som kan oppnå mer vellykket samarbeid i et delt utviklingsmiljø.
Figur: To utviklere som arbeider med samme app i individuelle utviklermiljøer, må kombinere arbeidet sitt i et delt integreringsmiljø før det går over til testing og produksjon.
Denne varianten omfatter vanligvis en strategi for kildekontroll, der hvert utviklingsmiljø representeres som en gren i kildekontrollen som flettes når endringer er klart til å forfremmes. Det er viktig å ta hensyn til hvordan programmet vedlikeholdes etter den første lanseringen.
Versjon 1.0 av appen kan for eksempel være i produksjon mens teamet går videre til å bygge versjon 2.0. Miljøstrategien må støtte løsing av et problem i versjon 1.0 mens utviklingen av versjon 2.0 pågår.
Figur: Versjon 1.0 må oppdateres, testes og distribueres mens versjon 2.0 utvikles, testes og distribueres.
Miljøgrupper tilbyr flere metoder for håndtering av dette scenarioet med virksomhetsapper. Dette kan for eksempel være én appgruppe, eller det kan involvere å ha separate grupper for hvert utviklingstrinn. I delen om gode fremgangsmåter utforsker vi hvordan du evaluerer alternativene.
Minimer bruken av utviklermiljøer
Individuelle utviklermiljøer er den anbefalte måten å gi oppretterne et arbeidsområde for å bygge løsninger med lavkode. De gir det høyeste isolasjonsnivået fra andre opprettere. Hvis organisasjonen imidlertid vil redusere antall utviklermiljøer, er flere delte miljøer bedre enn å oppmuntre beslutningstakere til å bygge ressurser i standardmiljøet.
I dette scenarioet begrenser du opprettingen av utviklermiljøer og oppretter delte utviklingsmiljøer av produksjonstypen. Du kan organisere disse delte miljøene etter organisasjonsstruktur, område eller andre vilkår. En miljøgruppe kan inneholde dem for å sikre at de har konsekvente regler for styring. Gi opprettere tillatelse til å opprette lavkoderessurser i miljøet som er tilordnet dem.
Sikkerhet som en del av miljøstrategien
Miljøer er en nøkkelkomponent ved bruk av Power Platform på en sikker måte. De representerer sikkerhetsgrenser innenfor leieren som bidrar til å beskytte apper og data. Som en del av miljøstrategien må du vurdere hvordan sikkerhetskravene påvirker antallet av og formålet med miljøene i leieren.
Miljøer gjør det mulig å opprette flere sikkerhetsgrenser innenfor leieren for å beskytte apper og data. Beskyttelsen som gis av miljøet, kan justeres for å gi den nødvendige sikkerhetsbeskyttelsen ved å bruke et konfigurerbart sett med sikkerhetsfunksjoner i miljøet. En detaljert diskusjon om de enkelte sikkerhetsfunksjonene i miljøet ligger utenfor omfanget av denne artikkelen. I denne delen tilbyr vi imidlertid anbefalinger for hvordan du tenker på sikkerhet som en del av miljøstrategien for leieren.
Sikkerhet på leiernivå
De fleste sikkerhetsinnstillinger som påvirker miljøer, er konfigurert for hvert miljø individuelt. Du kan imidlertid gjøre noen endringer på leiernivå for å støtte miljøstrategien.
- Vurder å deaktivere funksjonen Del med alle i Power Platform. Bare administratorer kan dele en ressurs med alle.
- Vurder å sikre integrasjon med Exchange.
- Bruk isolering på tvers av leier for å minimere risikoen for dataeksfiltrering mellom leiere.
- Begrens opprettingen av nye produksjonsmiljøer til administratorer. Begrensning av miljøoppretting er fordelaktig for å opprettholde kontroll generelt: både for å forhindre ikke-regnskapsført kapasitetsforbruk og for å redusere antall miljøer som skal administreres. Hvis brukere må be om miljøer fra sentral IT, er det enklere å se hva brukerne arbeider med hvis administrator er gatekeeper.
Sikre standardmiljøet
Standardmiljøet har en rolle i å støtte produktivitetstilpassinger i Microsoft 365. Som en del av den anbefalte miljøstrategien er det imidlertid best å redusere bruken så mye som mulig. I stedet bør oppretter bygge i sine egne isolerte miljøer. Selv om du ikke kan blokkere tilgang til standardmiljøet, kan du minimere hva som kan gjøres i det.
Bruk først miljøruting for å dirigere opprettere til sitt eget arbeidsområde for å bygge lavkoderessurser.
Se gjennom hvem som har administratortilgang til standardmiljøet, og begrens dette til roller som trenger det.
Vurder å endre navnet på standardmiljøet til noe mer beskrivende, for eksempel "Personlig produktivitet".
Etabler en policy for beskyttelse mot tap av data (DLP) for standardmiljøet som blokkerer nye koblinger og begrenser brukere til å bruke bare grunnleggende koblinger som ikke kan blokkeres. Flytt alle koblingene som ikke kan blokkeres, til forretningsdatagruppen. Flytt alle koblingene som kan blokkeres, til den blokkerte datagruppen.
Opprett en regel for å blokkere alle URL-mønstre som brukes av egendefinerte koblinger.
Sikring av standardmiljøet bør prioriteres. Gjør det sammen med sikkerhet på leiernivå som en del av det første trinnet i implementeringen av miljøstrategien. Uten at disse er implementert har opprettere flere muligheter til å legge til ressurser i standardmiljøet. Med dem på plass sammen med miljøruting oppfordres opprettere til å bruke sitt eget miljø.
Sikre andre miljøer
Hvis organisasjonen din er som de fleste andre, har du flere miljøer i tillegg til standardmiljøet. Sikkerhetsnivået hvert av dem krever, kan variere avhengig av appene og dataene det inneholder. Utviklermiljøer har vanligvis mindre strenge regler enn produksjonsmiljøer. Enkelte produksjonsmiljøer krever best mulig beskyttelse.
Som en del av etableringen av miljøstrategien identifiserer du felles sikkerhetsnivåer for miljøene dine og funksjonene som beskytter hvert nivå, som i eksemplet nedenfor.
Figur: Et eksempel på tre nivåer av miljøsikkerhet og sikkerhetsfunksjonene som gjelder for miljøer på hvert nivå.
Innlem sikkerhetsnivåene du identifiserer i gruppestrategien, og bruk regler der det er mulig, for å aktivere sikkerhetsfunksjonene i miljøene. I dette eksemplet begrenser en regel deling i alle miljøer som er angitt med normal eller middels sikkerhet.
Tilpass miljøer etter strategien for å hindre tap av data
Datapolicyer er en annen viktig del av en generell styringsinnsats for å styre tjenestene som brukes av lavkoderessurser i et miljø. Miljøgrupper har ikke en regel for å bruke en DLP-policy på et miljø. Du kan imidlertid tilpasse DLP-strategien med miljøgruppene. Du kan for eksempel opprette en DLP-policy med samme eller lignende navn som en miljøgruppe og bruke den på miljøer i gruppen.
Finn ut mer om hvordan du etablerer en DLP-strategi.
Figur: I dette eksemplet følger miljøer i gruppen Personlig utvikling en DLP-policy som blokkerer alle ikke-koblingerMicrosoft .
Skreddersy en miljøstrategi for organisasjonen
I tidligere deler har vi beskrevet vår syn på hvordan organisasjoner kan håndtere miljøer i stor skala. Vi har utforsket viktige funksjoner, hvordan de bidrar til en miljøstrategi og hvordan en grunnleggende miljøtopologi som bruker dem, kan se ut. Vi gav eksempler på hvordan man bygger videre på det fundamentet for å tilpasse vanlige scenarioer. Siden hver organisasjon er unik, er neste trinn å skreddersy en miljøstrategi som dekker organisasjonens behov.
Start der du er
Enten organisasjonen er ny i Power Platform eller har brukt det i mange år, er det første trinnet å evaluere situasjonen. Vurder, på et høyt nivå, hva som er i standardmiljøet, hvilke andre miljøer du har og hva de brukes til. Ofte utføres en miljøstrategi som en del av en total innsats for å etablere styring av Power Platform i en organisasjon. Hvis dette er tilfelle, har du kanskje allerede definert noe av styringsvisjonen som kreves for å skreddersy en strategi for organisasjonen.
Organisasjonsinformasjon du bør kjenne til, omfatter følgende:
Hva er visjonen for hvordan Power Platform skal brukes i organisasjonen?
Hvem i organisasjonen skal bygge lavkoderessurser?
Du må ta noen viktige avgjørelser:
Hvordan får opprettere nye miljøer?
Vil du gruppere miljøene, og hvordan i så fall?
Hvilke sikkerhetsnivåer kreves for ulike miljøer, og hvordan klassifiseres miljøer?
Hvordan avgjør du om en app, automatisering eller Copilot skal bruke et eksisterende miljø eller et nytt?
Er det konflikter mellom grunnlinjefunksjonene på plattformen og kravene dine som krever en tilpasset styringsprosess?
Hvordan håndterer du eksisterende ressurser i standardmiljøet?
Har du en DLP-policystrategi for leieren og miljøet, og hvordan samsvarer den i så fall med miljøstrategien du oppretter?
Du kan også finne litt inspirasjon i skydriftsmodellene som er en del av Cloud Adoption Framework for Azure.
Dekk opp mangler ved hjelp av plattformen
Du vil nesten alltid finne krav som plattformens innebygde funksjoner ikke dekker. Når du evaluerer disse manglene, må du vurdere følgende mulige resultater av evalueringen:
Mangelen kan godtas.
Mangelen kan dekkes ved å bruke Power Platform CoE-startsettet.
Mangelen kan dekkes ved hjelp av plattformens funksjoner, for eksempel API-er, koblinger og tilpassede apper eller automatiseringer.
Mangelen kan dekkes ved hjelp av et tredjepartsverktøy eller en app.
Startpakken for CoE
Power Platform CoE-startsettet er en samling komponenter og verktøy som er utformet for å bidra til at din organisasjon kan ta i bruk og støtte bruken av Power Platform. Et viktig aspekt ved startsettet er muligheten til å samle inn data om plattformbruk på tvers av miljøer, noe som kan være nyttig når du utvikler miljøstrategien.
Miljøinstrumentbordet i Power BI gir for eksempel en oversikt som hjelper deg med å forstå hvilke miljøer som finnes i leieren, hvem som opprettet dem, og hvilke ressurser de inneholder.
Figur: Instrumentbordet for miljøer i Power BI.
Pakken inneholder startpunkter eller inspirasjon, for eksempel en prosess som opprettere kan bruke til å be om nye miljøer og endringer i DLP-policyer for sine miljøer.
Figur: Flytskjema som illustrerer en miljøstyringsprosess i CoE-startpakken.
Programmerbarhet og utvidelse for plattformen
Noe av det beste med en lavkodeplattform er at du kan bruke den til å bygge apper, automatiseringer, portaler og kopiloter for å hjelpe deg med å administrere den. Du har også tilgang til verktøy på lavere nivå som kan brukes til å dekke mangler til støtte for miljøstrategien.
Du kan bruke følgende koblinger til å bygge apper og flyter:
Du kan bruke Power Platform-kommandolinjegrensesnittet (CLI) til å utvikle automatiseringer som hjelper deg med å administrere livssyklusen til miljøet og andre oppgaver relatert til DevOps-praksis.
Med PowerShell-cmdleter for Power Platform-opprettere og -administratorer kan du automatiser mange overvåkings- og administrasjonsoppgaver.
Power Platform DLP SDK kan hjelpe deg med å administrere policyene for hindring av datatap for leieren og miljøet.
Anbefalte fremgangsmåter
I denne delen av artikkelen bygger vi på anbefalingene i de grunnleggende og scenariospesifikke delene.
Nye miljøer
Som en del av utviklingen av strategien bør du vurdere når du oppretter miljøer for å støtte en arbeidsbelastning. Evalueringen må balansere fordelene ved isolasjon som et miljø gir, for eksempel om det å kunne låse bestemte miljøer mer enn andre, er nyttig fra et sikkerhetsperspektiv – med ulempene, for eksempel det at isolasjon skaper friksjon for brukere som prøver å dele data på tvers av apper.
Når du evaluerer om en app eller automatisering hører hjemme i et eget miljø, bør du vurdere de ulike trinnene i appens livssyklus separat. Under utvikling er isolasjon fra andre apper viktig. Når flere apper utvikles i ett enkelt miljø, risikerer du å skape avhengigheter på tvers av apper.
Som en generell anbefaling bør utviklingsmiljøer ha ett enkelt formål, kunne forkastes og enkelt opprettes på nytt, så sant dette er mulig.
Det er fornuftig å teste flere apper i samme miljø hvis de kjøres sammen i produksjon. Hvis du ikke tester med appene som kjører i produksjon, risikerer du faktisk at du ikke oppdager kompatibilitetsproblemer.
Når du evaluerer produksjonsmiljøet for en app, må du huske på følgende:
Er appen kompatibel med eksisterende apper i miljøet? Det kan for eksempel hende at to apper som begge bruker Kontakt-tabellen i Dataverse til ulike formål, ikke er kompatible. Er appene kompatible fra et DLP-policyperspektiv?
Finnes det spesielle samsvars- eller forskriftskrav for dataseparasjon? Krever for eksempel sensitiviteten til dataene at de må isoleres? Finnes det et krav om at data ikke kan inkluderes i andre data?
Er dataene svært konfidensielle eller sensitive? Vil eksfiltrasjon føre til penge- eller omdømmebruddsfare for organisasjonen? Hvis du isolerer data i et separat miljø, kan du få bedre kontroll over sikkerheten.
Trenger appen data fra andre apper, og må den sorteres sammen med dem? To apper som begge bruker Kunde-tabellen, må for eksempel driftes sammen. Hvis du skiller dem, opprettes overflødige datakopier og det oppstår problemer med vedlikehold av dataene.
Krever dataene regional datalagring? I enkelte scenarioer kan den samme appen eller automatiseringen distribueres til regionale miljøer for å sikre riktig dataisolasjon og -lagring.
Er de fleste brukere i samme region som miljøet? Hvis miljøet er i Europa, Midtøsten og Afrika, men de fleste brukerne av appen er basert i USA, er det ikke sikkert at deling av et miljø gir best ytelse.
Er det nødvendig med nye administratorer, eller er de eksisterende administratorene tilstrekkelige? Hvis den nye appen krever flere administratorer, er de kompatible med de eksisterende administratorene fordi alle har administratortillatelser for alle apper i miljøet.
Hva er forventet levetid for appen? Hvis appen eller automatiseringen er midlertidig eller har kort levetid, er det ikke sikkert at det er lurt å installere den i et miljø med flere permanente apper.
Vil det være vanskelig for brukerne å bruke flere miljøer for ulike apper? Dette kan påvirke alt fra å finne en app på mobilenheten til selvbetjent rapportering som må hente data fra flere miljøer.
Kapasitet
Hvert miljø (i tillegg til prøve- og utviklingsmiljøer) forbruker 1 GB til å klargjøre for første gang. Kapasiteten deles over hele leieren, slik at den må tildeles til dem som trenger den.
Spar kapasitet ved å:
- Administrere delte test- og produksjonsmiljøer. I motsetning til delte utviklingsmiljøer bør tillatelser i test- og produksjonsmiljøer begrenses til brukertilgang for testing.
- Automatisere rydding av midlertidige utviklingsmiljøer og oppmuntre til bruk av prøvemiljøer for testing eller konseptgodkjenningsarbeid.
Miljøgrupper
Miljøgrupper er fleksible og gjør det mulig å få plass til ulike brukstilfeller som er unike for organisasjonene. Her er noen få måter du kan vurdere gruppering av miljøer på som en del av miljøstrategien:
Etter tjeneste eller komponent, for eksempel et ServiceNow-tjenestetre
Utvikling, test og produksjon
Avdelinger, bedriftsgrupper eller kostnadssentre
Etter prosjekter
Etter sted hvis de fleste miljøer på et sted har lignende styringsbehov. Dette kan også bidra til å oppfylle lignende forskriftsmessig og juridisk samsvar på regionalt nivå
Figur: Miljøgrupper for to ulike avdelinger har ulike regler.
Navngi miljøer og grupper
Som en del av strategien bør du vurdere hvordan miljøer og grupper gis navn.
Miljønavn er synlige for administratorer, opprettere og brukere. Bare administratorer bruker vanligvis miljøgrupper, men opprettere kan støte på dem hvis de har rettigheter til å opprette miljøer.
Utviklermiljøer som opprettes automatisk, følger mønsteret <brukernavnets> miljø, for eksempel "Avery Howards miljø". Miljøgrupper gis ikke navn automatisk.
Det kreves ikke at navn på miljøer og miljøgrupper er unike. For å unngå forvirring er det imidlertid lurt å unngå dupliserte navn.
Navn kan inneholde maksimalt 100 tegn. Kortere navn er enklere å bruke.
Etabler en konsekvent navnekonvensjon.
Konsekvente navn hjelper administratorer med å vite hva gruppens formål er og hvilke miljøer den administrerer, og de kan gjøre automatisering og rapportering enklere.
En vanlig fremgangsmåte er å inkludere livssyklusfasen i navnet på et miljø, for eksempel Contoso Dev, Contoso Test, Contoso Prod. Målet er å skille miljøer med samme innhold, men ulike formål.
En annen vanlig fremgangsmåte er å inkludere avdelingen eller forretningsenheten i navnet når miljøet er dedikert til denne brukergruppen.
Du kan for eksempel bestemme at alle navn på miljøer eller miljøgrupper må følge mønsteret <livssyklusfase>-<region>-<forretningsenhet>-<formål> (Prod-US-Finans-Lønn).
La navnene være korte, meningsfulle og beskrivende.
Tenk på hvordan gruppene vil utvikle seg og vokse over tid, og sørg for at navnekonvensjonen kan imøtekomme disse endrede behovene.
Unngå å inkludere konfidensiell informasjon i navn. De kan være synlige for alle som har tilgang til administrasjonssenteret.
Ressurser i standardmiljøet
Miljøstrategien bør oppmuntre (eller håndheve) bruken av personlige utviklingsmiljøer for å redusere hva som opprettes i standardmiljøet. Du bør imidlertid se på hva opprettere beslutningstakere allerede har opprettet i standardmiljøet, og vurdere hvordan hvert brukstilfelle skal håndteres. Er det hensiktsmessig å la det være i standardmiljøet, eller skal det overføres til et annet miljø?
En viktig del av denne innsatsen er å identifisere programmer som brukes bredt i hele organisasjonen, og som bør ha et eget beskyttet utviklingsmiljø som er atskilt fra produksjonsmiljøet.
Tabellen nedenfor viser eksempelbrukssaker og overføringshandlinger. Til syvende og sist må organisasjonen identifisere egne brukssaker og risikofaktorer knyttet til det å la ressurser forbli i standardmiljøet. Finn ut mer om når du skal flytte ressurser fra standardmiljøet.
| Standard miljø | Overføringshandling |
|---|---|
| Personlig produktivitet i Microsoft 365 | Forbli i standardmiljøet. |
| Ressurser med én enkelt oppretter som har blitt brukt i det siste, men som ikke er delt | Flytt til eierens individuelle utviklermiljø. |
| Ressurser med én enkelt oppretter som har blitt brukt i det siste, og som er delt | Flytt til eierens individuelle utviklermiljø, og kjør fra et delt produksjonsmiljø. |
| Ressurser med flere opprettere som har blitt brukt i det siste, og som er delt | Flytt til et delt utviklermiljø, og kjør fra et delt produksjonsmiljø. |
| Ressurser som ikke har blitt brukt i det siste | Varsle eieren, og flytt til karantene hvis du ikke får svar. |
Ressurser i Dataverse for Teams-miljøer
Microsoft Dataverse for Teams gir brukere mulighet til å bygge egendefinerte apper, roboter og flyter inn Microsoft Teams ved å bruke Power Apps, Microsoft Copilot Studio og Power Automate. Når en teameier legger til denne funksjonen i teamet, opprettes det et Microsoft Power Platform-miljø med en Dataverse for Teams-database, og den kobles til teamet deres. Lær hvordan du etablerer styringspolicyer for å administrere Microsoft Dataverse for Teams miljøer.
Miljøstrategi internt på Microsoft
Microsoft anser seg selv som "Customer Zero" ettersom den internt tar i bruk Power Platform for å drive automatisering og effektivitet blant sine ansatte. Tallene nedenfor gir deg et forslag til bruksskalaen på tvers Microsoft av intern leier.
50 000 til 60 000 aktive opprettere hver måned
Over 250 000 programmer og over 300 000 flyter
Over 20 000 miljøer
Microsoft skifter fra sin tidligere miljøstrategi til en som bruker de nyeste Power Platform styringsfunksjonene, inkludert administrerte miljøer, miljøgrupper og regler.
Som en del av den forbedrede strategien Microsoft planlegger du å gruppere scenarier basert på utviklingstype, organisasjonseierskap og risikonivå. Siden det bygges så mye i hele selskapet, er det for vanskelig å fokusere på ethvert mulige scenario og tilpasse for hvert brukssak. Det skjer for mye, og det må automatiseres og utnyttes så mange av de innebygde kontrollene som mulig.
Microsoft strukturerer miljøene sine Power Platform i tre bredere kategorier som dekker syv brukstilfeller, som gjenspeiler varierende grad av risiko og kontroll: personlig produktivitet, teamsamarbeid og bedriftsutvikling.
Personlig produktivitet – Dette er for noen som bare vil bygge en app eller flyt for seg selv. De samarbeider for eksempel ikke med andre. Disse brukerne rutes til personlige utviklingsmiljøer, som er låst. Disse miljøene bruker funksjonene for administrert miljø, inkludert å begrense deling og også styre andre ting du kan gjøre i miljøer. Koblingene og de tilgjengelige handlingene er svært begrensede i denne gruppen av miljøer. Disse miljøene er minst risikable. Bruk av låste, personlige miljøer gjør det mulig for brukere å unngå den strengere samsvarsprosessen bare for å utvikle personlige produktivitetsapper og -flyter.
Teamsamarbeid – Dette er for brukere som bygger verktøy, automatisering og prosesser for teamet sitt. For dette scenariet,oppfordrer Microsoft til bruk av Dataverse for Teams miljøer. Livssyklus, tilgangsadministrasjon og dataetiketter styres på gruppenivå i Microsoft 365, så vi trenger ikke bruke tiden på å administrere disse brukerne fra et Power Platform-styringsperspektiv. Dette bruksnivået er neste trinn opp i risikospekteret.
Bedriftsutvikling/produksjonsnivå som brukes av alle ansatte – Dette er verktøy for mennesker som bygger verktøy eller løsninger som brukes bredere på tvers av selskapet. Disse miljøene lagrer kanskje de mest sensitive dataene, bruker kraftigere koblinger og krever mer styring. Dette regnes som den høyeste risikoen, og det meste av innsatsen brukes på styring. ALM er nødvendig når arbeid før produksjon skjer i sandkassemiljøer, og bare administrerte løsninger er tillatt i produksjonsmiljøer. Disse miljøene må være koblet til ServiceTree, som håndhever regelmessige sikkerhets- og personverngjennomganger. Miljøgruppereglene tilpasses basert på ServiceTree-metadata og -signaler. Mange miljøgrupper og regler brukes til å administrere og kontrollere disse miljøene.
Microsofts styringsstrategi er ikke statisk. Den er flytende og endres for å tilpasses til nye utfordringer og innlemme nye Power Platform-funksjoner.
Utvikle leiermiljøstrategien
I denne artikkelen har vi beskrevet hvordan du etablerer en miljøstrategi i bedriftsskala. Strategien kan vokse med virksomheten uavhengig av hvor du starter på reisen. Organisasjoner av alle størrelser kan dra nytte av strategien vi presenterer. For organisasjoner som allerede er på en høyere skala, er fordelene imidlertid større.
Det å utvikle en leiermiljøstrategi er ikke en engangsaktivitet. Det er en reise. Du bør utvikle strategien over tid etter hvert som behovene endres. Strategien må også justeres for å ta i bruk nye funksjoner på plattformen og ta tak i nye utfordringer.
Som alle reiser blir ulike organisasjoner med på ulike punkter underveis, men alle har samme mål i bakhodet. Det som følger, er mulige ramper som representerer hvor organisasjonen er i dag.
Starter
Organisasjonen er i begynnelsen av reisen mot å innføre Power Platform. Dette kalles ofte for greenfield. Du starter reisen på det beste stedet fordi du ikke trenger å bekymre deg for eksisterende miljøer, eller virkningen nye policyer kan ha for hvordan personer i organisasjonen bruker Power Platform. Dette er den beste tiden for implementering av en miljøstrategi i virksomhetsskala som er tilpasset produktfunksjoner og gode fremgangsmåter.
Utforsk de viktigste miljøfunksjonene og strategiene som beskrives i denne artikkelen. Ta deg tid til å forstå de viktigste temaene og vurderingene og avgjørelsene du trenger for å utforme og implementere en leiermiljøstrategi som passer best til dine behov.
Det er viktig å etablere et solid fundament nå for å unngå å havne i en situasjon der du ikke har kontroll, som kan oppstå senere hvis du starter uten en definert strategi. Planlegg hurtig akselerasjon av bruken av Power Platform, men unngå fristelsen til å overkonstruere miljøstrategien ved å legge til kompleksitet som ikke er nødvendig. Husk at dette er en reise, og du kan fortsette å utvikle strategien etter hvert som behovene dine endres.
Align
Organisasjonen har og kjører en miljøstrategi som må endres for å samsvare med nye funksjoner og gode fremgangsmåter i Power Platform. Dette kalles ofte for brownfield. I motsetning til organisasjoner som akkurat har startet, må du vurdere virkningen på organisasjonen når du endrer miljøstrategien.
Utforsk de viktigste miljøfunksjonene og strategiene som beskrives i denne artikkelen, og evaluer hva som kreves for å utvikle strategien slik at den blir mer i henhold. Vanligvis er trinnvise justeringer alt som trengs. Når det er mulig, kan du planlegge utrullingen av endringer for å redusere innvirkningen på brukerne.
Følgende forslag er vanlige trinnvise endringer du kan implementere:
Hvis du vil starte justeringen uten å påvirke eksisterende miljøer, oppretter du en miljøgruppe som inneholder nye utviklermiljøer og fastsetter regler for hvordan du vil styre dem. Aktiver miljøruting for å sikre at alle nye utviklermiljøer opprettes i den angitte gruppen.
Vurder grupperingsstrategien, og opprett grupper om nødvendig for å støtte eksisterende miljøer. Etabler regler for disse gruppene som samsvarer med eksisterende begrensninger og unntak. Flytt eksisterende miljøer til disse gruppene.
Identifiser populære programmer som er bygd og brukt i standardmiljøet. Bruk pipeliner til å publisere dem i et produksjonsmiljø der brukerne i organisasjonen kan kjøre dem. Deretter arbeider du med overføring av utvikling av disse appene til enten et individuelt utviklermiljø eller et dedikert utviklingsmiljø.
Opprett en plan for å identifisere, sette i karantene og fjerne ressurser i standardmiljøet som ikke brukes.
Forbedre
Miljøstrategien du kjører, er allerede i henhold med de nyeste funksjonene og de beste fremgangsmåtene, men organisasjonen vil legge til flere kontroller eller funksjoner.
Kommuniser miljøstrategien til organisasjonen
Du implementerer leiermiljøstrategien mer vellykket hvis Power Platform-brukerne forstår og er innrettet etter det du prøver å oppnå. Hvis du bare aktiverer strategien uten kommunikasjon, ser brukerne endringene som begrensninger, og ser etter måter å omgå dem på.
Som en del av utvikling av strategien avgjør du hvordan du informerer brukere om viktige elementer i strategien som påvirker bruken deres av Power Platform. De trenger ikke alle de tekniske detaljene i strategien, bare de nødvendige detaljene som bidrar til å sikre at de forblir produktive, for eksempel følgende:
Formålet med standardmiljøet
Hvor de skal bygge nye lavkoderessurser
Hvordan de bør bruke det personlige utviklermiljøet
Hvordan de ber om egendefinerte miljøer for bestemte forretningsenheter eller prosjekter
Generelle policyer for koblingsbruk og hvordan de ber om flere koblingsrettigheter for sine miljøer
Hvordan de deler det de bygger med andre
Ansvarsområdene til en oppretter, for eksempel:
Hold leieren ryddig. Slett miljøer, apper og flyter hvis de ikke lenger er nødvendige. Bruk testmiljøer hvis du eksperimenterer.
Del på en fornuftig måte. Unngå overdeling av miljøer, apper, flyter og delte tilkoblinger.
Beskytt organisasjonsdata. Unngå å flytte data fra svært konfidensielle eller konfidensielle datakilder til ikke-beskyttet eller ekstern lagring.
Når strategien endres, deler du hvordan endringene påvirker brukerne, slik at de vet hva de må gjøre på en annen måte
En god start er å aktivere velkomstinnholdet for opprettere i miljøgruppen der nye opprettere blir lagt til.
Figur: Bruk velkomstinnholdet til å hjelpe nye utviklere med å lykkes.
En annen effektiv metode for kommunikasjon med brukerne er oppretting av en intern Power Platform-hub. Huben kan være et sted der personer kan samarbeide på prosjekter, dele ideer og oppdage nye metoder for å bruke teknologi til å oppnå mer. Huben kan være stedet der du deler mer detaljert informasjon om miljøstrategien som er relevant for brukerne. Finn ut hvordan du oppretter en intern Power Platform hub.
Konklusjon
I denne artikkelen utforsket vi funksjoner som er utformet for å hjelpe organisasjonen din med å administrere Power Platform-miljøer i virksomhetsskala og innlemme dem i leiermiljøstrategien.
Etter hvert som organisasjonen tar i bruk Power Platform og akselererer bruken, kan behovet for miljøer endres raskt. Du trenger en smidig tilnærming som bidrar til at miljøstrategien holder tritt med endringer og fortsetter å oppfylle organisasjonens styringskrav i utvikling.
En viktig faktor for å lykkes med en leiermiljøstrategi er kommunikasjon med opprettere og brukere og å få støtte fra dem. Sørg for at personene som bygger lavkodeprogrammer og -automatiseringer, vet hvordan de kan følge organisasjonens miljøstrategi og hvor de skal bygge sine lavkoderessurser.
Enhver organisasjons reise for å ta i bruk Power Platform er unik. Vi har presentert noen ideer for å hjelpe deg med å starte på rett fot. Kontoteamet Microsoft eller Power Platform partneren kan hjelpe deg med å opprette en mer tilpasset leiermiljøstrategi for organisasjonen.