Copilot Managed Runtime: dalla CLI al deploy

Copilot Managed Runtime, in concreto

Copilot Managed Runtime è un ambiente gestito per le app aziendali interne. Il codice resta modificabile, il controllo versione continua a basarsi su un vero repository Git e Microsoft fornisce runtime ospitato, accesso con Microsoft Entra, connessioni dati governate, meccanismi di anteprima e deployment e un inventario amministrativo.

È come un edificio di uffici con tutti i servizi inclusi, ma destinato al codice. Sei tu a decidere cosa accade in ogni stanza; l’edificio mette a disposizione reception e badge, utenze, regole di sicurezza, registro della manutenzione e personale tecnico. Non è quindi la stessa cosa di un ambiente di coding con AI che si limita a disegnare la pianta delle stanze.

Microsoft presenta l’SDK come il livello di sviluppo per le app interne line-of-business. Include l’autenticazione Entra senza codice di identità personalizzato e consente di accedere da JavaScript e TypeScript a più di 1,500 connettori; sono però i criteri del tenant a stabilire quali connettori e quali azioni possa usare davvero l’app. La panoramica dell’SDK in anteprima pubblica e l’annuncio di lancio definiscono bene questi confini.

Questa guida segue l’SDK e la CLI disponibili oggi. Copilot Code e Autopilot non vengono trattati come nomi intercambiabili dello stesso insieme di strumenti.

Dove risiede davvero l’app

La risposta cambia nelle diverse fasi del ciclo di vita:

Questa separazione è importante. L’anteprima può avanzare mentre la versione live rimane stabile; inoltre, una build di anteprima non riuscita non sostituisce l’ultima versione funzionante.

Prima i requisiti, poi il codice

Il modo più rapido per perdere una giornata è scoprire un vincolo di tenant o licenza quando l’app è già pronta. Conviene verificare subito questi cinque punti.

Le opzioni di fatturazione e i criteri amministrativi richiedono una decisione di budget dedicata. Prima di consentire l’accesso a un gruppo pilota, consulta l’analisi dei prezzi di Copilot Managed Runtime. Un dettaglio operativo va chiarito subito: l’esecuzione locale non è una scappatoia gratuita. Richiede la stessa copertura runtime di un utente finale.

Le verifiche effettuate per questa guida

Il pacchetto è stato controllato davvero; il test nel tenant, invece, non è stato eseguito.

Di conseguenza, questo articolo non dichiara né un tempo misurato fino alla prima pagina locale o all’anteprima ospitata, né un errore di build osservato, un’identità Entra ispezionata, una chiamata a un connettore eseguita, un deployment o un addebito runtime. I passaggi che seguono descrivono il percorso documentato da Microsoft, non un test di laboratorio mascherato.

Dalla CLI a una piccola app operativa

Useremo un’app sintetica chiamata Ops Intake. Il primo obiettivo è volutamente limitato: mostrare in una coda di sola lettura i record provenienti da un’unica fonte approvata dal tenant. Partire da un’operazione di lettura rende comprensibile la prima revisione dei criteri. Le operazioni di scrittura vanno aggiunte solo dopo aver verificato identità, autorizzazioni della fonte, criteri sui connettori e copertura runtime.

Per rendere la procedura riproducibile, la sequenza fissa la versione della CLI verificata il 27 settembre 2026. Registra nel repository la versione scelta, così un aggiornamento del pacchetto in anteprima non potrà modificare il progetto pilota senza che nessuno se ne accorga.

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

Vediamo cosa significa ogni passaggio.

1. Accedi e crea l’involucro governato

ms auth login apre l’accesso con Microsoft Entra. Su un sistema senza interfaccia grafica, la CLI offre anche --device-code. ms app create crea il record dell’app, genera la struttura iniziale del progetto e, per impostazione predefinita, usa un repository Git gestito dalla piattaforma. Alla prima creazione o inizializzazione viene predisposto anche l’ambiente di sviluppo personale associato all’identità del maker, se le regole di routing lo consentono.

La modalità del repository non va scelta con leggerezza. Il Git gestito dalla piattaforma è il punto di partenza più rapido. Come repository esterno si può usare GitHub.com oppure GitHub Enterprise Cloud. GitHub Enterprise Server, Azure DevOps e gli altri provider non sono supportati in questo percorso. La modalità del repository resta fissa per l’intera vita dell’app: per cambiarla in seguito bisogna creare un’altra app.

