Come Solution Architect non progetti solo l’applicazione, ma anche la catena che la porta dallo sviluppo alla produzione in modo ripetibile, tracciabile e reversibile. In PL-600 il tema Application Lifecycle Management (ALM) è trasversale: definire il flusso di deployment, i gate di qualità e il modello di source control è una responsabilità architetturale, non un dettaglio DevOps.

Il principio non negoziabile: solution + automazione

Ogni personalizzazione deve vivere dentro una solution gestita (managed) negli ambienti a valle e unmanaged solo nell’ambiente di sviluppo (dev). Il deploy di solution managed in test/produzione garantisce che le componenti siano immutabili in loco e disinstallabili in blocco: è ciò che rende possibile il rollback affidabile. Personalizzare direttamente in produzione, o esportare/importare manualmente via UI, distrugge questa proprietà: perdi la ripetibilità, l’audit trail di chi ha promosso cosa e quando, e la capacità di ricostruire un ambiente.

La topologia minima raccomandata resta dev → test → prod, con dev separati per publisher/team quando i workstream sono paralleli, per poi convergere tramite branch e merge.

Scegliere l’orchestratore: Power Platform Pipelines vs Azure DevOps/GitHub Actions

Power Platform Pipelines (in-product, gestite da un ambiente host) sono la scelta consigliata quando:

  • il team è maker-centrico e non gestisce YAML o repository Git;
  • il requisito è promuovere solution tra ambienti con approvazioni e governance centralizzata, in tempi rapidi;
  • non serve integrare artefatti esterni (codice pro-dev, componenti PCF buildate, test automatici complessi).

Passi a Azure DevOps Pipelines o GitHub Actions (con Power Platform Build Tools / microsoft/powerplatform-actions) quando emerge anche solo uno di questi requisiti:

  • source control reale con branching, pull request e code review come gate umano;
  • pipeline che orchestra anche build di plug-in .NET, PCF, portali o test automatizzati;
  • gestione strutturata delle variabili d’ambiente e connection reference per il deployment settings file, con secret in Azure Key Vault;
  • necessità di audit enterprise e integrazione con work item.

In pratica, molti clienti adottano un modello ibrido: Pipelines per la promozione self-service dei maker, Azure DevOps per i workload pro-code. Dal punto di vista del pilastro Operational Excellence del Well-Architected Framework, la regola è: l’orchestratore deve eliminare il gesto manuale, non spostarlo.

La pac CLI come motore del ciclo

La Power Platform CLI (pac) è lo strumento che rende gli step scriptabili e identici in locale e in pipeline. Il pattern architetturale di riferimento è:

  • pac solution export dall’ambiente dev (managed e unmanaged);
  • pac solution unpack per esplodere la solution in file granulari da committare in Git — così i diff sono leggibili e il merge tra maker è gestibile (il .zip monolitico è opaco al source control);
  • in pipeline, pac solution pack ricostruisce l’artefatto;
  • pac solution import con il settings file (--settings-file) per iniettare i valori corretti di environment variable e connection reference per ambiente, senza toccare la solution.

Questo separa nettamente codice (la solution) da configurazione (i settings per ambiente), un principio chiave di affidabilità.

Gate di qualità: Solution Checker

Il Solution Checker (invocabile via pac solution check o come task di pipeline) deve essere un gate bloccante prima della promozione: analizza performance, sicurezza e uso di API non supportate, restituendo severità. Progetta la pipeline perché un finding Critical/High fermi il deploy (fail the build), non che generi solo un report ignorabile. Aggiungi, dove serve, test funzionali (Test Studio, Playwright/EasyRepro) come gate ulteriore. È l’applicazione concreta del pilastro Reliability: si promuove solo ciò che ha superato controlli automatici.

Trappole tipiche d’esame

  • Il maker ha modificato una app direttamente in produzione per un fix urgente → requisito: ripetibilità e audit. Soluzione: vietare la personalizzazione in prod; il cambiamento parte da dev, viene esportato come solution managed e promosso via pipeline. Il deploy manuale via UI è la risposta sbagliata.
  • Due team lavorano sulla stessa solution e i loro cambiamenti si sovrascrivono. Soluzione: pac solution unpack + source control con branching e pull request, così i merge sono espliciti e revisionabili.
  • Le connection reference e le environment variable puntano ancora a dev dopo l’import in test. Soluzione: deployment settings file per ambiente passato a pac solution import, con i secret in Key Vault — non valori hard-coded nella solution.
  • Serve garantire che nessuna app con problemi di performance/sicurezza raggiunga la produzione. Soluzione: Solution Checker come gate bloccante in pipeline che fa fallire la build sui finding critici.
  • Team di soli maker, nessuno gestisce YAML, ma serve governance con approvazioni. Soluzione: Power Platform Pipelines in-product; Azure DevOps/GitHub Actions sarebbe sovradimensionato se non ci sono artefatti pro-code o esigenze di branching avanzate.