Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / ALM di Power Platform con GitHub Actions: sorgente, build, test e rilascio senza tirare a indovinare (Doppiaggio IA)

Transcript

ALM di Power Platform con GitHub Actions: sorgente, build, test e rilascio senza tirare a indovinare (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Pronto per dieci giorni di Microsoft 365, Copilot, intelligenza artificiale, azzurro e le persone che stanno plasmando il futuro del lavoro?
0:07
A gennaio torna M365 con E e ci stiamo espandendo.
0:12
Uniscite noi per sessioni live, dimostrazioni pratiche e conoscenze pratiche da parte di MVP ed esperti del settore di tutto il mondo.
0:18
Nessuna slide generica, nessun termine di moda infinito.
0:22
Stiamo affrontando le vere sfide.
0:23
Copilot Studio, agenti di intelligenza artificiale, Fabric, sicurezza, governance e automazione.
0:28
Che tu sia un professionista IT, uno sviluppatore o un leader aziendale, ci sono sessioni pensate per te.
0:35
Con dieci giorni interi, puoi esplorare più tecnologie e connetterti con una community globale.
0:40
Guarda in diretta e porta spunti pratici alla tua organizzazione.
0:45
Gennaio 2027, dieci giorni, una community Microsoft. Le registrazioni sono aperte ora.
0:52
Vai subito a casa tua.
0:54
Questo è m365con.net.
1:00
Iscriviti ora su m365con.net e ci vediamo dal vivo.
1:03
A gennaio, hai mai avuto la sensazione che le tue distribuzioni di Power Platform fossero una scatola niente?
1:08
Rilasci un aggiornamento trattenendo il respiro e sperando che funzioni tra sviluppo, test e produzione.
1:12
E se potessi effettivamente controllare e vedere ogni fase del tuo processo LM usando GitHub Actions senza più indovinare o apportare modifiche manuali, scopriamo insieme come ogni componente, controllo del codice sorgente, automazione e variabili di sicurezza si collegano realmente, si collegano realmente.
1:28
Questa non è solo un'altra procedura dettagliata.
1:30
È il motivo per cui la maggior parte delle guide tralascia questo argomento in modo che la tua prossima distribuzione non ti lasci ne due.
1:34
Ecco perché Power Platform a LM sembra un labirinto.
1:38
Se hai mai provato a distribuire una Power App e hai avuto la sensazione di un'incertezza strisciante come se qualcosa di importante fosse sfuggito, non sai il solo.
1:45
Non sai il solo.
1:46
Sulla carta Power Platform promette uno sviluppo di app semplice ma dietro questa facciata intuitiva a LM è tutt'altro che lineare.
1:52
Un'app web viene distribuita dal controllo del codice sorgente, compilata in una pipeline e arriva in produzione con un comportamento prevedibile.
2:00
Power Platform, d'altro canto, nasconde metà della logica all'interno di interfaccia utente con trascinamento della selezione.
2:05
Schermate di connettori e formule che non puoi vedere in nessun repositori git.
2:08
Quindi anche se segui ogni passaggio di quelle guide amministrative di alto livello, ti imbatti comunque in strani errori difficili da diagnosticare quando le app aziendali critiche escono dallo sviluppo.
2:17
Diamo un'occhiata alle guide LM in circolazione.
2:19
La maggior parte di esse ti guiderà attraverso l'esportazione di un file zip di soluzione e la sua importazione altrove.
2:24
Basta semplice, vero?
2:25
Ma il come è solo un livello.
2:27
Ciò che saltano è il perché.
2:29
Perché la distribuzione di Power Platform si interrompe in modo in cui il codice normale non lo fa mai?
2:33
Ecco cosa causa infinita confusione.
2:35
La radice del problema è che la logica, le connessioni e la configurazione in Power Apps non sono archiviate come il codice classico.
2:42
Non stai semplicemente clonando un repository e osservando i test unitari.
2:45
Quindi quando provi a spostare la tua app, tutte quelle dipendenze nascoste e connessioni Outlook, SharePoint, API personalizzate, non sempre viaggiano ordinatamente all'interno di quel file zip.
2:54
Ecco lo scenario.
2:55
Ottieni una nuova app brillante che funziona nell'ambiente di sviluppo.
2:58
Esporti una soluzione, la importi in fase di test e all'improvviso il flusso smette di funzionare.
3:02
Tra la mente si tratta solo il numero di file.
3:03
Al contrario, le connessioni puntano al posto sbagliato, le autorizzazioni non sono allineate e i criteri dati bloccano le connessioni che sembravano corrette fino a pochi minuti fa.
3:11
Ora, immagina di eseguire questa operazione in tre ambienti, sviluppo, test e produzione, ognuno dei quali utilizza connessioni, criteri di protezione dei dati, approvatori e protezioni amministrative diverse.
3:21
Non puoi uscirne con un copia e incolla.
3:24
La ricerca supporta ciò che amministratori e creatori vedono ogni settimana.
3:27
La maggior parte delle distribuzioni Power Platform non riuscite deriva da riferimenti di connettori mancanti o variabili di ambiente gestite in modo errato.
3:34
La mancanza di un riferimento di connettore significa semplicemente che il flusso non riesce a trovare la propria connessione Outlook o Dataverse.
3:39
Quindi nel momento in cui provi a seguire l'app o il flusso in un altro ambiente ricevi errori di runtime.
3:47
E poiché le variabili di ambiente funzionano in modo diverso in Power Platform rispetto ad altri prodotti Microsoft 365 fanno inciampare anche gli sviluppatori più esperti.
3:55
Le variabili dovrebbero gestire endpoint, chiave e configurazioni specifiche del tenant.
3:59
Tuttavia, se qualcuno dimentica di aggiornarle dopo aver esportato una soluzione, anche una modifica apparentemente innocua può danneggiare un app live.
4:06
Molti di noi cadono inizialmente nella stessa trappola.
4:09
Potresti pensare che esportare una soluzione in formato zip racchiuda tutto il necessario, ma in realtà salta ai riferimenti dinamici e connettori.
4:14
Ad esempio, supponiamo di avere un'app che utilizza un connettore HTTP per un servizio di terze parti in dev.
4:18
Quando esegui un'importazione in testa e in produzione, quella distanza esatta del connettore ne esisterà.
4:23
Il riferimento al connettore all'interno dell'app punta a un oggetto mancante e i flussi all'interno della soluzione si interrompono silenziosamente finché un utente o un amministratore non ricrea e rimappa manualmente le connessioni.
4:35
Se hai più di un creatore o un amministratore, è ancora più facile perdere traccia di quale riferimento va, dove e nessuno vuole che ha funzionato in dev post-mortem.
4:44
Un altro aspetto negativo sono i principi di servizio.
4:46
La maggior parte delle persone inizia a utilizzare gli account utente per esportare e importare soluzioni perché è più veloce iniziare.
4:53
Ma quando provi ad automatizzare con le azioni di GitHub o qualsiasi sistema CI utilizzando le credenziali di una persona, finisci rapidamente in un piccolo secolo.
4:59
Ti imbatterai in barriere di autorizzazione, a volte senza messaggi di errore chiari, o addirittura attiverai controlli di conformità perché stai eseguendo distribuzioni critiche con un account personale anziché con qualcosa pensato per l'automazione.
5:09
L'entità servizio, essenzialmente identità di app create in Azure AD, gestiscono tutte le autorizzazioni, la registrazione e controllo delle esigenze della pipeline.
5:19
Senza di esse, la tua catena di automazione si trasforma in un mosaico di passaggi di consegne da persona a persona a persona, non sai mai chi ha modificato cosa.
5:25
Anche il controllo del codice sorgente si trasforma in uno.
5:27
Con il codice normale hai cronologie di commit e strumenti di attribuzione delle call.
5:32
I file di soluzione di Power Platform rappresentano solo snapshot, che significa che ti manca il monitoraggio di un'area delle modifiche.
5:37
La logica nascosta nelle formule dello schermo di un'app canvas o in flussi scarsamente documentati non è visibile finché non esegui di nuovo l'esportazione.
5:44
Qualcuno modifica un'impostazione di flusso nell'interfaccia utente e buona fortuna nello scopriere perché gli ambienti downstream si comportano improvvisamente modifiche.
5:49
Il risultato finale, ovvero la gestione di LM per Power Platform, è come risolvere un puzzle a cui mancano metà dei pezzi o che almeno sono nascosti sotto la scatola.
5:57
Dipendenze invisibili, connettori specifici dell'ambiente e variabili, che non è possibile vedere nel codice, modellano il consueto flusso di lavoro degli sviluppatori.
6:06
E questo prima di dover considerare il fatto che gli ambienti di produzione hanno quasi sempre autorizzazioni più rigide e criteri sui dati diversi e requisiti di controllo che non sono evidenti in fase di sviluppo o test.
6:16
Ecco il lato positivo.
6:18
Questa complessità non è casuale.
6:19
C'è una ragione pratica per cui Power Platform gestisce codice sorgente, variabili e connettori in un modo così unico?
6:27
Cerca di consentire agli utenti aziendali di creare app potenti senza preoccuparsi del codice.
6:32
L'effetto collaterale è che tu, in quanto persona che imposta l'automazione, devi tenere traccia di ciò che si nasconde sotto il cofano.
6:38
Se sai dove passano quei fili invisibili, puoi risolvere o evitare la maggior parte dei problemi che fanno deragliare Power Platform LM.
6:45
Ora, se tutto questo ti sembra troppo da gestire, non ti sbagli, ma ci sono quattro pilastri LM che aiutano effettivamente a districare questo pasticcio.
6:53
Origine, compilazione, test, diluzione.
6:55
Ognuno di questi elementi ha le sue peculiarità in Power Platform, ma insieme riescono a ridare struttura a ciò che altrimenti sembrerebbe caos.
7:02
Il sistema LM di base, origine, compilazione, test e distribuzione.
7:05
Ogni volta che qualcuno chiede una pipeline di Power Platform che funzioni, la prima cosa che gli viene in mente sono quei quattro polverosi pilastri di LM.
7:11
Origine, compilazione, test e distribuzione.
7:15
Nel tradizionale ambiente di sviluppo potresti quasi eseguirli nel sonno.
7:19
Power Platform non te la cava così facilmente.
7:21
All'improvviso, origine non significa codice.
7:24
Significa litigare con file di soluzione, esportare bundle compressi pieni di app, flussi e talvolta connettori che fingono di essere parte dell'origine.
7:32
Iniziamo dalle basi, quindi analizziamo cosa rende ogni pilastro un po' strano in questo mondo.
7:38
Hai il file zip dell'autosoluzione.
7:40
Non è codice nel senso che uno è detto.
7:42
Aprilo e ti vengono presentati i file esplicativi XML e JSON, non la logica che troveresti in TypeScript o C Sharp.
7:47
Ma questa è l'origine di Power Platform.
7:50
I team spesso inciampano qui.
7:52
Sembra portabile finché non ti rendi conto che la maggior parte delle modifiche, come l'aggiornamento di una formula in una schermata o la modifica della logica di un flusso,
7:59
non sono evidenti finché non esporti un nuovo file zip della soluzione.
8:02
Quindi sì, puoi creare una versione di questi file di soluzione in Git, ma a meno che tu non sia disciplinato nell'esportare dopo ogni modifica rilevante e la cronologia presenta lacuni evidenti,
8:09
Ora arriva la configurazione.
8:12
Per le app normali potreste archivare le stringhe di connessione in un file di configurazione e chiudere lì.
8:17
Power Platform introduce di nascosto dati specifici dell'ambiente all'interno di queste soluzioni.
8:21
Non si tratta solo di variabili di ambiente, ma anche di riferimenti ai connettori, endpoint dinamici, ruoli e autorizzazioni raggruppati insieme alla logica aziendale.
8:29
Se non li aggiorni prima di esportare da dev o test, stai bloccando i puntatori nel posto sbagliato.
8:35
Ho visto team impegnare religiosamente i loro file zip della soluzione, solo per poi distribuirli e rendersi conto che metà della loro app sta ancora comunicando con il dataverse di dev, anziché con prod, perché nessuno ha rimappato i riferimenti ai connettori.
8:48
Quindi abbiamo creato.
8:50
La parola build solitamente evoca immagini di codice di compilazione e segni di spunta verdi in un processo di CI.
8:55
Con Power Platform il processo di build consiste nell'archiviare quei bundle zip, ricontrollare lo schema e verificare le dipendenze.
9:01
In una pipeline di GitHub Actions un processo di build acquisisce il file della soluzione di cui è stato eseguito il comi, quindi utilizza l'interfaccia della riga di comando di Power Platform di Microsoft per decomprimere, convalidare e impacchettare la soluzione.
9:12
La fase di convalida è dove avviene la magia o il caos?
9:14
Potrebbe rilevare riferimenti interrotti e azioni non supportate?
9:18
Peggio ancora, se una modifica al flusso si basa su un connettore personalizzato che non è mai stato inserito nel controllo del codice sorgente, la build crea automaticamente un pacchetto incompleto.
9:25
Ecco dove le cose si complicano.
9:28
Questi processi di build riguardano meno la compilazione e più l'orchestrazione di un'esportazione affidabile e la verifica che il contenuto sia distribuibile.
9:36
I team che saltano questo passaggio lo affrettano finiscono rapidamente in situazioni in cui una build ha tecnicamente successo, ma ciò che finisce in U8 o in produzione manca della metà delle funzionalità previste.
9:45
Microsoft continua a promuovere il messaggio che i file di soluzione rendono ALM portabile ma c'è sempre una nota a piedi pagina.
9:50
La portabilità dipende dal fatto che i connettori siano mappati correttamente e che i ruoli siano impostati in tutti gli ambienti.
9:54
Il test è il pulsante di regione successiva.
9:56
In una pipeline di app web i test automatizzati potrebbero eseguire test unitario o controlli dell'interfaccia utente.
10:02
Per Power Platform cosa conta come test? È oggetto di dibattito.
10:06
A volte si tratta della convalida da soluzioni, in altre parole la soluzione si apre e le dipendenze chiave vengono risolte.
10:12
Altre volte si tratta di eseguire flussi di test o verificare che i connettori rispondano in un ambiente di test.
10:18
Spesso il test è manuale perché la convalida della logica aziendale all'interno di un'app canvas non è ancora collegata alle pipeline automatizzate.
10:25
Tuttavia è possibile automatizzare i controlli per individuare connettori mancanti, convalidare flussi critici
10:29
o persino eseguire il ping di un ambiente di test solo per dimostrare che le credenziali funzionano.
10:34
La distribuzione è la causa principale.
10:35
Quando viene distribuita un'app standard potresti semplicemente eseguire il push di un artefatto web su altro.
10:40
Con Power Platform devi mappare le connessioni, assegnare autorizzazioni, aggiornare i segreti, scambiare variabili di ambiente
10:45
e infine attivare un'importazione utilizzando un'entità a servizio, ma è un account normale.
10:49
Altrimenti rimane bloccato con audit e di nieghi di autorizzazione.
10:53
Le azioni GitHub possono collegare questo processo, ma solo se ogni processo sa a quale ambiente fare riferimento e quali segreti usare.
10:59
Ho visto team provare a abbreviare questo processo usando un singolo set di credenziali tra sviluppo e produzione,
11:04
il che è una ricetta per il caos, perdite di dati, errori di autorizzazione e funzionalità non funzionanti che si presentano solo in un ambiente.
11:11
Prendo un team reale con cui ho lavorato qualche mese fa.
11:14
Hanno fatto la maggior parte delle cose correttamente, repositori Git standard, zip di soluzioni, conversioni chiare.
11:18
La loro pipeline si è sempre interrotta durante l'estribuzione.
11:20
Non si sono mai preoccupati di scambiare le variabili di ambiente e aggiornare i riferimenti dei connettori prima di importare in produzione.
11:27
Ciò ha lasciato flussi chiave che puntavano agli endpoint sbagliati,
11:29
con dati che filtravano nei sistemi sbagliati.
11:31
La soluzione è stata costituita da passaggi con script nella loro pipeline GitHub
11:34
che hanno scambiato le variabili e rimappato ogni connettore durante l'importazione.
11:38
Le linee guida di Microsoft sono molto chiare su questo.
11:40
Utilizza i file di soluzione per spostare elementi tra ambienti,
11:43
ma gestisci sempre i riferimenti dei connettori e la mappatura dei ruoli come parte della tua pipeline.
11:48
Sottolineo che saltare questi passaggi è il modo principale per dammeggiare le app,
11:51
soprattutto quando gli ambienti diventano più bloccati.
11:54
Una volta che si considerano la creazione di codice sorgente,
11:56
la compilazione, il test e la distribuzione come parti mobili connesse,
11:59
non solo passaggi isolati, è più facile capire perché così tanti tentativi di LM falliscono,
12:03
è come possibile risolvere i problemi anziché incrociare le dita.
12:07
Ora, vediamo come GitHub Actions coordina questa danza,
12:09
i trigger, la diramazione e la separazione dei processi
12:12
che mantengono l'automazione di Power Platform flessibile e sicura.
12:17
GitHub Actions collega i puntini con trigger e processi.
12:19
Se hai atteso il completamento di una pipeline di GitHub Actions dopo aver aggiornato Power Up,
12:25
sai già che l'automazione non è immediata e sicuramente non è magica.
12:29
La maggior parte dei team si scontra con quel muro subito dopo l'entusiasmo di vedere il loro primo flusso di lavoro eseguito.
12:34
Imposti uno script, lo colleghi al tuo repository e ti aspetti che ogni nuovo commit venga distribuito senza problemi in tutti gli ambienti.
12:41
Poi in realtà si fa sentire.
12:42
Invece di avviare semplicemente uno script, GitHub Actions utilizza una catena logica basata su trigger, processi e passaggi di consegne tra ambienti.
12:51
Tale ordine e struttura sono ciò che impedisce alle distribuzioni di diventare un groviglio di passaggi non riusciti ed errori strani.
12:56
Il punto di partenza di questo sistema è il trigger.
12:59
La maggior parte dei principianti crea un flusso di lavoro
13:02
che si attiva a ogni push o ogni volta che una richiesta di pull arriva nel ramo principale.
13:08
In superficie questa sembra una buona norma.
13:10
Perché non eseguire la pipeline ogni volta che il lavoro cambia?
13:12
Ecco il trucco.
13:13
Quando imposto un trigger solo sul ramo principale tutto viene incanalato attraverso un'unica traccia.
13:17
Cosa succede se le modifiche devono raggiungere lo sviluppo ma non il test o la produzione?
13:20
Cosa succede se sei pronto per il push in produzione ma il test ancora eseguendo la convalida?
13:24
I team che si attengono a trigger universali tendono a riscontrare problemi
13:27
in cui le funzionalità pensate per gli ambienti di sviluppo si insinuano nella produzione
13:30
o le distribuzioni di test sovrascrivono improvvisamente le impostazioni di produzione.
13:35
Puoi diramare i flussi di lavoro per ogni ambiente, sviluppo, test e produzione e impostare.
13:39
Trigger molto specifici per ognuno.
13:41
Ad esempio imposta un flusso di lavoro che venga eseguito solo sui push a un ramo di sviluppo
13:46
o attiva un flusso di lavoro diverso quando qualcuno esegue il merge in release prod.
13:50
Questo approccio offre un maggiore controllo e crea una chiara separazione tra il lavoro
13:53
in corso e le modifiche live ma molti team non riesaminano mai i propri trigger dopo averli
13:57
creati.
13:58
Ecco come i segreti di un ambiente possono passare a un altro e la configurazione destinata
14:02
allo sviluppo finisce accidentalmente in produzione.
14:05
Un team con cui ho lavorato ha provato a eseguire l'intero processo LM da un singolo flusso
14:09
di lavoro.
14:11
Per un po' sembrava tutto a posto finché qualcuno non ha notato che la stringa di connessione
14:14
al database di produzione era apparsa nell'ambiente di sviluppo.
14:18
Non si erano resi conto che i loro segreti venivano condivisi tra i job.
14:21
Una volta che il codice si spostava tra gli ambienti quei segreti troppellavano con esso.
14:24
Non si trattava di un arresto amomalo, di un errori.
14:26
Era silenzioso.
14:28
Questo tipo di perdita di dati è più comune di quanto si pensi, soprattutto se non si impostano
14:31
i flussi di lavoro per separare i segreti delle variabili di ambiente.
14:35
Ogni job in un flusso di lavoro di GitHub Actions gestisce una parte chiara del processo.
14:39
Un processo potrebbe gestire l'esportazione della soluzione dall'ambiente di origine.
14:43
Un altro processo si occupa della convalida, dell'estrazione, dell'analisi dei metadati
14:47
della soluzione, del controllo di tutte le dipendenze e della verifica dell'esistenza
14:50
dei riferimenti al connettore.
14:52
Successivamente viene il processo che prepara le variabili specifiche dell'ambiente, traducendo
14:56
la soluzione in modo che si adatti al suo ambiente di destinazione.
14:58
L'ultimo processo attiva il processo di importazione, utilizzando l'entità di servizio per scrivere
15:03
le modifiche nell'ambiente corretto.
15:05
Potresti pensare alle variabili di ambiente e ai segreti, come semplice segnaposto, ma
15:09
in pratica sono il collante che tiene insieme tutto.
15:12
String di connessione, chiavi API, password condivise.
15:15
Devono essere tutte scambiate tra i processi, ma non possono mai superare i limiti.
15:20
In Power Platform ALM potresti avere una connessione dataverse diversa per ogni ambiente o dover
15:25
scambiare l'endpoint a seconda del flusso della power-up a cui ti stai rivolgendo.
15:28
Se riutilizzi variabili o codici segreti rigidi, ti ritrovi con una pipeline fragile
15:33
o, peggio, con rischi significativi per la sicurezza.
15:36
Il processo di importazione dipende dall'estrazione dei segreti solo dal vault corretto, quindi
15:40
la produzione non è esposta a incidenti di test o di sviluppo.
15:43
Un buon modello mentale per i segreti in GitHub Actions è immaginare che ogni ambiente abbia
15:48
il suo cavo digitale, una scatola chiusa a chiave che solo i job giusti possono vedere.
15:53
GitHub ti offre controlli precisi.
15:55
Puoi limitare i segreti agli ambienti in modo che un job in esecuzione in dev non possa
15:59
accedere alle credenziali di produzione e viceversa.
16:00
Imposta questi cavo, e anche se qualcuno che modifica la pipeline tenta qualcosa di rischioso,
16:06
le regole di protezione dell'ambiente impediscono che un passo falso si verifichi.
16:10
Sia la documentazione di Microsoft e quella di GitHub sottolineano questo punto.
16:13
Raccomandano regole di protezione dell'ambiente, una rigorosa definizione dell'ambito dei segreti
16:17
per fermare le perdite tra ambienti prima ancora che inizino.
16:20
Senza questo tipo di protezione, anche i flussi di lavoro ALM meglio progettati fallisco.
16:25
Immagina un flusso di lavoro che viene distribuito in produzione mantenendo ancora una stringa
16:28
di connessione di sviluppo o un ambiente di test che improvvisamente ha accesso ai dati
16:31
di produzione.
16:32
Non sempre le cose si rompono in modo visibile.
16:35
A volte significa solo che i flag di conformità scattano e registri si riempiono di errori
16:38
sottili che lentamente si accumulano fino a diventare problemi più grandi.
16:41
Ecco perché la suddivisione dei flussi di lavoro e la definizione dell'ambito dei segreti
16:43
non sono solo argomenti avanzati.
16:45
Sono le reti di sicurezza che impedisce all'automazione di sgretolarsi silenziosamente.
16:49
È utile anche suddividere i flussi di lavoro non solo in base all'ambiente, ma anche
16:51
in base alla responsabilità.
16:54
Codice che esporta e convalida le soluzioni non dovrebbe nemmeno sapere come distribuire
16:58
o scambiare i segreti.
17:00
Se ogni processo gestisce un pezzo del puzzle diventa molto più facile individuare dove
17:03
le cose si rompono, eseguire il rollback e verificare le modifiche dopo il fatto.
17:08
I segreti rimangono nel loro vault, i processi seguono autorizzazioni chiaramente definite
17:12
e gli errori della pipeline puntano direttamente al pezzo che deve essere corretto.
17:16
Comprendere come GitHub Actions trasferisce il lavoro da un processo a un altro mantenendo
17:20
i segreti strettamente definiti e i trigger chiaramente definiti è ciò che trasforma
17:24
LM da un esperimento speranzoso a una pratica affidabile, sicura e prevedibile.
17:29
Questa segmentazione del flusso di lavoro non riguarda solo l'abbinamento delle best
17:32
practice.
17:34
È ciò che blocca le fale di sicurezza silenziose e gli override accidentali ed elimina un'intera
17:38
classe di errori invisibili prima che inizino a infestare i tuoi ambienti.
17:42
Ora che tutti i componenti funzionano insieme tramite un'automazione con ambito appropriato
17:46
ha giunto il momento di affrontare un altro punto di attrito.
17:49
Connettori, principi di servizio e le piccole ma critiche insidie che possono bloccare le
17:53
distribuzioni non appena si acquisisce sicurezza.
17:57
Principi di servizio segreto e problemi con i connettori.
18:00
Se hai mai provato a spostare una power app, un fludodev prod, conosci la storia.
18:05
Le cose funzionano perfettamente in un ambiente, poi non appena passi a un altro ambiente tutto
18:09
si blocca o ti dà quei misteriosi errori.
18:11
Di connessione.
18:13
Non è un problema esclusivo di un team specifico.
18:15
Ogni amministratore di Power Platform prima o poi si imbatte in questo ostacolo.
18:19
La radice del problema sta nel modo in cui i connettori segreti si comportano dietro le quinte.
18:25
Non puoi semplicemente esportare un file zip di soluzione allo sviluppo e aspettarti che
18:28
funzioni da qualche altra parte perché i cavi da cui dipende cambiano in ogni ambiente.
18:33
Prendi riferimento ai connettori per iniziare.
18:35
In Power Platform un connettore non è mai solo un bit statico di informazioni raggruppate
18:39
nell'app.
18:40
È dinamico, modificabile e spesso univoco per ambiente.
18:44
Quando esporti la soluzione i riferimenti ai connettori agiscono quasi come segnalibri.
18:48
Puntano a oggetti di connessione che esistono solo nell'ambiente in cui sono stati creati.
18:52
Quindi quando esegui l'importazione in testo produzione il tuo endpoint HTTP o collegamento
18:56
dataverse non viene necessariamente ricreato nello stesso modo o non viene ricreato affatto.
19:01
È qui che i team vengono colti in fatto.
19:02
Se Dev utilizza un connettore per testare i dati e quella configurazione esatta non viene
19:08
rispecchiata in produzione, il flusso o l'app non riesce in modo silenzioso o si blocca
19:13
il primo tentativo di connessione.
19:16
Molte persone cercano di aggirare questo problema condividendo le credenziali utenti tra gli ambienti.
19:21
Pensano che se utilizzi lo stesso account o la stessa password con cui è stata creata
19:24
la connessione in Dev forse funzionerà anche in produzione.
19:27
La realtà è che questo comporta una serie di problemi dai dinighi di autorizzazione
19:30
ai trighi di controllo della conformità.
19:32
Le linee guida di Microsoft sono chiare.
19:34
Utilizzare credenziali utenti individuali per le distribuzioni automatizzate non è fattibile
19:37
né sicuro.
19:39
Mette l'automazione alla merce delle reimpostazioni delle password e può lasciare una traccia poco
19:42
chiara nei registri di controllo.
19:45
Non esiste una chiara responsabilità e alla fine le autorizzazioni bloccano la pipeline
19:48
quando l'utente originale viene contrassegnato, rimosso o perde l'accesso.
19:53
Entrano in gioco l'internet suite.
19:54
Se non hai mai lavorato con loro, immagina un'entità a servizio come un set di mani
19:58
extra digitali creato appositamente per l'automazione.
20:01
A differenza di un utente normale, un'entità a servizio è legata alla registrazione di un'app
20:05
in Azure AD, non a una persona reale, non a una persona reale, gli fornisce le autorizzazioni
20:10
minime necessarie per eseguire le attività di distribuzione.
20:12
Sembra semplice ma il vantaggio è grande.
20:15
Invece di fare affidamento su un utente che potrebbe lasciare l'organizzazione o cambiare
20:18
ruolo, le distribuzioni rimangono coerenti, verificabili e tracciabili.
20:21
Ogni ambiente ottiene l'accesso solo alle connessioni e alle risorse giuste e tutte
20:24
le modifiche vengono registrate in quest'account robot.
20:28
Quando qualcosa non va, hai una traccia di controllo pulita e non ti ritrovi con flussi
20:32
orfani che nessuno può risolvere.
20:35
Per quanto riguarda il problema della mappatura dei connettori, considera cosa succede quando
20:38
gli ambienti si allontanano.
20:40
Forse il team di sviluppo ha ottenuto l'approvazione per un nuovo connettore personalizzato.
20:43
Supponiamo che raggiunga un API Sandbox.
20:45
Quando arriva il momento di passare alla produzione, quel connettore non solo manca, ma potrebbe
20:49
anche non essere consentito dai criteri di dati dell'organizzazione.
20:52
Se dimentichi di rimappare, l'app richiama l'endpoint sbagliato, si interrompe completamente.
20:58
Di recente ho visto questa situazione verificarsi duramente in un gruppo sanito.
21:01
Una mancata mappatura del connettore ha attivato l'uso di dati di test in produzione e ha quasi
21:05
creato un incidente di conformità.
21:06
La pipeline automatizzata ha esportato tutto come pianificato, ma il riferimento al connettore
21:11
all'interno della soluzione puntava ancora a un vecchio database di test che non era
21:14
stato contrassegnato da Power Platform finché i dati reali non hanno iniziato a fluire attraverso
21:18
le pipeline sbagliate.
21:20
Le variabili di ambiente intervengono per alleviare parti di questo problema.
21:23
A differenza degli endpoint di codifica rigida o delle chiavi API, le variabili di ambiente
21:27
consentono di separare ciò che cambia tra gli ambienti da ciò che rimane invariato.
21:31
Puoi scambiare endpoint, chiavi API o altri segreti a ogni distribuzione senza riscrivere
21:34
l'app o il flusso.
21:37
Ad esempio, un flusso che funziona con una tabella dataverse di sviluppo può essere riconfigurato
21:41
all'importazione per utilizzare la tabella di produzione semplicemente modificando la
21:45
variabile di ambiente all'interno del processo di distribuzione.
21:48
Le pipeline di GitHub Actions rendono questa operazione però.
21:50
Ogni processo può iniettare il valore giusto al momento giusto, ma anche in questo caso
21:54
la disciplina è fondamentale.
21:56
Se dimentichi di aggiornare una variabile o lasci che i segreti trappellino tra gli ambienti,
21:59
all'improvviso il tuo flusso di lavoro verrà esposto, Microsoft sottolinea la necessità
22:04
di definire attentamente l'ambito dei segreti e di mappare intenzionalmente i riferimenti
22:08
dei connettori.
22:09
Le policy di prevenzione della perdita di dati di LP esistono per un motivo, impedire
22:14
che informazioni sensibili si spostino tra gli ambienti o emergano nel posto sbagliato.
22:19
Se provi a eluderle condividendo variabili o connessioni, inciamperai nei controlli di
22:23
sicurezza o conformità aziendali, ancora più importante per di prevedibilità perché
22:28
non c'è più una linea di demarcazione tra ciò che è destinato allo sviluppo e ciò
22:31
che è destinato al testo e all'autorazione.
22:33
Il vantaggio di ottenere tutto questo in modo giusto è difficile da sopravvalutare.
22:36
I principi di servizio combinati con variabili di ambiente ben gestite e connettori mappati
22:40
correttamente trasformano la tua pipeline, le tue distribuzioni diventano prevedibili.
22:45
Quando le cose si rompono hai una chiara catena di custodia e sai esattamente dove cercare.
22:49
Si è trattato di una mappatura di connettori, di una variabile, di un'autorizzazione mancata.
22:52
I revisori possono seguire le modifiche e non c'è suspense quando qualcuno lascia
22:55
l'organizzazione o cambia le password.
22:58
Tutto si riduce a gestire segreti, connettori e principi di servizio come se fossero importanti.