Una soluzione robusta di Application Lifecycle Management (ALM) è ciò che distingue un progetto Power Platform maturo da una raccolta di modifiche fatte “a mano” in produzione. Come functional consultant devi saper progettare il flusso con cui una customizzazione nasce, viene testata e arriva agli utenti finali in modo ripetibile e reversibile.

Ambienti separati come pilastro dell’ALM

Il principio di base è la separazione degli environments per stadio del ciclo di vita:

  • Development (dev): qui i maker lavorano su unmanaged solution, con i componenti editabili (app, flow, tabelle Dataverse, ruoli di sicurezza).
  • Test / QA: riceve le modifiche come managed solution per validare in condizioni simili alla produzione, includendo UAT e verifica delle dipendenze.
  • Production: ospita solo managed solution, dove nessuno modifica direttamente i componenti.

Ogni environment è associato a un proprio Dataverse database. La separazione non è solo organizzativa: protegge gli utenti da lavori incompleti e permette di promuovere modifiche in blocco anziché componente per componente.

Unmanaged vs managed

  • Una unmanaged solution è il “sorgente”: modificabile, tipicamente esportata dall’ambiente di sviluppo e conservata in un repository (source control).
  • Una managed solution è il “pacchetto compilato”: in destinazione i componenti sono in sola lettura e la solution può essere disinstallata pulitamente, rimuovendo i propri componenti.

Regola d’oro d’esame: si sviluppa unmanaged, si distribuisce managed.

Solution layering

Quando più solution toccano lo stesso componente, Dataverse costruisce una pila di layer. Esistono due tipi:

  • Managed layers: impilati nell’ordine di importazione; l’ultima managed solution importata vince sulle proprietà che modifica.
  • Unmanaged layer: sta sopra tutti i managed layer. Se esiste, la sua personalizzazione ha la precedenza e maschera il valore definito dalle managed solution sottostanti.

Capire il layering spiega perché una modifica manuale in produzione “sopravvive” a un deployment ma allo stesso tempo blocca gli aggiornamenti provenienti dal pacchetto managed.

Power Platform Pipelines

Le Power Platform Pipelines automatizzano la promozione tra ambienti direttamente dentro la piattaforma, senza dover configurare Azure DevOps o GitHub Actions. Con esse:

  • definisci uno host environment e le stage (es. Dev → Test → Prod);
  • il maker esegue il deploy con export automatico come managed e import in destinazione;
  • puoi aggiungere pre-deployment approval per introdurre governance.

Sono la scelta consigliata quando il team è composto da maker/functional consultant che vogliono un ALM strutturato ma a basso attrito. Per pipeline CI/CD complesse, con test automatici e gestione avanzata dei branch, si passa invece a Azure DevOps o GitHub con la Power Platform Build Tools / Power Platform CLI (pac solution export, pac solution import).

Extending: il confine maker / pro-developer

La maggior parte dello scenario PL-200 si risolve con componenti dichiarativi. Ma alcuni requisiti richiedono extending, cioè codice pro-developer:

  • Plug-in: logica server-side registrata sull’event pipeline di Dataverse (es. sincrona su Update per validazioni complesse), quando business rule e flow non bastano.
  • Custom component / PCF (Power Apps Component Framework): controlli UI custom code-based.
  • Custom API / azioni e web resource JavaScript.

Come functional consultant devi riconoscere quando serve questa estensione e coinvolgere il pro-developer, non necessariamente scriverla. Fondamentale: anche i plug-in e i PCF viaggiano dentro le solution, quindi rientrano nella stessa strategia ALM.

Trappole tipiche d’esame

  • Scenario: un amministratore modifica un form direttamente in produzione; al successivo import della managed solution l’aggiornamento non compare. → Risposta giusta: la modifica ha creato un unmanaged layer sopra i managed layer, che maschera il valore del pacchetto; va rimosso (rimuovi la personalizzazione unmanaged / “Remove active customization”) per far tornare visibile la managed.
  • Scenario: serve promuovere le modifiche da dev a produzione con approvazioni ma senza infrastruttura DevOps. → Risposta giusta: usa Power Platform Pipelines con stage e pre-deployment approval.
  • Scenario: distribuzione in produzione con componenti editabili dagli utenti. → Risposta giusta: errore; in produzione si importa sempre managed, non unmanaged.
  • Scenario: una validazione cross-record sincrona non realizzabile con business rule/flow. → Risposta giusta: plug-in registrato sull’event pipeline (extending pro-developer).
  • Scenario: si vuole conservare il “sorgente” per il source control. → Risposta giusta: esporta la unmanaged solution dall’ambiente di sviluppo, non la managed.