ALM: Soluzioni e Versioning nella Power Platform

Introduzione alla gestione delle soluzioni

La gestione delle soluzioni (Solutions Management) rappresenta il cuore delle pratiche di Application Lifecycle Management (ALM) nella Microsoft Power Platform. Una soluzione è un contenitore che racchiude tutti i componenti — tabelle, app, flussi, connettori, API e regole — che costituiscono un’applicazione o una funzionalità aziendale. Il suo scopo principale è consentire la distribuzione coerente di tali componenti tra ambienti diversi (sviluppo, test, produzione).

Per poter utilizzare le soluzioni è necessario che l’ambiente Power Platform includa un database Microsoft Dataverse. In assenza di Dataverse, la funzionalità non è disponibile. L’approccio basato su soluzioni è oggi obbligatorio per distribuire componenti tra ambienti, assicurando consistenza e tracciabilità.

Tipologie di soluzioni: unmanaged e managed

Le soluzioni si dividono in due categorie principali, ciascuna con caratteristiche e scopi ben definiti all’interno del ciclo ALM.

Soluzioni Unmanaged

• Si creano manualmente o tramite codice all’interno dell’ambiente di sviluppo.
• Considerate "aperte", consentono la modifica di qualunque impostazione e componente.
• Possono essere esportate sia come unmanaged che come managed.
• La cancellazione non rimuove i componenti: questi rimangono nella Default Solution.

Le soluzioni unmanaged sono ideali nella fase di sviluppo, dove è necessario flessibilità e iterazione continua. Tuttavia, non dovrebbero mai essere distribuite in ambienti di test o produzione.

Soluzioni Managed

• Si creano solo esportando una soluzione unmanaged.
• Considerate "chiuse": i componenti possono essere bloccati per evitare modifiche.
• Possono essere importate ma non esportate.
• Sono ideali per ambienti downstream (test, staging, produzione).

Le soluzioni managed garantiscono integrità e protezione della proprietà intellettuale, particolarmente utili per ISV o per team che distribuiscono soluzioni tramite Microsoft AppSource.

Layering delle soluzioni

Il layering è un principio fondamentale per comprendere come le personalizzazioni vengono applicate in un ambiente Power Platform. Ogni componente può esistere in più livelli sovrapposti:

• System Layer: contiene le tabelle core di Dataverse, non modificabili.
• Managed Layer: include tutte le soluzioni managed importate. L’ordine di installazione influisce sulle dipendenze.
• Unmanaged Layer: ospita soluzioni aperte create o importate localmente, senza layering tra loro.

Le dipendenze tra soluzioni seguono un comportamento bottom-up: una soluzione può dipendere solo da componenti presenti in layer inferiori. Se una dipendenza non è soddisfatta, l’importazione fallisce.

Dipendenze e segmentazione

Ogni soluzione può contenere componenti che dipendono da altri, come tabelle, colonne o processi. Per ridurre l’impatto negativo delle dipendenze e migliorare la modularità, è stata introdotta la solution segmentation a partire da Dynamics 365 versione 8.0.

La segmentazione consente di includere solo un sottoinsieme dei subcomponenti di una tabella in una soluzione, facilitando il lavoro parallelo di più sviluppatori e riducendo i conflitti. È anche alla base dei concetti di patching e aggiornamento.

Patching e aggiornamento delle soluzioni

Con la segmentazione, la Power Platform introduce anche i concetti di patch e update, che migliorano la gestione delle modifiche incrementali.

Patch di soluzione

• Deriva da una soluzione unmanaged esistente.
• Contiene modifiche minori, spesso per bugfix o miglioramenti limitati.
• Blocca temporaneamente la soluzione originale fino all’esportazione della patch come managed.

Update di soluzione

Un aggiornamento è una versione successiva della soluzione principale. Durante l’importazione si può scegliere tra:

• Upgrade: aggiorna e rimuove i componenti non più presenti.
• Stage for upgrade: consente un aggiornamento differito, mantenendo temporaneamente entrambe le versioni.
• Update: aggiunge nuovi componenti senza rimuovere i vecchi (non più raccomandato).

Versionamento delle soluzioni

Ogni soluzione deve includere una versione numerica nel formato Major.Minor.Build.Revision (ad esempio, 1.0.10.125). Questa versione è fondamentale per gestire patch, upgrade e compatibilità tra ambienti. È importante distinguere la versione della soluzione interna a Dataverse da quella gestita nel repository di codice (es. Azure DevOps).

Nel contesto ALM, Azure DevOps o GitHub vengono utilizzati per tracciare le versioni delle soluzioni esportate e gestire la continuità del codice sorgente.

Configurazione e pagine HTML

Una Configuration Page è una pagina HTML web resource inclusa nel pacchetto della soluzione, utile soprattutto per ISV che desiderano consentire agli amministratori di inserire dati di configurazione, chiavi di licenza o impostazioni iniziali. Queste pagine devono implementare la logica di scrittura delle configurazioni nel Dataverse.

Le web resources HTML, CSS e JavaScript sono componenti soluzioni-aware e vengono caricate direttamente nel Dataverse. Possono essere referenziate tra loro, ad esempio:

<link rel="stylesheet" type="text/css" href="../styles/contoso.css" />

Le risorse di codice (JavaScript) possono interagire con l’API client di Dataverse, manipolare form e comunicare con servizi esterni.

Best practice Microsoft per ALM e versioning

• Usare un unico publisher per tutte le soluzioni di progetto.
• Utilizzare soluzioni unmanaged solo in sviluppo e managed negli altri ambienti.
• Seguire una rigorosa politica di versioning e naming coerente.
• Applicare la segmentazione per minimizzare conflitti e dipendenze.
• Integrare Azure DevOps per automazione di build, export e deploy.

Secondo l’esempio di Contoso Inc., l’adozione di queste pratiche ha garantito stabilità e controllo sulle distribuzioni multi-ambiente, migliorando il time-to-market e la qualità delle release.