Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Pipeline Azure DevOps per Power Platform: deployment affidabili con service principal, validazione e rollback (Doppiaggio IA)

Transcript

Pipeline Azure DevOps per Power Platform: deployment affidabili con service principal, validazione e rollback (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per 10 giorni di Microsoft 365, Copilot, intelligenza artificiale,
0:04
Speaker 2: Azure e le persone che stanno plasmando il futuro del
0:06
Speaker 2: lavoro e il lavoro. A gennaio torna M365Con e ci
0:10
Speaker 2: stiamo espandendo. Unisciti a noi per sessioni live, dimostrazioni pratiche
0:15
Speaker 2: e conoscenze pratiche da parte di MVP ed esperti del
0:17
Speaker 2: settore di tutto il mondo. Niente slide generiche, niente parole
0:20
Speaker 2: d'ordine infinite. Stiamo affrontando le vere sfide. Copilot Studio, agenti
0:24
Speaker 2: di intelligenza artificiale, Fabric, sicurezza, governance e automazione. Che tu
0:30
Speaker 2: sia un professionista IT, uno sviluppatore o un leader aziendale,
0:33
Speaker 2: ci sono sessioni pensate per te. Con 10 giorni interi
0:36
Speaker 2: puoi esplorare più tecnologie e connetterti con una community globale.
0:40
Speaker 2: Guarda la diretta e porta spunti pratici alla tua organizzazione.
0:45
Speaker 2: Cennaio 2027, 10 giorni, una community Microsoft. Le registrazioni sono
0:50
Speaker 2: aperte ora. Vai su m3665con. net e assicurati il tuo posto
0:55
Speaker 2: oggi stesso. Questo è m3665con. net. Iscriviti ora su m365com. net e
1:02
Speaker 2: ci vediamo dal vivo a gennaio.
1:05
Speaker 3: Mai avuto la sensazione che distribuire soluzioni Power Platform significhi
1:07
Speaker 3: fare un passo avanti e due indietro? Se sei stanco
1:10
Speaker 3: di vedere le modifiche apportate data verso interrompersi nel controllo
1:12
Speaker 3: qualità o di vedere le dipendenze compromettere le tue distribuzioni,
1:15
Speaker 3: questo video è proprio per te. Oggi analizzeremo componente per
1:18
Speaker 3: componente la pipeline di Azure DevOps in modo che le
1:20
Speaker 3: tue distribuzioni funzionino come una macchina ben oliata e non
1:22
Speaker 3: come un azzardo. Sei curioso di sapere come funziona davvero
1:26
Speaker 3: il rollback quando l'automazione diventa complicata? Scopriamo cosa non ti
1:28
Speaker 3: dicono mai i documenti. Distribuzioni manuali e pipeline automatizzate, qui
1:32
Speaker 3: che iniziano davvero i problemi. Se lavori con Power Platform
1:36
Speaker 3: probabilmente ti è capitato. Ore di modifica, un'app basata su
1:40
Speaker 3: un modello, perfezionamento di un flusso di Power Automate, ottimizzazione attenta,
1:44
Speaker 3: dei ruoli di sicurezza, l'intera checklist. Hai ricontrollato ogni campo,
1:48
Speaker 3: hai premuto esporta soluzioni, hai caricato il tuo file zip,
1:50
Speaker 3: hai incrociato le dita mentre il controllo qualità riceve una
1:52
Speaker 3: nuova build. Poi, proprio mentre tutti si preparano per una demo,
1:56
Speaker 3: per andare in onda, qualcosa non va, ehm. Una tabella
1:59
Speaker 3: non viene visualizzata, un flusso si attiva nell'ambiente sbagliato, o
2:02
Speaker 3: peggio ancora, l'importazione non riesce con uno di quei codici
2:05
Speaker 3: di errore criptici che indicano solo che qualcosa da qualche
2:07
Speaker 3: parte non corrisponde, non corrisponde. La stanza diventa implusenziosa. Quel
2:12
Speaker 3: familiare nodo allo stomaco si insinua e si torna a
2:14
Speaker 3: cercare di capire cosa non è andato a buon fine,
2:16
Speaker 3: dove e perché. Questa è la realtà quotidiana dei team
2:19
Speaker 3: che si affidano alle distribuzioni manuali in Power Platform. Devi
2:22
Speaker 3: destreggiarti tra esportazioni di soluzioni sul desktop, sposti file zip
2:25
Speaker 3: tra ambienti e a volte utilizzi un vecchio foglio Excel
2:28
Speaker 3: o una chat di Teams per registrare cosa è stato
2:29
Speaker 3: spostato e quando... Se ti perdi una personalizzazione, magari una
2:34
Speaker 3: nuova tabella o un riferimento di connessione per un flusso,
2:36
Speaker 3: la tua distribuzione è a metà ma completamente interrotta.
2:39
Speaker 2: Il
2:39
Speaker 3: classico funziona in fase di sviluppo ma il controllo qualità
2:41
Speaker 3: non ha idea di cosa è appena inviato. Ora tutti
2:43
Speaker 3: sono su Slack o Teams e cercano di capire cosa
2:46
Speaker 3: manca o chi ha esportato per ultimo la versione reale dell'app.
2:49
Speaker 3: Le distribuzioni manuali sono più subdole nella loro fragilità di
2:51
Speaker 3: quanto si aspettino i tipi. Non si tratta solo di
2:53
Speaker 3: passaggi mancati. Ha a che fare con ambienti che si disanninano, silenziosamente.
2:58
Speaker 3: Nel corso di settimane di modifiche. Lo sviluppatore ottiene un
3:01
Speaker 3: nuovo connettore o un'autorizzazione, ma nessuno lo registra per la
3:03
Speaker 3: distribuzione successiva. Forse qualcuno modifica i dettagli di attivazione di
3:06
Speaker 3: un flusso, ma solo nello sviluppo. Quando sei in produzione
3:09
Speaker 3: c'è un mosaico di deviazioni di configurazione. Anche se provi
3:12
Speaker 3: a documentare tutto, l'errore umano trova sempre un modo... Una
3:16
Speaker 3: modifica a tarda notte dopo un'interruzione, un ruolo di sicurezza
3:18
Speaker 3: trascurato o una variabile di ambiente migrata manualmente, all'improvviso ti
3:21
Speaker 3: ritrovi a inseguire un problema che non era ovvio due
3:24
Speaker 3: giorni fa ma che ora sta bloccando l'adozione da parte
3:26
Speaker 3: degli utenti o sta danneggiando i dati in un'integrazione critica.
3:30
Speaker 3: Ecco una storia che probabilmente ti suona familiare. Un flusso
3:33
Speaker 3: Power Automate critico per l'azienda stava procedendo senza intoppi nello
3:36
Speaker 3: sviluppo spostando righe tra tabelle e dataverse utilizzando alcuni nuovi
3:39
Speaker 3: riferimenti di connessione. L'esportazione in Kuai l'importazione sembra corretta ma
3:43
Speaker 3: non si attiva nulla. Dopo ore di analisi dei registri
3:46
Speaker 3: e ricontrollo delle autorizzazioni, qualcuno si rende conto che l'ambiente
3:49
Speaker 3: QA non ha mai avuto il riferimento di connessione corretto.
3:52
Speaker 3: Non ci sono avvisi in interfaccia utente e niente è
3:54
Speaker 3: stato segnalato nella fase di importazione. È stato necessario analizzare
3:57
Speaker 3: a fondo i livelli della soluzione e le dipendenze dei
3:59
Speaker 3: componenti e nel frattempo l'azienda ha avuto un processo interrotto
4:02
Speaker 3: per gran parte della settimana. Microsoft sottolinea apertamente questo punto
4:06
Speaker 3: dolente nella propria documentazione, il che è quasi rassicurante, il
4:08
Speaker 3: che è quasi rassicurante. Anche gli amministratori esperti e persone
4:11
Speaker 3: che vivono e respirano Dataverse perdono di vista le dipendenze
4:14
Speaker 3: nascoste o le sottili differenze ambientali. Ciò che a malapena
4:18
Speaker 3: viene menzionato nella documentazione è spesso la causa esatta del
4:20
Speaker 3: fallimento di un'implementazione. Questi non sono errori da principianti. Sono
4:24
Speaker 3: le conseguenze di una piattaforma flessibile ma silenziosamente piena di
4:27
Speaker 3: collegamenti incrociati e dipendenze. Quando ti affidi alle persone per
4:30
Speaker 3: ricordare ogni impostazione è solo questione di tempo prima che
4:33
Speaker 3: qualcosa scivoli. Quindi la grande sfida è l'automazione. Azure DevOps
4:37
Speaker 3: si colloca al limite di questo problema promettendo di trasformare
4:40
Speaker 3: quei passaggi manuali soggetti a errori in pipeline ripetibili tracciabili
4:44
Speaker 3: e si spera a prova di proiettile l'idea sembra buona
4:48
Speaker 3: sulla carta cabli una pipeline l'alimenti con power platform e
4:51
Speaker 3: lasci che si occupi del lavoro pesante la soluzione viene
4:54
Speaker 3: esportata importata le dipendenze vengono controllate e se qualcosa non
4:58
Speaker 3: va lo rilevi subito ottieni registri con timestamp reali non
5:02
Speaker 3: dovrei più chiederti se alice o bob hanno la copia
5:04
Speaker 3: più recente se eseguita correttamente ogni distribuzione è sottoposta controllo
5:07
Speaker 3: di versione tracciabile fino alla Niente più dipendenze in continuazione
5:10
Speaker 3: a sorpresa dell'ultimo minuto. Ed ecco il numero che tutti
5:13
Speaker 3: amano condividere nelle presentazioni. I team che passano dai processi
5:16
Speaker 3: manuali alle pipeline automatizzate vedono cicli di feedback che non
5:19
Speaker 3: solo sono più rapidi ma in realtà chiudono la porta
5:21
Speaker 3: alla maggior parte delle distribuzioni non riuscite. Certo gli errori
5:24
Speaker 3: si verificano ancora ma vengono individuati in anticipo e non
5:27
Speaker 3: devi passare ore a districare cosa è andato storto. Ancora
5:29
Speaker 3: più importante ottiene la verificabilità. Puoi tracciare ogni distribuzione, sapere
5:33
Speaker 3: esattamente chi ha spedito cosa e si individuare dove come
5:36
Speaker 3: qualcosa non ha funzionato. Ma la realtà è che si
5:38
Speaker 3: tratta di fiducia, non solo di velocità. Se il tuo
5:41
Speaker 3: team non si fida del processo di distribuzione, se ogni
5:43
Speaker 3: release sembra un lancio di dadi, ogni buona funzionalità che
5:46
Speaker 3: crea è a rischio. Le parti interessate esitano a rilasciare.
5:49
Speaker 3: Gli utenti si innervosiscono per interruzioni o le funzionalità mancate.
5:51
Speaker 3: La promessa di una rapida innovazione low- code cade nel vuoto
5:54
Speaker 3: quando l'ultimo miglio rimane inaffidabile. L'automazione non serve solo a
5:59
Speaker 3: risparmiare tempo o a impressionare la dirigenza passando a DevOps.
6:03
Speaker 3: È l'unico modo realistico per distribuire soluzioni Power Platform che
6:06
Speaker 3: funzionino sempre allo stesso modo in ogni ambiente. Quindi con
6:10
Speaker 3: le pipeline automatizzate ottieni prevedibilità. Ottieni un registro affidabile di
6:14
Speaker 3: ogni dipendenza di distribuzione e passaggio eseguito. Diventa possibile un
6:18
Speaker 3: vero CSD per Power Platform e la risoluzione dei problemi
6:21
Speaker 3: diventa una questione di registri, non di supposizioni. Naturalmente niente
6:25
Speaker 3: di tutto ciò avviene per magia. L'automazione è forte solo
6:28
Speaker 3: quanto i collegamenti tra la tua pipeline e i tuoi ambienti.
6:31
Speaker 3: È lì che le cose possono ancora andare storte. Quindi
6:35
Speaker 3: ora parliamo di come collegare Azure DevOps a Power Platform
6:38
Speaker 3: in modo stabile, sicuro e che non si interrompa alle
6:41
Speaker 3: 3 del mattino. Il collante, le connessioni servizio e pool
6:45
Speaker 3: di agenti che non si interrompono. Se hai provato a
6:48
Speaker 3: connettere Azure DevOps a Power Platform e hai visto la
6:51
Speaker 3: pipeline generare immediatamente un errore di autorizzazione o bloccarsi per
6:55
Speaker 3: quella che sembra un'eternità, sei in buona compagnia. Quasi tutti
6:59
Speaker 3: i team prima o poi si imbattono in questo ostacolo.
7:01
Speaker 3: Potrebbe essere progettata in modo impeccabile. Il tuo YAN potrebbe
7:04
Speaker 3: essere impeccabile, ma basta una connessione di servizio configurata in
7:07
Speaker 3: modo errato o un'impostazione di agente mancante e ti ritrovi
7:10
Speaker 3: a dover affrontare errori di autenticazione o a chiederti perché
7:12
Speaker 3: non si abbia mai nulla. La realtà è che le
7:15
Speaker 3: distribuzioni di Power Platform vivono o muoiono in base a
7:17
Speaker 3: ciò che accade dietro le quinte, ciò che mi piace
7:19
Speaker 3: definire l'impianto idraulico invisibile. Stiamo parlando di connessioni di servizio,
7:23
Speaker 3: flussi di autenticazione, pool di agenti e quelle piccole impostazioni
7:25
Speaker 3: che tengono tutto insieme silenziosamente o che ti rovinano la giornata.
7:29
Speaker 3: Siamo onesti, il concetto sembra ingannevolmente semplice. crei una connessione
7:34
Speaker 3: di servizi in Azure DevOps, le fornisci alcune credenziali, le
7:37
Speaker 3: indirizzi al tuo ambiente e torni a creare i tuoi flussi.
7:41
Speaker 3: In realtà però è una rete di autorizzazioni, token, handshake, API.
7:46
Speaker 3: Se ne tralasci uno, potresti interrompere non solo la tua pipeline,
7:48
Speaker 3: ma potenzialmente anche l'integrazione sottostante per tutti gli altri che
7:51
Speaker 3: utilizzano lo stesso servizio principale. Questa non è solo teoria.
7:55
Speaker 3: Ho visto team che lavoravano perfettamente per mesi solo per
7:57
Speaker 3: poi imbattersi in una singola distribuzione che si rifiutava di
7:59
Speaker 3: andare a buon fine. Tutto si riduce sempre a qualche
8:02
Speaker 3: dettaglio nascosto, un segreto scaduto, un ruolo mancante nell'account di
8:06
Speaker 3: servizio o un ambito di autorizzazione modificato in Azure Active Directory.
8:11
Speaker 3: Nel peggiore dei casi potresti bloccare accidentalmente te stesso o
8:13
Speaker 3: il tuo team fuori dagli ambienti se diventi troppo aggressivo
8:16
Speaker 3: con le assegnazioni di ruolo. Immagina la configurazione. Ottieni finalmente
8:19
Speaker 3: l'approvazione per utilizzare un servizio principale per la tua pipeline
8:23
Speaker 3: puntando a una vera sicurezza alla separazione dei compiti. La
8:26
Speaker 3: teoria ha senso. Hai un'identità per ambiente e tutto dovrebbe funzionare.
8:30
Speaker 3: Ma poi arriva il giorno della distribuzione. Esegui la tua
8:32
Speaker 3: pipeline e non riesci al primo passaggio di autenticazione. I
8:35
Speaker 3: messaggi di errore sono scuri. Esamini i registri solo per
8:38
Speaker 3: scoprire che hai perso una piccola assegnazione di ruolo Dataverse.
8:42
Speaker 3: Una casera di controllo e ora il tuo agente non
8:44
Speaker 3: può accedere all'ambiente. Naturalmente i registri non lo segnalano. Ti
8:47
Speaker 3: hanno appena risposto con un messaggio generico di mancata autorizzazione
8:50
Speaker 3: e quindi ti ritrovi a curiosare nel portale di Azure
8:52
Speaker 3: D23 a cambiare le autorizzazioni e a sperare di non
8:54
Speaker 3: rompere qualcos'altro nel processo. È frustrante e del tutto evitabile
8:59
Speaker 3: allo stesso tempo. C'è uno schema qui. Un'autorizzazione mancata o
9:03
Speaker 3: una configurazione non standard possono bloccare l'intero spettacolo. Ecco perché
9:07
Speaker 3: la prassi consigliata è quella di usare un'entità a servizio dedicata.
9:10
Speaker 3: Ed ecco il trucco. Non limitarti ad assegnare i diritti
9:13
Speaker 3: di amministratore ovunque per comodità. Assegna solo i ruoli Dataverse
9:17
Speaker 3: minimi necessari per il suo ambiente e le sue attività specifici.
9:21
Speaker 3: Potrebbe sembrare eccessivo se sei le prime armi con DevOps,
9:23
Speaker 3: ma nel mondo reale questo ti salva dal rischio che
9:25
Speaker 3: qualcuno elimini o danneggi accidentalmente i dati perché un'entità a
9:28
Speaker 3: servizio onnipotente è accesso ovunque. Significa anche che cambiare le
9:32
Speaker 3: chiavi o i segreti è più pulito. Se devi revocare
9:35
Speaker 3: una connessione dal controllo qualità non rischi di far saltare
9:37
Speaker 3: la produzione. I team che rispettano questa separazione raramente hanno
9:42
Speaker 3: tutti gli ambienti in panne. Ora parliamo dei pool di
9:45
Speaker 3: agenti perché stranamente vengono solitamente trattati come ripensamento. Hai due
9:51
Speaker 3: opzioni principali, agenti ospitati da Microsoft e agenti self- hosted. La
9:55
Speaker 3: maggior parte delle persone sceglie ciò che è predefinito nel
9:58
Speaker 3: proprio progetto Azure DevOps e spera che funzioni. Per i processi.
10:03
Speaker 3: NET o web di base di solito funziona, ma con
10:06
Speaker 3: Power Platform alla fine ti imbatterai in un ostacolo. Gli
10:09
Speaker 3: agenti ospitati da Microsoft sono ottimi per le attività di
10:11
Speaker 3: compilazione di base, ma poiché vengono sottoposti a provisioning e
10:13
Speaker 3: condivisi in modo dinamico non puoi garantire che tutti i
10:15
Speaker 3: propri visiti siano presenti. come versioni specifiche di strumenti di
10:19
Speaker 3: compilazione di Power Platform o moduli PowerShell personalizzati necessari per
10:22
Speaker 3: attività di soluzione più complesse. Inoltre, se hai bisogno di
10:25
Speaker 3: software personalizzato o integrazione, qualsiasi cosa non sia nell'immagine standard,
10:29
Speaker 3: sei bloccato. E buona fortuna nella risoluzione dei problemi di
10:32
Speaker 3: errori isolati in ambienti di cui non sei proprietario. Gli
10:34
Speaker 3: agenti self- hosted ti danno il pieno controllo sull'ambiente, il che
10:36
Speaker 3: è una benedizione e una maledizione. Da un lato, poi,
10:40
Speaker 3: per installare strumenti di compilazione, SDK, script, qualsiasi cosa richieda
10:45
Speaker 3: il tuo progetto. Se disponi di connettori univoci o di
10:48
Speaker 3: un set stabile di dipendenze, ciò può farti risparmiare un
10:50
Speaker 3: sacco di tempo. D'altro canto, sei completamente responsabile degli aggiornamenti
10:54
Speaker 3: delle macchine, dell'applicazione di batch e del mantenimento, in funzione
10:56
Speaker 3: della gente. Tuttavia, molti team preferiscono questa strada, soprattutto se
11:00
Speaker 3: il loro lavoro su Power Platform include molti passaggi di
11:02
Speaker 3: build personalizzati o integrazioni che non funzionano bene con le
11:05
Speaker 3: immagini Microsoft condivise. Un suggerimento che mi hanno trascurato è
11:08
Speaker 3: quello di eseguire sempre una prova generale. Testa la connessione
11:10
Speaker 3: del servizio ed esegui un'esportazione di prova prima di inserire
11:13
Speaker 3: elementi importanti nella pipeline. Solo perché la pipeline indica connesso
11:16
Speaker 3: non significa che abbia il giusto livello di accesso per
11:18
Speaker 3: ogni operazione che desideri eseguire. Quell'esportazione di prova è la
11:22
Speaker 3: tua rete di sicurezza. Rileverai lacune nelle autorizzazioni, problemi di
11:25
Speaker 3: ruolo e persino stranezze di rete di base prima di
11:27
Speaker 3: essere immerso fino al collo in una distribuzione di tutto.
11:29
Speaker 3: È meglio scoprirlo ora che quando sarà in corsa contro
11:31
Speaker 3: le finestre di GoLive. Quindi ciò che desideri davvero è
11:33
Speaker 3: affidabilità senza sorpresa. Le connessioni di servizio durevoli e i
11:37
Speaker 3: pool di agenti sono la base per tutto ciò che
11:38
Speaker 3: verrà dopo. Se sbagli, non importa quanto sia raffinato il
11:42
Speaker 3: tuo YAML o quanto siano sofisticate le tue attività di pipeline,
11:45
Speaker 3: falliranno perché le basi non sono cablate correttamente. Una volta
11:49
Speaker 3: che hai definito questo sistema idraulico invisibile, il resto del
11:51
Speaker 3: processo della pipeline si sistema con molta meno drammaticità e
11:55
Speaker 3: molta più prevedibilità. I grattacapi passano dal perché la mia
11:58
Speaker 3: pipeline non è mai partita come posso renderla ancora più intelligente,
12:01
Speaker 3: che è un problema molto più divertente da risolvere. Con
12:04
Speaker 3: quelle connessioni stabili e i tuoi agenti che funzionano in
12:06
Speaker 3: modo affidabile hai appena superato il primo vero ostacolo. Tuttavia,
12:09
Speaker 3: un sistema idraulico solido non garantisce di individuare i problemi
12:12
Speaker 3: di soluzione prima che raggiungano la produzione. Ora, immergiamoci in
12:14
Speaker 3: come i controlli e le convalide automatizzati proteggono i tuoi
12:17
Speaker 3: ambienti da errori silenziosi prima che si diffondano. Guardrail automatizzati,
12:21
Speaker 3: controlli delle dipendenze, convalide e predistribuzione. Se hai mai visto
12:25
Speaker 3: una distribuzione di pop- up platform passare in fase di sviluppo,
12:27
Speaker 3: seguire i movimenti in fase di controllo qualità e quindi
12:30
Speaker 3: far scattare gli allarmi nel momento in cui arriva in produzione,
12:33
Speaker 3: sai dove vogliamo arrivare. I problemi non si annunciano quasi
12:36
Speaker 3: mai in anticipo. Al contrario, si verificano dipendenze nascoste in silenzio,
12:41
Speaker 3: del tipo che si trovano a due o tre clic
12:42
Speaker 3: di profondità in un'app canvas o sepolte all'interno dei sottoflussi
12:45
Speaker 3: di un'app basata su un modello. Per quanto riguarda lo sviluppo,
12:48
Speaker 3: tutto sembra a posto, ma la produzione con i suoi connettori,
12:51
Speaker 3: diversi utenti con licenza o una sottile differenza nei ruoli
12:54
Speaker 3: di sicurezza di Dataverse trova immediatamente l'anello debole. A volte
12:59
Speaker 3: l'unico avviso che si riceve è un utente che dice« Ehi,
13:01
Speaker 3: questi dati non si aggiornano», un ticket di supporto con
13:03
Speaker 3: una traccia dello stack che non offre nulla di utile.
13:06
Speaker 3: Problema di fondo? Nessuno ha verificato se tutti i pezzi
13:08
Speaker 3: in movimento sono effettivamente sopravvissuti allo spostamento. Ecco perché i
13:11
Speaker 3: controlli delle dipendenze, le convalide predistribuzioni non sono solo utili.
13:15
Speaker 3: Sono il sistema immunitario della pipeline. Pensa a loro come
13:18
Speaker 3: a un sistema che viaggia prima della distribuzione e illumina
13:20
Speaker 3: tutti gli angoli in cui i problemi amano nascondersi. Questi
13:24
Speaker 3: guardrail automatizzati rilevano elementi come flussi figlio mancanti, riferimenti di
13:27
Speaker 3: connessione assenti o componenti non gestiti che non sono mai
13:30
Speaker 3: stati aggiunti all'esportazione. Senza questi controlli ogni distribuzione è un
13:34
Speaker 3: atto di fede. Speri solo che l'impianto idraulico sottostante alla
13:37
Speaker 3: tua app abbia lo stesso aspetto in ogni ambiente e
13:39
Speaker 3: scopri che non è così solo quando il rapporto sull'incidente
13:41
Speaker 3: arriva nella tua casella di posto. Ho visto questa situazione
13:43
Speaker 3: ripetersi più volte di quanto vogliono. Un progetto aveva un
13:46
Speaker 3: incubo ricorrente, un flusso di Power Automate che funzionava benissimo
13:49
Speaker 3: in ogni test di sviluppo per poi scomparire completamente dalla
13:52
Speaker 3: distribuzione di produzione. Cosa è successo? Si è scoperto che
13:55
Speaker 3: una soluzione rapida aveva un flusso figlio come dipendenza e
13:58
Speaker 3: il processo di esportazione non rilevava che il flusso figlio
14:00
Speaker 3: era esterno alla soluzione gestita. Quando quel flusso figlio non
14:03
Speaker 3: veniva visualizzato nel controllo qualità e nella produzione, la logica
14:06
Speaker 3: padre semplicemente non funzionava. Nessun errore, nessun avviso, solo un
14:10
Speaker 3: processo che si disattivava silenziosamente e gli utenti erano confusi
14:12
Speaker 3: sul motivo per cui le loro attività si erano improvvisamente bloccate.
14:15
Speaker 3: Ci siamo resi conto solo dopo che un numero sufficiente
14:17
Speaker 3: di utenti aveva segnalato aggiornamenti mancanti, che qualcuno aveva finalmente
14:20
Speaker 3: trovato il collegamento mancato. A quel punto erano passate ore
14:22
Speaker 3: a esaminare i file XML di esportazione e ad eseguire
14:25
Speaker 3: controlli manuali. Una dipendenza trascurata aveva causato il caos che
14:28
Speaker 3: avrebbe potuto essere segnalato con la giusta protezione in atto.
14:32
Speaker 3: Il vero problema è quanto sia ormai prevenibile. Strumenti come
14:35
Speaker 3: Solution Checker in Power Platform consentono di impostare scansioni automatizzate
14:38
Speaker 3: come passaggio della pipeline, fornendo avvisi in anticipo su problemi
14:41
Speaker 3: con la stratificazione della soluzione, dipendenze mancanti, prestazioni delle app
14:46
Speaker 3: e persino consigli sulla sicurezza. Gli strumenti di compilazione di
14:50
Speaker 3: Power Platform per Azure DevOps avvicinano ulteriormente questo aspetto alla
14:54
Speaker 3: realtà CISD. Con il passaggio della pipeline giusto si fa
14:57
Speaker 3: molto di più di una semplice importazione e esportazione. Si
15:00
Speaker 3: eseguono controlli di convalida sia sulla soluzione che sulle relative
15:02
Speaker 3: connessioni all'ambiente di destinazione. Se si hanno requisiti aggiuntivi, gli
15:07
Speaker 3: script PowerShell personalizzati consentono di andare ancora più a fondo
15:10
Speaker 3: eseguendo la scansione di elementi come le variabili di ambiente richieste,
15:13
Speaker 3: convalidando le connessioni per le IP Premium o verificando gli
15:16
Speaker 3: ambiti di autorizzazione nei flussi integrati in AD. Ciò che
15:21
Speaker 3: è interessante è quanto queste protezioni automatizzate siano in grado
15:23
Speaker 3: di rilevare rispetto ai vecchi metodi di esportazione Speranza. Studi
15:26
Speaker 3: della community affermano che questi controlli segnalano fino al 70%
15:29
Speaker 3: dei problemi prima che qualcosa venga pubblicato. Ciò significa meno
15:33
Speaker 3: chiamate fuori orario, meno sprint di recupero per risolvere i problemi,
15:36
Speaker 3: e molte meno. Riunioni imbarazzanti per spiegare alla dirigenza perché
15:40
Speaker 3: un go live è diventato un fallimento. Le ricerche e
15:44
Speaker 3: i casi di studio di Microsoft lo confermano. I team
15:47
Speaker 3: che eseguono la convalida predistribuzione di norma registrano un calo
15:49
Speaker 3: drastico delle interruzioni di produzione. I problemi vengono individuati così
15:52
Speaker 3: presto che vengono malapena registrati come incidenti. Un passaggio solido
15:55
Speaker 3: della pipeline per questo è semplice ma efficace. Esporta la
15:58
Speaker 3: tua soluzione dalla fonte, ma prima ancora di prendere in
16:00
Speaker 3: considerazione l'importazione e l'ambiente di destinazione, avvia una sequenza che
16:04
Speaker 3: esegue il controllo della soluzione e tutti i test personalizzati
16:06
Speaker 3: che hai aggiunto. Non fermarti solo alla build. Esegui query
16:10
Speaker 3: sul dataverse di produzione per assicurarti che le entità che
16:12
Speaker 3: stai per sostituire non abbiano differenze di schema che causerebbero
16:15
Speaker 3: un errore silenzioso con valide riferimenti di connessione. Non dare
16:19
Speaker 3: per scontato che tutti coloro che avevano autorizzazione in DEV
16:21
Speaker 3: o QA avranno lo stesso ruolo in PROD Avere questi
16:24
Speaker 3: passaggi nella pipeline significa che lo script fallisce in anticipo
16:26
Speaker 3: se manca qualcosa e ottieni registri utili che ti indicano
16:29
Speaker 3: esattamente dove si trova la lacuna. Questi controlli automatizzati fanno
16:32
Speaker 3: la differenza tra trascorrere la giornata e creare funzionalità utili
16:35
Speaker 3: e passare la serata a risolvere problemi di distribuzione non funzionanti.
16:39
Speaker 3: Non si limitano a mantenere stabile l'ambiente ma danno all'intero
16:42
Speaker 3: team la certezza che le modifiche in corso nella pipeline
16:44
Speaker 3: non abbiano saltato alcun passaggio cruciale o perso una dipendenza
16:47
Speaker 3: dell'ultimo minuto. Trasformano la giornata di distribuzione da un momento
16:51
Speaker 3: di tensione a una routine Quando qualcuno chiede la distribuzione
16:54
Speaker 3: è terminata? Puoi rispondere con più di quanto pensi perché
16:58
Speaker 3: hai le protezioni per dimostrarlo? È facile liquidare i controlli
17:02
Speaker 3: per la distribuzione come un'altra casella da spuntare, ma nel
17:04
Speaker 3: mondo di Power Platform fanno risparmiare più tempo e fatica
17:08
Speaker 3: di quasi qualsiasi altra automazione di... Invece di procedere a
17:12
Speaker 3: ritroso partendo da interruzioni e reclami, ricevi avvisi sentinella proattivi, tempestivi,
17:17
Speaker 3: fruibili e collegati direttamente ai componenti? Considerali meno come una
17:21
Speaker 3: rete di sicurezza e più come un sistema radar. Naturalmente
17:24
Speaker 3: anche con le migliori protezioni le cose possono comunque andare storte,
17:27
Speaker 3: niente a prova di proiettile ogni team ha bisogno di
17:29
Speaker 3: un modo per annullare le modifiche quando qualcosa sfugge. Vediamo
17:33
Speaker 3: quindi come funziona un vero e proprio piano di rollback
17:35
Speaker 3: e backup per Power Platform oltre alla semplice speranza che
17:38
Speaker 3: il pulsante annulla funzioni. Quando le cose si rompono è
17:42
Speaker 3: necessario creare una vera strategia di rollback e backup. Parliamo
17:46
Speaker 3: di cosa significa realmente il rollback per Power Platform, perché
17:49
Speaker 3: è facile supporre che ci sia un grande pulsante a
17:51
Speaker 3: nulla pronto a salvarti quando una distribuzione si blocca. Tuttavia,
17:55
Speaker 3: a differenza dei progetti di codice in cui un rollback
17:57
Speaker 3: è solo un ripristino di git o una ridistribuzione di
17:59
Speaker 3: un pacchetto, il mondo di Power Platform è molto meno indulgente.
18:02
Speaker 3: Non esistono di ripristino della distribuzione nativa. Una volta eseguita un'importazione,
18:07
Speaker 3: le modifiche vengono integrate nell'ambiente, le tabelle potrebbero essere aggiornate,
18:10
Speaker 3: i componenti potrebbero cambiare versione, le relazioni tra i dati
18:13
Speaker 3: potrebbero essere organizzate in modo silenzioso. Se qualcosa non va
18:16
Speaker 3: a metà dell'importazione, il risultato potrebbe essere la distribuzione di
18:19
Speaker 3: metà soluzione, integrazioni interrotte e utenti bloccati dall'accesso alle app
18:23
Speaker 3: su cui fanno affidamento. La posta in gioco è raramente
18:25
Speaker 3: ovvia finché non si verifica e a quel punto la
18:27
Speaker 3: correzione richiede finezza. La dura verità è che un'importazione mai
18:30
Speaker 3: riuscita lascia l'ambiente in una sorta di limbo. Alcuni componenti
18:34
Speaker 3: potrebbero essere aggiornati, altri potrebbero restare alla vecchia versione e
18:38
Speaker 3: le connessioni o i ruoli potrebbero trovarsi in uno stato indefinito.
18:41
Speaker 3: Le configurazioni perdono rapidamente la sincronizzazione e il sistema non
18:44
Speaker 3: corrisponde esattamente alle intenzioni di tutti. Ciò che sembra una
18:48
Speaker 3: piccola modifica in una soluzione gestita può compromettere interi processi
18:51
Speaker 3: aziendali a valle. Sia la maggior parte degli amministratori seriali
18:54
Speaker 3: si ha la sensazione di poter semplicemente eseguire di nuovo
18:57
Speaker 3: la modifica o annullare un passaggio quando in pratica si
19:00
Speaker 3: ha a che fare con un'applicazione attiva su cui gli
19:01
Speaker 3: utenti contano per svolgere il proprio lavoro. Ora immagina posta
19:05
Speaker 3: in gioco con un esempio reale. Una grande società finanziaria
19:08
Speaker 3: aveva in coda una nuova funzionalità per il proprio portale PowerApps.
19:11
Speaker 3: Alcune modifiche. Al flusso di lavoro, un paio di nuovi
19:14
Speaker 3: dashboard e una tabella, dati e riconfigurata. La modifica è
19:18
Speaker 3: stata superata rapidamente dal controllo qualità, quindi hanno dato il
19:20
Speaker 3: via libera all'importazione in produzione la tarda serata di venerdì,
19:22
Speaker 3: sperando la tarda serata di venerdì, sperando di sistemare le
19:24
Speaker 3: cose per la discadenza della segnalazione di lunedì. L'importazione ha
19:26
Speaker 3: generato un errore a metà. Il risultato finale è che
19:28
Speaker 3: gli utenti che hanno effettuato l'accesso lunedì mattina hanno trovato
19:31
Speaker 3: dashboard non funzionanti, automazioni non riuscite e una manciata di
19:33
Speaker 3: app canvas che non si caricavano. A peggiorare le cose,
19:36
Speaker 3: l'ultimo backup completo dell'ambiente era vecchio di settimane e non
19:39
Speaker 3: avevano esportato l'ultima versione della soluzione dopo le modifiche dell'ultimo
19:42
Speaker 3: minuto portate dallo sviluppatore. Le opzioni di ripristino erano limitate
19:46
Speaker 3: l'azienda ha perso un'intera giornata di lavoro mentre gli amministratori
19:49
Speaker 3: rimettevano insieme l'ambiente nessun singolo passaggio ha causato il disastro
19:53
Speaker 3: è stata una finestra di backup mancata la convinzione di
19:55
Speaker 3: soluzioni rapide e la mancanza di una pianificazione flessibile del
19:57
Speaker 3: rollback che li ha esposti quindi cosa puoi fare effettivamente
20:01
Speaker 3: per evitare di finire nel limbo del rollback il primo
20:04
Speaker 3: più affidabile livello è automatizzare le esportazioni della soluzione in
20:08
Speaker 3: ogni fase Invece di affidarti all'ultima versione in una cartella
20:11
Speaker 3: di sviluppo, la tua pipeline dovrebbe esportare automaticamente la soluzione
20:14
Speaker 3: in una posizione sicura, idealmente nel controllo del codice sorgente.
20:18
Speaker 3: In questo modo ogni versione è riuscita o non riuscita
20:20
Speaker 3: a un backup corrispondente. Se la distribuzione odierna non va
20:24
Speaker 3: a buon fine, non rimani bloccato con ciò che si
20:25
Speaker 3: trova sul tuo desktop. Hai sempre accesso all'ultimo pacchetto valido
20:29
Speaker 3: o noto. I backup noturni dell'ambiente sono un'altra mossa pratica,
20:33
Speaker 3: anche se pensi di non averne mai bisogno. Microsoft offre
20:36
Speaker 3: funzionalità di backup complete dell'ambiente, in particolare per gli ambienti Dataverse,
20:39
Speaker 3: ma rimarrai sorpreso da quanti team non automatizzano effettivamente l'utilizzo.
20:43
Speaker 3: Le linee video ufficiali sono chiare e esegui sempre un
20:45
Speaker 3: backup completo dell'ambiente prima di passare alla produzione. Tuttavia, sul campo,
20:49
Speaker 3: molti team si affidano al principio e lo faremo se
20:51
Speaker 3: ce ne ricordiamo. Funziona più o meno come ci si
20:54
Speaker 3: aspetterebbe finché non lo fa più. Configurare backup notturni o
20:57
Speaker 3: predistribuzione significa disporre di uno snapshot completo da cui eseguire
20:59
Speaker 3: ripristino in caso di problemi. Se abbinate le esportazioni a
21:02
Speaker 3: livello di soluzione, puoi decidere se ripristinare un intero ambiente
21:05
Speaker 3: o semplicemente eseguire il rollback di una singola soluzione seconda
21:09
Speaker 3: dell'entità del problema. I file di soluzione delle versioni del
21:12
Speaker 3: controllo del codice sorgente possono sembrare basilari, ma sono un
21:14
Speaker 3: vero toccato. Il monitoraggio di ogni file zip esportato con
21:17
Speaker 3: cronologia di commit, denominazione dei rami e richieste pool avvicina
21:20
Speaker 3: le distribuzioni di power platform e cicli di vita delle
21:22
Speaker 3: applicazioni classiche. Ottieni un audit trail completo di cosa è
21:25
Speaker 3: cambiato quando è da kit. Se diventa necessario un rollback,
21:28
Speaker 3: non è necessario organizzarsi. Basta ridistribuire la build precedente riuscita.
21:32
Speaker 3: Non è solo comodo. È un utipo affidabile per ripristinare
21:35
Speaker 3: modifiche aziendali critiche senza conseguenze collaterali. Senza collaterali. Quando è
21:39
Speaker 3: il momento di eseguire un vero rollback, i file di
21:41
Speaker 3: soluzioni esportati sono la tua ancora di salvezza. Sono lezze.
21:45
Speaker 3: Inizia ripristinando la versione precedente della soluzione che è già
21:48
Speaker 3: convalidato in un ambiente inferiore. Il rollback a quello stato
21:51
Speaker 3: noto e funzionante rimposterà i tuoi componenti, i flussi e
21:53
Speaker 3: le personalizzazioni correlate. Non otterrai una macchina del tempo perfetto.
21:57
Speaker 3: I record o i dati transazionali modificati dall'ultima distribuzione potrebbero
22:00
Speaker 3: essere ancora a rischio, ma puoi riportare l'app a una
22:02
Speaker 3: configurazione funzionante, spesso entro un'ora. Per problemi più gravi, come
22:07
Speaker 3: un'entità danneggiata, relazioni perse o problemi di integrazione dei dati,
22:11
Speaker 3: potresti dover utilizzare quel backup a livello di ambiente o
22:13
Speaker 3: suddividere i ripristini delle singole tabelle a seconda di ciò
22:16
Speaker 3: che è disponibile. Una lezione appresa a tue spese? Non
22:20
Speaker 3: dare mai per scontato che il tuo piano di rollback
22:21
Speaker 3: sia solido a meno che tu non lo abbia testato
22:23
Speaker 3: in una sandbox. La differenza tra un processo di ripristino
22:26
Speaker 3: teorico e uno reale è enorme. Senza effettuare test rischi
22:30
Speaker 3: di ripristinare dipendenze incomplete e di riscontrare conflitti di importazione imprevisti.
22:34
Speaker 3: Esercitarsi con il rollback è un