Managed og unmanaged solutions, forklart enkelt

Managed og unmanaged solutions er noe av det første man møter i Power Platform, og noe av det som skaper mest forvirring. Hvorfor dukker ikke endringen min opp i produksjon? Hvorfor kan jeg ikke redigere denne flyten? Hvorfor har skjemaet tre lag?

I dette innlegget går jeg gjennom det fra A til Å, så enkelt jeg klarer.

Hva er en solution?

En solution er en beholder for alt du har laget: tabeller, kolonner, skjemaer, visninger, apper, flyter, miljøvariabler og så videre. Den gjør det mulig å flytte arbeidet ditt fra ett miljø til et annet som én pakke, i stedet for å gjenskape alt for hånd.

Solutions finnes i to varianter: unmanaged og managed.

Unmanaged: arbeidsversjonen

Tenk på et Word-dokument. Du kan skrive, slette og endre så mye du vil. Det er slik en unmanaged solution fungerer.

• Du kan redigere alle komponentene direkte.
• Solutionen er egentlig bare en liste over hva som hører sammen. Selve komponentene lever i miljøet.
• Sletter du en unmanaged solution, forsvinner bare listen. Tabellene, flytene og skjemaene blir liggende igjen.

Det siste punktet overrasker mange. Du kan ikke «avinstallere» en unmanaged solution.

Managed: den ferdige pakken

Tenk på en PDF laget fra Word-dokumentet. Den er ferdig, låst og ment for å bli brukt, ikke redigert. Det er en managed solution.

• Du lager den ved å eksportere en unmanaged solution som managed fra utviklingsmiljøet.
• Komponentene kan som regel ikke endres direkte der den er installert.
• Den kan avinstalleres. Da fjernes alle komponentene den la til.

Hvorfor unmanaged i utvikling, men managed ellers?

Utviklingsmiljøet er verkstedet. Der må du kunne endre fritt, så der jobber du i unmanaged.

Alle andre miljøer skal få nøyaktig det som ble testet, og ingenting annet. Derfor installerer du managed der:

Miljø	Type	Hvorfor
Utvikling	Unmanaged	Her bygger du og endrer fritt
Test	Managed	Du tester det som faktisk skal i produksjon
QA	Managed	Samme pakke som går videre
Produksjon	Managed	Låst, sporbar og mulig å rulle tilbake

Noen team bruker unmanaged i et testmiljø også, for å kunne gjøre raske rettelser. Det er fristende, men da tester du noe annet enn det som havner i produksjon, og rettelsene må huskes og gjøres på nytt i utviklingsmiljøet. Min anbefaling er managed overalt unntatt i utvikling.

Lag: slik henger det sammen

Her blir det interessant. Hver gang en solution endrer en komponent, legges endringen som et lag oppå det som var der fra før. Tenk på det som gjennomsiktige ark lagt oppå hverandre.

Slik kan lagene for et skjema se ut:

1. Aktivt lag (unmanaged)Endringer gjort direkte i miljøet
2. Managed: Kundeservice 2.0Sist installert
3. Managed: Kundeservice 1.0Installert først
4. SystemStandard fra Microsoft

Tre ting er verdt å vite:

1. Systemlaget ligger alltid nederst. Det er Microsofts standardoppsett.
2. Managed-lagene legges oppå i den rekkefølgen de installeres.
3. Det aktive, unmanaged laget ligger alltid øverst. Alt som endres direkte i miljøet havner der.

For de fleste komponenter er det det øverste laget som vinner. Brukeren ser det som står i det øverste laget som har endret den aktuelle egenskapen. Skjemaer, områdekart (sitemap) og båndet (ribbon) er unntak: der slås lagene sammen, slik at endringer fra flere solutions kan leve side om side.

Du kan se lagene selv: åpne en solution, velg en komponent og velg See solution layers.

Hva skjer når du legger et unmanaged lag på toppen?

Si at du har installert en managed solution i produksjon, og at noen gjør en «rask fiks» direkte i miljøet. Da havner endringen i det aktive laget, helt øverst.

Neste gang du installerer en ny versjon av den managed solutionen, legges den nye versjonen inn under det aktive laget. Den manuelle endringen ligger fortsatt øverst og vinner. Den nye versjonen din er installert, men brukerne ser den ikke.

Dette er grunnen til det klassiske spørsmålet: «Jeg har jo importert den nye versjonen, hvorfor ser jeg ikke endringen?»

Hvordan publishers påvirker lagene

Hver solution har en publisher. Publisheren sier hvem som eier komponentene, og gir dem et prefiks, for eksempel edm_kundenummer.

