Su Power Platform ogni personalizzazione — table, column, model-driven app, Power Automate flow, plugin, Power Apps component framework (PCF) control — non vive isolata: viene trasportata tra ambienti dentro una solution. Per il PL-400 devi ragionare da developer, cioè capire come le solution si stratificano e come automatizzarne il ciclo di vita con Power Platform CLI (pac).

Managed vs unmanaged

La differenza è il cuore dell’ALM (Application Lifecycle Management).

  • Unmanaged: è la solution “di lavoro”. Nell’ambiente di dev costruisci sempre in unmanaged, perché i componenti sono modificabili, aggiungibili e rimovibili. È lo stato editabile.
  • Managed: è il pacchetto “sigillato” che deploi in test e prod. I componenti non sono modificabili direttamente, la disinstallazione rimuove pulitamente ciò che ha portato, e le personalizzazioni sono governate dal layering.

Regola d’oro: si sviluppa unmanaged, si distribuisce managed. Non importare mai una unmanaged in produzione: diventa parte del default layer e non la disinstalli più in modo pulito.

Publisher e prefix

Ogni solution ha un publisher che definisce il customization prefix (es. contoso_) e l’option value prefix per le choice. Impostali all’inizio: cambiare il publisher a posteriori non rinomina i componenti già creati. Un prefix coerente è fondamentale per riconoscere i tuoi asset e per il naming negli scenari managed.

Solution layering e dipendenze

Quando più solution managed toccano lo stesso componente, Dataverse costruisce uno stack di layer: l’ordine di importazione determina chi vince (“last one wins” sulla proprietà modificata). Sopra tutto c’è l’eventuale unmanaged (active) layer, che ha sempre la precedenza.

Qui nasce la trappola classica: modificare direttamente un componente managed in test/prod crea un unmanaged layer che maschera il valore managed. Al deploy successivo la tua modifica sembra ignorata, perché l’active layer soprastante continua a vincere. La soluzione è rimuovere l’unmanaged layer (Remove active customization) e ripartire dalla modifica in dev.

Le dependencies vanno gestite a monte: se una solution referenzia una table di un’altra, quella deve essere presente (o inclusa come dependency) nell’ambiente target, altrimenti l’import fallisce.

Passaggio dev → test → prod

Il flusso base è export dalla dev (unmanaged per il source control, managed per il deploy) e import nei target. Per governare tutto usa le Power Platform Pipelines, che orchestrano la promozione tra ambienti con approvazioni, senza scriptare a mano ogni import.

Power Platform CLI (pac)

pac è lo strumento da developer per automatizzare l’ALM e integrare source control e CI/CD (Azure DevOps o GitHub Actions).

pac solution export --name Contoso --managed true
pac solution unpack --zipfile Contoso.zip --folder src
pac solution import --path Contoso.zip

Il pattern chiave è solution unpack: scompatta lo zip in file granulari (XML, JSON, codice) da committare in Git. Così ottieni diff e merge reali invece di versionare un blob binario. In pipeline, solution pack ricompone lo zip prima dell’import. pac gestisce anche PCF (pac pcf), plugin, connection reference e environment variable.

Dati vs metadati

Punto d’esame ricorrente: le solution trasportano metadati e componenti, non i record. Per migrare dati di configurazione (record di reference/seed) tra ambienti si usa il Configuration Migration tool (parte dei Power Platform CLI/SDK tools), che esporta/importa row di Dataverse via schema. Non confondere pac solution (struttura) con la migrazione dati (contenuto delle table).

Trappole tipiche d’esame

  • Scenario: in un ambiente di produzione con una solution managed devi cambiare un form → Risposta: non modificarlo direttamente (creeresti un unmanaged layer che va rimosso), applica la modifica in dev e ridistribuisci la managed.
  • Scenario: serve versionare le personalizzazioni in Git con diff leggibili → Risposta: pac solution unpack per generare file di source control, non il file .zip esportato.
  • Scenario: devi spostare record di configurazione (non tabelle/campi) da test a prod → Risposta: Configuration Migration tool, non l’export/import di solution.
  • Scenario: dopo un import in prod le tue modifiche “spariscono” → Risposta: c’è un active (unmanaged) layer che maschera il managed; rimuovi la active customization.
  • Scenario: deploy verso produzione di una app funzionante in dev → Risposta: esporta e importa la solution come managed; l’unmanaged è solo per dev e source control.