Che cosa viaggia dentro una solution e che cosa resta indietro

Un agente costruito in Microsoft Copilot Studio non è un file: è un insieme di record in Microsoft Dataverse, e vive dentro un environment di Power Platform. Quando lo crei viene aggiunto automaticamente a una default solution, che però non è esportabile in modo utile: per muovere l’agente fra ambienti devi crearlo, o spostarlo, dentro una custom solution con un publisher e un prefisso propri. Da architetto la domanda non è “come esporto”, ma “che cosa è realmente contenuto nell’artefatto che sto promuovendo”.

La documentazione è esplicita su ciò che non è solution-aware in Copilot Studio e richiede quindi passaggi post-deployment sull’ambiente a valle: le impostazioni di Azure Application Insights, le impostazioni di manual authentication, la sicurezza dei canali Direct Line e Web, i canali pubblicati e la condivisione dell’agente. Aggiungi che dopo l’import devi riconfigurare l’autenticazione utente e devi pubblicare l’agente importato prima di poterlo condividere. Un architetto che promette “un click e siamo in produzione” ha già sbagliato il disegno: il runbook di rilascio deve elencare questi passi manuali e assegnarli a un ruolo.

Attenzione anche alle action e ai connector. Se l’agente usa un custom connector, l’ordine è vincolante: prima il custom connector, poi la connection reference insieme alla solution dell’agente. Gli agent flow e le loro dipendenze vanno inclusi con Add required objects, altrimenti l’import fallisce per componenti mancanti. Le component collection — insiemi riutilizzabili di topic, knowledge, action ed entità — si trasportano anch’esse via solution e permettono a team diversi di rilasciare con cadenze indipendenti.

Strategia di ambienti: dove si costruisce, dove si valida, dove non si tocca

La regola minima è tre ambienti: development, test, production. La documentazione chiede di configurare la produzione come environment di tipo production e tutti gli altri, development e test inclusi, come sandbox, e di proteggere ciascun ambiente con un Entra Security Group che ne limiti l’accesso ai soli membri. Le ALM golden rules aggiungono il criterio che l’esame ama: non personalizzare fuori da un ambiente di sviluppo, lavorare sempre nel contesto di una solution, esportare come managed salvo che tu stia allestendo un ambiente di sviluppo.

Il motivo è strutturale, non stilistico. In Dataverse esistono un unmanaged layer unico e i managed layer, e il layer in cima determina il comportamento a runtime. Se un maker “sistema al volo” un topic direttamente in produzione crea un unmanaged layer sopra il componente managed: quella modifica governa il runtime, non esiste in sviluppo, non sarà mai riesportata (le managed solution non si esportano) e sopravvive alle release successive finché qualcuno non esegue Remove unmanaged layer. È esattamente il divario fra artefatto collaudato e artefatto in esecuzione che l’ALM deve rendere impossibile.

La segmentazione per rischio completa il quadro: gli agenti personali stanno in Developer environment con la condivisione disattivata, gli agenti di reparto in ambienti gestiti dall’IT con pipeline e approvazione dell’admin alla pubblicazione, gli agenti mission-critical seguono gli standard ALM dell’organizzazione. Non confondere questo ciclo con il deployment lifecycle di un agente in Microsoft Foundry: sono due catene di rilascio distinte, e una domanda che parla di solution, environment variable e pipeline sta parlando di Power Platform.

Parametrizzare: connection reference ed environment variable

Ciò che cambia fra ambienti non deve essere dentro il codice dell’agente. Le connection reference disaccoppiano l’action dalla credenziale concreta, le environment variable tengono fuori endpoint, identificativi e impostazioni. Pipelines in Power Platform chiede connessioni e valori delle environment variable in anticipo e li valida prima che il deployment inizi, così l’agente arriva collegato alla sorgente dati giusta senza post-processing manuale. Due limiti da ricordare in fase di design: una connection reference priva di valore nella solution o nell’ambiente di destinazione non può essere aggiornata durante il deployment, e un delegated deployment eseguito come pipeline stage owner non può portare solution che contengono connection reference per connessioni OAuth — lì serve un service principal.

Scenario tipico da esame: una compagnia assicurativa deve rilasciare un agente di service desk che chiama un ERP tramite custom connector, con il vincolo di dimostrare all’auditor che il binario collaudato in UAT è lo stesso installato in produzione e che nessun maker ha accesso in scrittura alla produzione. La risposta non è “esportiamo e importiamo a mano”.

Sigillare la catena: pipeline, approvazioni, produzione chiusa

Pipelines in Power Platform esporta la solution nel momento in cui il maker invia la richiesta di deployment e distribuisce lo stesso artefatto a tutti gli stadi successivi, in ordine sequenziale, impedendo modifiche o manomissioni: nessuna personalizzazione può scavalcare l’ambiente di QA o il processo di approvazione. Le delegated deployments completano il disegno: lo stadio esegue come service principal o come stage owner, il deployment resta in pending finché non viene approvato (trigger OnApprovalStarted), e il delegato ha Deployment Pipeline Administrator sull’host e System Administrator sul target. Il maker ottiene il rilascio senza avere permessi in produzione.

L’ultimo lucchetto è l’impostazione Block unmanaged customizations, che si attiva per ambiente dall’area Features del Power Platform admin center e blocca import di solution unmanaged, creazione di nuovi componenti e modifiche unmanaged su componenti managed, lasciando passare il cambio di valore di una environment variable e la rimozione di un unmanaged layer. Qui l’architetto deve dichiarare un compromesso reale: fra le limitazioni note, con l’impostazione attiva la pubblicazione di un agente Copilot Studio non funziona. In un ambiente che ospita anche authoring non puoi accenderla e basta.

L’esame verifica proprio questo: sa distinguere chi propone una catena in cui l’artefatto validato è per costruzione lo stesso che arriva in produzione da chi descrive un export manuale ripetuto tre volte. E non confondere l’ALM con la evaluation o con il monitoring: la pipeline garantisce che sia stato promosso l’oggetto giusto, non che l’agente risponda bene.