• Samme publisher, ny versjon: Når du oppgraderer en solution fra samme publisher, erstatter den nye versjonen sitt eget lag.
• Ulike publishers på samme komponent: Hvis to solutions fra forskjellige publishers endrer det samme skjemaet, får hver av dem sitt eget lag. Den sist installerte ligger øverst.
• Avinstallering avslører laget under: Fjerner du den øverste solutionen, trer laget under frem igjen.

Et vanlig eksempel er en tredjepartsløsning fra en leverandør, med dine egne tilpasninger i en egen solution oppå. De to ligger i hvert sitt lag, og du kan oppdatere hver av dem uten å overskrive den andre.

Eksempel: skjemaet med tre lag

Tenk deg skjemaet for Kontakt i produksjon:

1. Leverandørens solution (publisher: Leverandør AS) legger til fanen «Medlemskap».
2. Din solution (publisher: deg) legger til feltet «Kundenummer» og flytter «Telefon» øverst.
3. En superbruker flytter «Kundenummer» ned til bunnen direkte i produksjon.

Siden skjemaer slås sammen, ser brukerne både fanen fra leverandøren og feltet ditt. Men plasseringen av «Kundenummer» kommer fra det aktive laget, altså superbrukerens endring.

Neste uke leverer du en ny versjon der «Kundenummer» skal stå ved siden av «E-post». Du importerer, alt går grønt, og ingenting skjer. Superbrukerens lag ligger fortsatt øverst.

Eksempel: flyten som ikke ville oppdatere seg

Dette skjer ofte med Power Automate.

En flyt sender en e-post når en sak blir opprettet. Den ligger i en managed solution i produksjon. En dag feiler den, og noen åpner flyten i produksjon og retter mottakeradressen der og da. Flyten virker igjen, og alle er fornøyde.

Det de ikke så, er at redigeringen laget et unmanaged lag oppå den managed flyten.

En måned senere lager du en ny versjon av flyten i utviklingsmiljøet, med bedre feilhåndtering. Du importerer den nye versjonen til produksjon. Men produksjon kjører fortsatt den gamle, manuelt rettede versjonen, fordi det aktive laget vinner. Den nye flyten din ligger trygt under, uten å bli brukt.

Løsningen er å fjerne det aktive laget. Da trer den nye versjonen frem.

Hvorfor lag på lag blir et problem

Lag i seg selv er ikke noe problem. De er faktisk en sikkerhetsmekanisme:

• Ingenting overskrives for godt. Hver solution har sitt eget lag, og kan fjernes uten å ødelegge de andre.
• Du kan alltid rulle tilbake. Avinstallerer du en solution, kommer det som lå under frem igjen.
• En leverandørs løsning kan oppdateres uten å slette tilpasningene dine, og omvendt.

Problemet oppstår når det hoper seg opp med lag ingen har kontroll på, spesielt unmanaged lag i test og produksjon:

• Oppdateringer ser ikke ut til å virke, fordi et aktivt lag ligger oppå.
• Miljøene glir fra hverandre. Produksjon er ikke lenger det samme som utvikling, og ingen vet helt hvorfor.
• Feilsøking tar lang tid, fordi du må grave i lagene for å finne ut hvilken endring som faktisk gjelder.
• Endringene finnes bare ett sted. En rask fiks i produksjon finnes ikke i utviklingsmiljøet, og blir borte eller skaper konflikter senere.

Slik rydder du opp

1. Åpne komponenten i en solution og velg See solution layers.
2. Sjekk om det ligger et aktivt (unmanaged) lag øverst, og hva det inneholder.
3. Sørg for at endringen du vil beholde finnes i utviklingsmiljøet.
4. Fjern det aktive laget med Remove active customizations.

Gode vaner

• Bygg i unmanaged i utviklingsmiljøet, og installer som managed alle andre steder.
• Ikke gjør endringer direkte i test eller produksjon. Gjør dem i utvikling og send dem videre.
• Bruk én egen publisher med et fast prefiks.
• Ikke importer en unmanaged versjon i produksjon «bare denne gangen». Den legger seg øverst og blir liggende.
• Bruk Upgrade når du importerer nye versjoner. Da fjernes også komponenter du har slettet i utvikling.
• Automatiser flyten mellom miljøene med Power Platform Pipelines eller Azure DevOps, så slipper du manuelle importer.
• Bruk managed properties for å bestemme hva som kan tilpasses i målmiljøet.

Oppsummert

Unmanaged er for å bygge, managed er for å levere. Hver solution legger seg som et lag, og det øverste laget vinner, med skjemaer som unntak der lagene slås sammen. Lagene beskytter deg, men et unmanaged lag i produksjon kan gjøre at nye versjoner aldri vises.

Hold produksjon fri for manuelle endringer, så slipper du de fleste overraskelsene.