2. Esegui l’app in locale e misura il primo risultato utile

Installa una volta le dipendenze predisposte dal progetto, quindi esegui ms app dev. Il comando legge ms.config.json, avvia il processo di sviluppo del progetto e mostra un Local Play URL. Aprilo nello stesso profilo del browser usato per il tenant.

Avvia un cronometro subito prima di ms app dev e fermalo quando compare la prima pagina utilizzabile. Annota separatamente le interruzioni dovute alle autorizzazioni del browser. Chrome e Microsoft Edge possono impedire a un’origine pubblica di raggiungere localhost finché non viene concesso l’accesso alla rete locale: è un vincolo del browser, non un errore della build dell’applicazione.

3. Verifica una lettura governata

ms connector list mostra ID del connettore, tipo di autenticazione, supporto tabellare e stato sia di Data Loss Prevention sia di Advanced Connector Policy. Considera questo output la fonte ufficiale per l’ambiente. La presenza di un connettore nel catalogo Microsoft non significa che sia automaticamente consentito nel tenant.

Per Ops Intake, seleziona una connessione SharePoint autorizzata, un dataset e un elenco, quindi scegli un’operazione di lettura o di elenco. Il flusso interattivo ms app add data-source genera modelli e servizi TypeScript tipizzati in generated/. Richiama dall’app il metodo di lettura generato, invece di costruire un flusso personalizzato basato su token Graph.

Nel browser, verifica tre aspetti:

1. L’utente connesso corrisponde all’identità Entra prevista.
2. L’utente vede soltanto i record già autorizzati dal sistema di origine.
3. Se lo stesso utente perde l’accesso alla fonte, l’app gestisce l’errore in sicurezza.

Condividere l’app in seguito non concede l’accesso ai dati sottostanti. Ogni destinatario deve comunque disporre delle autorizzazioni e della connessione corrette per la fonte. È una caratteristica del modello, non un fastidio legato al deployment.

4. Esegui commit e push del codice reale

Usa i normali comandi Git: la CLI del runtime non sostituisce il controllo versione. Il commit deve includere sia la modifica funzionante dell’applicazione sia i binding generati per i connettori che fanno parte del progetto.

La trappola da ricordare è semplice: git push non compila l’app. Aggiorna soltanto il codice sorgente remoto considerato ufficiale.

5. Apri l’anteprima ospitata e controlla la build

ms app play --mode preview apre l’endpoint stabile di anteprima. Se per l’ultimo commit inviato non esiste ancora una build, l’apertura dell’anteprima ne mette una in coda. Misura il tempo che passa dall’apertura dell’anteprima fino alla disponibilità della nuova versione.

Se la build non riesce, esegui ms app build-status, eventualmente con --commit <sha>, e salva il motivo completo accanto al commit. Quando una build più recente è ancora in corso o non è riuscita, l’anteprima continua a mostrare l’ultima build completata con successo. L’URL di anteprima è destinato agli sviluppatori con accesso in scrittura al repository, non a revisori generici.

Se vuoi avviare una build prima di aprire l’anteprima, puoi eseguire ms app build. Per la maggior parte dei team è meglio imparare prima il comportamento predefinito: inviare il codice, quindi aprire l’anteprima.

6. Distribuisci soltanto la versione verificata

ms app deploy promuove una build riuscita alla versione live dell’app. La versione live è uno snapshot fisso e non segue automaticamente ogni push o build di anteprima.

Per un rilascio controllato, registra lo SHA del commit, verifica lo stato della build, apri l’anteprima corrispondente e poi distribuisci quello SHA con ms app deploy --commit <sha>. La stessa opzione consente di tornare in modo pulito a una build precedente riuscita, senza riscrivere la cronologia Git.

I costi si spostano sul livello di piattaforma

Il runtime non rende gratuito il lavoro sull’applicazione. Cambia quali componenti il team deve acquistare o costruire separatamente.

