Il tipo di environment decide che cosa puoi farci

Un environment è lo spazio in cui archiviare, gestire e condividere dati, app e flussi dell’organizzazione, e serve anche da contenitore per separare app con ruoli, requisiti di sicurezza o pubblici diversi. Ogni environment nasce sotto un tenant Microsoft Entra, è legato a una posizione geografica e può avere zero o un database Microsoft Dataverse. La pagina “Power Platform environments overview” elenca sei tipi, e il tipo — non un’impostazione successiva — ne determina le caratteristiche.

Production è destinato al lavoro permanente: la doc dice esplicitamente che è quello da usare per qualunque environment su cui si fa affidamento. Può essere creato da un amministratore o da chiunque abbia una licenza Power Apps, purché ci sia 1 GB di capacità database disponibile.

Default esiste una volta sola per tenant, viene creato automaticamente ed è condiviso da tutti. È pensato per sperimentazione, esplorazione e sviluppo leggero: non offre garanzie di backup e non va usato per carichi di produzione. Ogni nuovo utente entra automaticamente nel ruolo Environment Maker, l’environment non si può eliminare e la capacità è limitata a 1 TB.

Sandbox è qualunque environment non di produzione: offre operazioni come copy e reset, e serve a sviluppare e testare in isolamento. Con l’administration mode solo chi ha i ruoli System Administrator o System Customizer riesce ad accedere. Nota il vincolo asimmetrico: la creazione di sandbox si può riservare agli amministratori, ma la conversione di un production in sandbox non si può bloccare.

Trial copre esigenze di test a breve termine, scade dopo 30 giorni e ne è ammesso uno per utente. Developer — che la doc segnala come “formally called Community” — viene creato da chi ha la licenza Power Apps Developer Plan, è un environment a utente singolo destinato al solo proprietario e non può eseguire né condividere app di produzione; ai developer environment non si possono assegnare security group. Microsoft Dataverse for Teams viene creato automaticamente per il team selezionato quando si crea per la prima volta un’app in Teams o si installa un’app dal catalogo: qui non è disponibile alcuna personalizzazione dei security role, perché i membri vengono mappati sul loro tipo di appartenenza al team (owner, member, guest).

La creazione di developer, production e trial si può restringere agli amministratori dalle Tenant settings del Power Platform admin center.

Dove vive ciascuna fase del lavoro

Per praticare ALM servono almeno environment separati per sviluppo e produzione, ma la pagina “ALM environment strategy considerations” raccomanda di mantenere anche almeno un environment di test distinto, così da validare end-to-end non solo l’applicazione ma il deployment stesso; molte organizzazioni aggiungono UAT, SIT e training. La stessa doc suggerisce environment di sviluppo separati per isolare un lavoro non ancora concluso da quello di altri.

Chi accede dove non è un dettaglio: nella tabella di “ALM basics” gli app user non dovrebbero avere accesso allo sviluppo, e maker e sviluppatori non dovrebbero averlo in produzione, o solo a livello utente. Due vincoli tecnici pesano sulla topologia. Primo: si può importare una solution in un environment di versione più recente di quello di export, ma non in modo affidabile in uno più vecchio, perché potrebbero mancare componenti o funzionalità — da cui il consiglio di allineare gli environment di sviluppo a station di aggiornamento pari o precedenti a quelle di produzione. Secondo: la scelta di installare le app Dynamics 365 va fatta alla creazione dell’environment, perché non si possono né installare né disinstallare dopo.

Solution: che cosa viaggia e che cosa resta indietro

Le solution sono il meccanismo con cui si implementa ALM. Una solution è unmanaged o managed: le unmanaged si sviluppano e vivono negli environment di sviluppo, le managed si distribuiscono in tutto ciò che non è environment di sviluppo. Non si modificano componenti direttamente dentro una managed solution, non si esporta una managed (si esporta un’unmanaged come managed) e non si può importare una managed nello stesso environment che contiene la unmanaged originaria: per testarla serve un altro environment. Definisci un solution publisher tuo, con il suo prefix, invece di usare quello di default: una volta introdotto un publisher per un componente in una managed solution non lo si cambia più.

Che cosa non si esporta: i dati. Le solution contengono metadati e alcune tabelle di configurazione, non dati di business, e alcune tabelle di sistema non si possono aggiungere affatto. Attenzione al rovescio: eliminare una managed solution comporta la perdita dei dati nelle tabelle e nelle colonne custom che le appartengono.

I parametri che cambiano fra environment si spostano con le environment variable, di tipo Decimal number, Text, JSON, Two options, Data source o Secret. Qui c’è la raccomandazione più citata dall’esame: alla domanda “Should I include the value in my solution?” la doc risponde “No” — nella solution va la definizione, il valore va fornito per l’environment di destinazione durante il deployment. Le credenziali invece passano dalle connection reference, componenti che contengono un riferimento a una connection: durante l’import viene fornita una connection per tutte le connection reference, così i flow che le usano possono essere accesi automaticamente. Confusione tipica da evitare: una data source environment variable non è una connection — la connection rappresenta la credenziale, la variabile i parametri (sito, lista, server) che il connettore richiede. Nota anche che i flow usano connection reference per tutti i connettori, mentre le canvas app le usano solo per le connessioni implicitly shared, non OAuth, come SQL Server Authentication.

Pipeline e Git integration

Le pipelines in Power Platform non sono più in preview e portano il deployment dentro il prodotto. Si distinguono per host. Il platform host genera personal pipeline: viene provisionato per l’intero tenant al primo accesso alla pagina Pipelines, ammette tre environment (uno di sviluppo corrente e due di destinazione), non si può estendere né condividere, e default environment, environment Teams e environment senza Dataverse non possono essere destinazione. Il custom host è un environment dedicato — la doc consiglia un production dedicato — che fa da storage e management plane per configurazione, sicurezza e run history: quattro environment raccomandati, minimo tre, fino a sette stage, con i ruoli Deployment Pipeline User e Deployment Pipeline Administrator.

Il vincolo da ricordare: tutti gli environment di destinazione usati in una pipeline devono essere abilitati come managed environment, mentre l’host della pipeline e i developer environment non devono esserlo. Le pipeline non deployano unmanaged solution, il comportamento di import predefinito è Upgrade senza Overwrite customizations, e non si eseguono dalla default solution, dalle managed solution o dagli environment di destinazione. Poiché la solution viene esportata al momento della richiesta e lo stesso artefatto attraversa gli stage in ordine, nessuna personalizzazione può scavalcare lo stage di QA.

Accanto alle pipeline c’è la Dataverse Git integration, che sincronizza solution e oggetti attraverso un repository Git di Azure DevOps; la doc precisa che è pensata per i developer environment e non per test o produzione, dove si deploya con le pipeline.