Come Solution Architect su Power Platform, la strategia di Application Lifecycle Management (ALM) è una delle prime decisioni di design che condizionano tutto il ciclo di vita: come impacchetti, versioni, sposti e ripristini le personalizzazioni tra ambienti. La solution è l’unità di trasporto; progettarla male significa deploy fragili e impossibilità di hotfix mirati.

Managed vs unmanaged: la scelta di fondo

Il primo trade-off è tra solution unmanaged e managed.

  • Unmanaged: contenitore di sviluppo. I componenti sono modificabili, non esiste un vero confine e la disinstallazione non rimuove nulla. È lo stato corretto solo nell’ambiente di DEV.
  • Managed: artefatto di rilascio immutabile. Applica il solution layering, protegge i componenti, permette upgrade e uninstall pulite (con rimozione dei componenti orfani via managed solution upgrade).

Raccomandazione di design: DEV in unmanaged, tutti gli ambienti a valle (TEST, UAT, PROD) esclusivamente in managed, importati da una pipeline. Consegnare unmanaged in produzione è un errore architetturale: mescoli sviluppo e runtime, perdi la capacità di rimuovere il layer e rendi il rollback inaffidabile. Questo si allega direttamente al pilastro Operational Excellence del framework di eccellenza operativa: ambienti riproducibili e deploy deterministici.

Solution layering e gestione dei layer

Ogni solution managed aggiunge un layer sopra il system layer. Quando più solution toccano lo stesso componente, l’ordine di importazione determina il valore attivo (last writer wins tra i managed layer). Gli unmanaged layer stanno sempre sopra tutti i managed e ne “mascherano” le proprietà: un unmanaged customization fatto in produzione (magari con un hotfix manuale) crea un layer che sovrascrive i futuri upgrade managed. Va rimosso con Remove active customization.

Design implication: definisci un ordine di deploy stabile delle solution e vietane la modifica diretta in PROD, così il layering resta prevedibile.

Segmentazione: il cuore della strategia

Una singola solution monolitica non segmentata è l’anti-pattern classico: impossibile fare deploy selettivi, ogni rilascio trascina tutto, gli hotfix diventano rischiosi e il rollback impraticabile.

Segmenta per ritmo di rilascio e ownership, non per capriccio:

  • Solution di base/core (data model condiviso, tabelle, security roles) con cadenza lenta.
  • Solution funzionali per area/feature, deployabili in modo indipendente.
  • Eventuali solution di configurazione per dati di riferimento gestiti come artefatti.

Usa le segmented solution (aggiungendo i singoli asset di una tabella — colonna, form, view specifici — invece dell’intera tabella con Include all components) per ridurre le dipendenze trasportate e minimizzare la superficie di conflitto tra team.

Publisher, prefix e dipendenze

Definisci un solo publisher personalizzato per soluzione/prodotto, con prefix e option value prefix coerenti (es. contoso) fin dal primo giorno: il prefix è di fatto immutabile e distingue i tuoi componenti da quelli di default. Publisher incoerenti tra solution generano naming caotico e conflitti.

Le dipendenze sono il vincolo dell’import: una solution che referenzia un componente presente in un’altra solution ne richiede la presenza a destinazione. Progetta un grafo di dipendenze aciclico (le core non devono dipendere dalle funzionali) e ordina di conseguenza il deploy.

Collegamento a source control e ALM ripetibile

Il solution management ha valore solo dentro un flusso ALM ripetibile:

  1. Export unmanaged da DEV → unpack (Power Platform CLI / pac solution unpack) in file granulari.
  2. Commit su Git (Azure DevOps o GitHub): il source control è la single source of truth, non l’ambiente.
  3. Build managed da pipeline (Power Platform Build Tools / Actions), non esportando manualmente il managed dalla UI.
  4. Deploy automatizzato verso gli ambienti a valle con Power Platform Pipelines o pipeline custom, con approvazioni per ambiente.

Trade-off Power Platform Pipelines vs Azure DevOps/GitHub: le Pipelines native sono più rapide da adottare e governate in-platform (ideale per team citizen/pro-dev misti); Azure DevOps/GitHub offrono controllo totale su gate, test, branching e integrazione con il resto dell’estate — preferibili in scenari enterprise con requisiti di compliance stringenti.

Trappole tipiche d’esame

  • Requisito: hotfix urgente in PROD senza rifare tutto il rilascio → soluzione: segmenta in più managed solution per feature e distribuisci solo quella impattata; mai una solution monolitica.
  • Requisito: rimuovere componenti obsoleti durante l’aggiornamento → soluzione: usa managed solution upgrade (Stage for Upgrade), non Update, perché solo l’upgrade elimina i componenti non più presenti.
  • Requisito: source control come fonte di verità con più sviluppatori → soluzione: unpack con Power Platform CLI + commit su Git e build managed in pipeline; non esportare manualmente il managed dalla UI.
  • Requisito: un fix manuale in PROD non deve rompere i futuri deploy → soluzione: individua e rimuovi l’unmanaged layer (Remove active customization) che maschera il managed.
  • Requisito: convivenza di più team senza conflitti sugli stessi oggetti → soluzione: segmented solutions + un solo publisher/prefix coerente e un grafo di dipendenze aciclico core→funzionali.