Il budget software confrontabile è tutt’altro che trascurabile. La pagina ufficiale dei prezzi di Retool indica per il piano Team $10 al mese per ogni builder e $5 per ogni utente interno, mentre per il piano Business indica $50 per builder e $15 per utente interno. Copilot Managed Runtime non è automaticamente più conveniente. In un’organizzazione Microsoft 365 può eliminare parte del lavoro di piattaforma separato, ma licenze runtime, crediti, lavoro sui connettori e tempo degli amministratori restano costi reali.

Prima di concludere che il progetto pilota costa meno, usa questa formula:

Costo del progetto pilota = tempo degli sviluppatori + configurazione amministrativa + copertura runtime + lavoro su connettori e dati.

La voce che ha più probabilità di ridursi è l’assemblaggio della piattaforma. Quella che rischia maggiormente di sorprendere è la copertura runtime per ogni utente che apre l’app.

Sette app interne adatte a questo runtime

I casi migliori sono i flussi di lavoro interni in cui identità, dati Microsoft 365 governati e rilascio controllato contano più di una vetrina pubblica.

Ogni caso d’uso dovrebbe iniziare in sola lettura. Un’azione di scrittura, un endpoint esterno, un connettore di terze parti o un’app condivisa su larga scala cambiano il tipo di revisione necessario. I criteri predefiniti includono 18 connettori Microsoft proprietari, non l’intero catalogo, e bloccano alcune azioni aperte basate su HTTP, codice arbitrario, query arbitrarie e piattaforme arbitrarie persino nei connettori approvati.

Tre prodotti da costruire su questo runtime

Il prodotto con il potenziale maggiore è un centro di comando per l’onboarding in Microsoft 365. Unisce la domanda misurata più elevata a un flusso di lavoro che, per sua natura, attraversa identità, documenti, attività, posta e passaggi tra team.

1. Un centro di comando per l’onboarding in Microsoft 365

Costruisci un’unica app interna in cui HR e IT possano vedere il record approvato di una nuova assunzione, le attività ancora aperte, i link ai documenti e i relativi responsabili. I team HR operations e IT service pagherebbero per ridurre i passaggi dimenticati e semplificare la traccia di audit.

La domanda è visibile: “employee onboarding software” riceve circa 590 ricerche mensili negli Stati Uniti, con intento commerciale e un costo per clic di $156.35. La query più specifica “best employee onboarding software” riceve 90 ricerche al mese e, nei dati dei suggerimenti, ha mostrato una crescita tendenziale annua del 180%.

La versione vendibile più piccola serve un solo reparto, legge un unico elenco approvato di dipendenti, mostra una checklist di attività e collega ogni attività al suo responsabile. Le azioni dei connettori vanno aggiunte soltanto dopo che il percorso di lettura ha superato i test sui criteri e sulle autorizzazioni.

L’ostacolo è concreto. I dati HR sono sensibili, le autorizzazioni della fonte si prestano a equivoci e i fornitori affermati di software per l’onboarding coprono già flussi HR più ampi. Il prodotto può vincere soltanto quando la governance di Microsoft 365 e il funzionamento nativo nel tenant contano più di un lungo elenco di funzionalità generiche.

2. Una console governata per le approvazioni

Costruisci un’interfaccia di approvazione riutilizzabile per i team finance, procurement o operations che dispongono di uno stato decisionale chiaro, ma hanno il contesto di supporto sparso. Il cliente paga per riesaminare più rapidamente e per un processo di rilascio controllato, non per un altro generatore di moduli.

“Approval workflow software” riceve circa 320 ricerche mensili negli Stati Uniti, con intento commerciale, un costo per clic di $114.86 e, nei dati dei suggerimenti, una crescita tendenziale annua del 53%. Questa combinazione segnala un problema d’acquisto attuale e uno spazio per un’implementazione mirata in Microsoft 365.

L’MVP comprende un solo tipo di richiesta, un’unica fonte approvata, una schermata di revisione in sola lettura, la cronologia delle decisioni e una sola azione autorizzata dai criteri. Il modello decisionale deve restare deterministico: non nascondere le regole di approvazione in testo generato.

L’ostacolo sono i criteri sui connettori. Un connettore può essere consentito mentre una sua azione specifica rimane bloccata; inoltre, i criteri dati classici possono combinarsi con le Advanced Connector Policies e prevale il risultato più restrittivo.

