Power Platform ALM

Vad är Power Platform ALM?

Applikationens livscykel beskriver det fullständiga kretslopp som en applikation normalt går igenom, om och om igen. Livscykeln består av flera delar, och hanteringen av hela detta kretslopp kallas ALM – Application Lifecycle Management.

I en fullständig ALM‑process bör alla fem delar av livscykeln ingå. I praktiken fokuserar man dock oftast på tre av dem när man talar om ALM:

• Test
• Driftsättning (Deploy)
• Förvaltning (Maintain)

Inom Power Platform används begreppet ALM ofta nästan uteslutande för själva driftsättningsdelen, och då främst i samband med automatiserade deployer. I många av våra projekt ser vi att just detta – automatiserade driftsättningar – är det område som våra kunder upplever som mest utmanande.

Andra aspekter och förutsättningar

Innan man går in på detaljer kring automatiserade deployer behöver man också ta hänsyn till andra delar som är avgörande för helheten:

• Miljöstruktur
• Lösningsstruktur
• Repository (källkodshantering)
• Användare

Miljöstruktur

För att lyckas med en ”hälsosam” ALM‑process behövs minst tre miljöer:

1. Utvecklingsmiljö, där alla förändringar görs
2. Testmiljö, dit lösningen deployas för verifiering
3. Produktionsmiljö, där lösningen lyfts när den är testad och godkänd

Utöver dessa tre kan det finnas fler miljöer, antingen i pipelinen eller vid sidan av som stödjande miljöer. I pipelinen kan man till exempel ha ytterligare en utvecklingsmiljö där kunden själv – eller ett annat team – gör förändringar. Stödjande miljöer kan användas för prestandatester, utvärdering av nya releaser från Microsoft eller för hotfixar.

Lösningsstruktur

En annan viktig del av ALM är hur lösningarna är strukturerade. En rekommendation, både från Microsoft och CRMK, är att alla miljöer utom utvecklingsmiljön körs med Managed solutions.

Även antalet och typen av lösningar spelar stor roll. Microsoft rekommenderar en miljö per unmanaged solution. Trots detta har vi ofta flera unmanaged solutions i samma utvecklingsmiljö när det finns ett tydligt behov. Det kan till exempel handla om separata lösningar för datakällor eller regler för automatisk postskapande (ARC).

Repository

Microsofts rekommendation för en välfungerande ALM‑process är att lagra en uppackad version av den unmanaged lösningen i ett repository. Det görs lämpligen i samma repository som används för kod, till exempel plugins eller TypeScript.

Även i projekt som inte innehåller traditionell kod – rena low‑code‑ eller no‑code‑lösningar – skapar vi ett repository. Där lagras både lösningen och YAML‑definitioner för automatiserade export‑ och deploypipelines.

Användare

Innan ni skapar era automatiserade pipelines är det klokt att lägga tid på att definiera en tydlig användarstrategi. Det handlar dels om vilka behörigheter som krävs för att deploya lösningar, dels om vilka användare som används av lösningen i drift.

Vanligtvis använder vi en Application Registration (Service Principal) som den användare som ansvarar för deployment. Fördelen är att alla komponenter ägs av denna användare, vilket säkerställer att de fortsätter fungera även om utvecklare lämnar organisationen.

Utöver detta kan det finnas behov av servicekonton, beroende på vilka flöden och connectors som används.

Om din organisation bygger lösningar i Power Platform och upplever osäkerhet kring releaser, test eller ägarskap är ALM ofta den saknade pusselbiten. Med rätt struktur går det att kombinera snabb utveckling med hög kontroll.

Vill du diskutera hur en ALM‑process kan utformas utifrån era förutsättningar hjälper vi gärna till – oavsett om ni står inför ett första införande eller behöver ta nästa steg i en befintlig setup.