Che cosa sposta una pipeline, e in quale ordine

Una pipeline in Power Platform sposta una solution da un ambiente di sviluppo verso uno o più ambienti di destinazione, senza export e import manuali. Il maker la trova nella pagina Pipelines dentro una solution unmanaged, oppure dal pulsante Deploy nella vista Overview; scelto lo stage (per esempio Deploy to Test) e Deploy here, si apre il pannello di distribuzione. Si decide se distribuire Now o pianificare per Later, poi il sistema esegue la validazione della solution contro l’ambiente di destinazione — la documentazione la chiama anche preflight checks — che intercetta dipendenze mancanti e altri problemi comuni prima che la distribuzione parta.

Subito dopo arriva il passaggio che l’esame ama: se la solution contiene connection reference o environment variable, al maker viene chiesto di fornirne i valori, esattamente come in un import manuale. Tenete separati i tre oggetti che qui si confondono. Una connection reference è un componente della solution che punta a una connection, cioè a una credenziale memorizzata per un connettore. Una environment variable è un valore di configurazione che cambia da ambiente ad ambiente. Una variabile globale di Copilot Studio è invece stato di conversazione dentro l’agente e non ha alcun ruolo nel rilascio.

Tre vincoli strutturali. Gli stage si completano in ordine: la stessa versione della solution deve passare per gli stage precedenti, e il sistema non riesporta l’artefatto per gli stage successivi, così nessuna personalizzazione può scavalcare l’ambiente di QA o le approvazioni. Tutti gli ambienti di destinazione devono essere abilitati come managed environment, mentre l’host e gli ambienti di sviluppo non lo richiedono. E le pipeline non distribuiscono solution unmanaged: verso gli ambienti non di sviluppo va la versione managed. Attenzione anche a dove la pipeline si vede: “Pipelines aren’t visible within the default solution, managed solutions, or target environments.” Cioè niente Default Solution, niente solution managed e nessuna guida dall’ambiente di arrivo.

Personal pipeline sul platform host: comoda, ma con un tetto

Alla prima visita della pagina Pipelines in un ambiente non già associato a un host personalizzato, viene provisionato il platform host, disponibile per tutto il tenant. Da lì un maker crea una personal pipeline con Create pipeline: nome, descrizione e Target environment, con l’elenco filtrato sugli ambienti dove ha già accesso di import. Con Add stage il proprietario può aggiungere uno stage, ma solo a una pipeline a stage singolo.

Il tetto è esplicito, e vale come domanda d’esame: la personal pipeline non si estende, non si condivide con altri utenti, e associa tre ambienti — l’ambiente di sviluppo corrente più due destinazioni. Ambienti default, ambienti Teams e ambienti senza store Dataverse non possono fare da destinazione. Inoltre un ambiente può essere associato a un solo host: per passare a un host personalizzato bisogna eliminare i record ambiente nel platform host, oppure usare Force Link, così da liberarli.

Custom host: l’applicazione va installata solo nell’host

Quando servono più destinazioni, condivisione ed estensibilità, si passa a un custom host. L’host è un ambiente dedicato che fa da piano di archiviazione e gestione per configurazione, sicurezza e run history; si crea da Deployments e New custom host nel Power Platform admin center, oppure installando l’applicazione Power Platform Pipelines in un ambiente esistente da Resources e Dynamics 365 apps. Il punto che si sbaglia più spesso: l’applicazione si installa solo nell’ambiente host, non negli ambienti di sviluppo, di test o di produzione.

Poi, nella Deployment Pipeline Configuration app, si creano i record in Environments con Environment Type impostato su Development Environment o Target Environment e con Environment Id corretto, verificando che Validation Status risulti Success. La pipeline si compone con Linked Development Environments e con i Deployment Stages, dove ogni stage ha Previous Deployment Stage e Target Deployment Environment. L’accesso si governa con i ruoli Deployment Pipeline User e Deployment Pipeline Administrator, e condividendo il record della pipeline.

Estendere: approvazione e delegated deployment

L’estensione poggia sui business events di Microsoft Dataverse, quindi la logica si scrive come cloud flow nell’ambiente host. Tre gated extension inseriscono uno step custom in punti diversi della progressione: Pre-export Step Required, Is delegated deployment e Pre-deployment Step Required. Non confondeteli: il primo valida prima dell’export dall’ambiente di sviluppo, il terzo aggiunge uno step dopo l’approvazione, il secondo cambia l’identità che distribuisce.

Is delegated deployment è la risposta al caso in cui i maker non hanno privilegi in produzione: lo stage distribuisce con l’identità di un service principal oppure dello Stage Owner invece che del maker richiedente, e richiede approvazione da un’identità autorizzata. Il flow parte dal trigger OnApprovalStarted, esegue l’approvazione e chiude con Perform an unbound action sull’azione UpdateApprovalStatus, dove 20 completa e 30 rifiuta lo step. La connection usata da quell’azione deve essere quella del delegato, altrimenti il sistema respinge l’approvazione. Chi possiede gli oggetti distribuiti? L’identità che distribuisce: nel delegated deployment il service principal o lo stage owner, non il maker.

Per far scattare la logica solo su uno stage si usa una trigger condition:

@equals(triggerOutputs()?['body/OutputParameters/DeploymentStageName'], 'Contoso UAT')

Ricordate infine la regola che chiude il cerchio: le personal pipeline create in Power Apps non si possono estendere. Se lo scenario parla di approvazione o di identità delegata, l’host è custom.