3. Una valutazione per migrare le app al runtime gestito

Vendi una valutazione standardizzata che esamini un’app web interna generata dall’AI o sviluppata su misura e stabilisca se può passare a Copilot Managed Runtime. Il cliente ideale è un’organizzazione Microsoft 365 con un prototipo utile, ma nessuna intenzione di mantenere un altro stack autonomo per hosting e governance.

“Custom business app development” riceve circa 90 ricerche mensili negli Stati Uniti, con intento commerciale e un costo per clic di $84.03. Il volume è inferiore, ma la query è vicina all’acquisto di un servizio.

L’MVP cataloga repository dell’app, presupposti del runtime, endpoint esterni, codice per l’identità, fonti dati e azioni necessarie. Produce quindi una decisione di via libera, modifica o arresto e trasferisce una singola porzione in sola lettura in un ambiente di test.

L’ostacolo è la dipendenza dalla piattaforma. Il risultato è utile soltanto per tenant Microsoft 365 idonei; il comportamento dell’anteprima pubblica può cambiare e provider del codice sorgente non supportati o risorse esterne bloccate possono trasformare una migrazione apparentemente semplice in una ricostruzione.

Che cosa Copilot Managed Runtime non risolve

È un percorso promettente per le app interne governate, non una piattaforma universale per applicazioni.

• È una funzionalità in anteprima pubblica con documentazione preliminare. Comandi e criteri possono cambiare.
• Non abilita automaticamente la creazione via CLI. Anche quando il tenant può usare il runtime, questo percorso è disattivato per impostazione predefinita.
• Non rende tutti gli oltre 1,500 connettori fonti dati autorizzate. L’accesso dipende ancora dai criteri del tenant, dai criteri sulle azioni dei connettori, dai criteri dati classici e dalle autorizzazioni della fonte.
• Non trasforma un’app interna line-of-business in un prodotto pubblico rivolto ai clienti. L’anteprima è riservata agli sviluppatori con accesso in scrittura al repository, mentre l’accesso live viene condiviso intenzionalmente all’interno del modello governato.
• Non supporta ogni provider di repository. Le fonti esterne sono limitate a GitHub.com e GitHub Enterprise Cloud, e la modalità del repository non può essere modificata sul posto.
• Non elimina le licenze runtime. L’esecuzione locale e quella degli utenti richiedono Power Apps Premium oppure Managed Application Copilot Credits finanziati.
• Non offre agli amministratori una registrazione forense perfetta. La vista amministrativa copre inventario, utilizzo, stato, connettori, fonti dati e dipendenze; Microsoft specifica però che non è una vista completa delle destinazioni esatte, degli endpoint dinamici, delle azioni eseguite o delle autorizzazioni effettive di ogni utente sulle fonti.
• Non dimostra un deployment effettuato da questa redazione. L’assenza di Git Credential Manager, di una libreria Linux per l’archiviazione dei segreti e di un tenant idoneo ha fermato il test prima dell’accesso.

La decisione sensata riguarda un perimetro preciso: usalo quando l’app è interna, l’organizzazione lavora già in Microsoft 365 e il lavoro evitato su identità e governance giustifica l’adozione di una piattaforma in anteprima con i relativi controlli del tenant. Scegli un altro host quando serve un prodotto SaaS pubblico, un diverso provider del codice sorgente, il controllo dell’infrastruttura o un modello di rilascio che gli amministratori non possono autorizzare.

Domande frequenti

La prossima mossa, lunedì

Chiedi a un amministratore Power Platform di abilitare la creazione via CLI per un solo gruppo di test, verifica la regola di routing dell’ambiente associata al gruppo e fornisci copertura runtime a due utenti di test. Scegli un elenco SharePoint non sensibile e una sola operazione in lettura. Chiedi poi a uno sviluppatore di registrare nel log del progetto pilota quattro dati: versione della CLI, tempo fino alla prima pagina locale, tempo fino all’anteprima ospitata e SHA del commit distribuito. Interrompi il progetto pilota se identità Entra, autorizzazioni della fonte o criteri sui connettori si comportano diversamente da quanto documentato.

Se vuoi progettare e realizzare questo percorso governato per la tua azienda, parti da una valutazione dei sistemi AI in produzione.