Procedure consigliate di gestione del ciclo di vita

Questo articolo offre il materiale sussidiario per i creatori di dati e analisi che gestiscono il contenuto durante l'intero ciclo di vita. L'articolo è incentrato sull'uso dell'integrazione Git per il controllo del codice sorgente e le pipeline di distribuzione come strumento di rilascio. Per consultare il materiale sussidiario sulla pubblicazione di contenuti in Enterprise, vedere pubblicazione di contenuti in Enterprise.

L'articolo è suddiviso in quattro sezioni:

• Preparazione del contenuto: preparare il contenuto per la gestione del ciclo di vita.

• Sviluppo: informazioni sui modi migliori per creare il contenuto nella fase di sviluppo delle pipeline di distribuzione.

• Test: informazioni su come usare la fase di test delle pipeline di distribuzione per testare l'ambiente.

• Produzione: usare la fase di produzione delle pipeline di distribuzione quando il contenuto diventa disponibile per l’uso.

Preparazione del contenuto

Per preparare al meglio il contenuto per la gestione in corso durante il ciclo di vita, esaminare le informazioni contenute in questa sezione prima di:

• Rilasciare il contenuto nell'ambiente di produzione.

• Iniziare a usare una pipeline di distribuzione per un'area di lavoro specifica.

Dividere lo sviluppo tra team

Diversi team dell'organizzazione hanno in genere competenze, proprietà e metodi di lavoro diversi, anche quando si lavora sullo stesso progetto. È importante mettere dei limiti, dando a ogni team la propria indipendenza per lavorare come preferisce. Prendere in considerazione la possibilità di avere aree di lavoro separate per team diversi. Con aree di lavoro separate, ogni team può avere autorizzazioni diverse, lavorare con repository di controllo del codice sorgente diversi e spedire il contenuto alla produzione a una cadenza diversa. La maggior parte degli elementi può connettersi e usare i dati tra aree di lavoro, quindi non blocca la collaborazione sugli stessi dati e sullo stesso progetto.

Pianificare il modello di autorizzazione

Sia l'integrazione Git che le pipeline di distribuzione richiedono autorizzazioni diverse rispetto alle sole autorizzazioni dell'area di lavoro. Informazioni sui requisiti di autorizzazione per le pipeline di integrazione e distribuzione Git.

Per implementare un flusso di lavoro sicuro e semplice, pianificare chi ottiene l'accesso a ogni parte degli ambienti in uso, sia il repository Git che le fasi di sviluppo/test/produzione in una pipeline. Alcune considerazioni importanti:

• Chi deve avere accesso al codice sorgente nel repository Git?

• Quali operazioni devono poter eseguire gli utenti che accedono alla pipeline in ogni fase?

• Chi esamina il contenuto nella fase di test?

• I revisori della fase di test hanno accesso alla pipeline?

• Chi deve supervisionare la distribuzione nella fase di produzione?

• Quale area di lavoro si sta assegnando a una pipeline o durante la connessione a Git?

• A quale ramo si sta collegando l'area di lavoro? Qual è il criterio definito per tale ramo?

• L'area di lavoro è condivisa da più membri del team? Devono apportare modifiche direttamente nell'area di lavoro o solo tramite richieste pull?

• Quale fase viene assegnata all'area di lavoro?

• È necessario apportare modifiche alle autorizzazioni dell'area di lavoro che si sta assegnando?

Connettere fasi diverse a database diversi

Un database di produzione deve essere sempre stabile e disponibile. È preferibile non sovraccaricarlo con query generate dai creatori di BI per i modelli semantici di sviluppo o test. Compilare database separati per lo sviluppo e i test al fine di proteggere i dati di produzione, e non sovraccaricare il database di sviluppo con l'intero volume dei dati di produzione.

Usare i parametri per le configurazioni che cambieranno tra le fasi

Quando possibile, aggiungere parametri a qualsiasi definizione che potrebbe cambiare tra fasi di sviluppo/test/produzione. L'uso dei parametri consente di modificare facilmente le definizioni quando si spostano le modifiche nell'ambiente di produzione. Anche se non esiste ancora un modo unificato per gestire i parametri in Fabric, è consigliabile usarlo negli elementi che supportano qualsiasi tipo di parametrizzazione. I parametri hanno usi diversi, ad esempio la definizione delle connessioni alle origini dati o agli elementi interni in Fabric. Possono anche essere usati per apportare modifiche a query, filtri e testo visualizzato agli utenti.
Nelle pipeline di distribuzione è possibile configurare le regole dei parametri per impostare valori diversi per ciascuna fase di distribuzione.

Sviluppo

Questa sezione offre materiale sussidiario sull'uso della fase di sviluppo delle pipeline di distribuzione.

Eseguire il backup del lavoro in un repository Git

Con l'integrazione con Git, qualsiasi sviluppatore può eseguire il backup del proprio lavoro eseguendone il commit in Git. Per eseguire correttamente il backup del lavoro in Fabric, ecco alcune regole di base:

• Assicurarsi di disporre di un ambiente isolato in cui lavorare, in modo che altri utenti non sostituiscano il lavoro prima che venga eseguito il commit. Ciò significa lavorare in uno strumento desktop (ad esempio VS Code, Power BI Desktop o altri) o in un'area di lavoro separata a cui altri utenti non possono accedere.

• Eseguire il commit in un ramo che si è creato e che nessun altro sviluppatore sta usando. Se si usa un'area di lavoro come ambiente di creazione, leggere le informazioni sul lavoro con i rami.

• Eseguire il commit di modifiche che devono essere implementate insieme. Questo consiglio si applica a un singolo elemento o a più elementi correlati alla stessa modifica. Il commit di tutte le modifiche correlate può essere utile in un secondo momento durante l’implementazione in altre fasi, la creazione di richieste pull o il ripristino delle modifiche.

• I commit di grandi dimensioni potrebbero raggiungere un limite massimo di dimensioni del commit. Tenere presente il numero di elementi di cui si esegue il commit nello stesso tempo o le dimensioni generali di un elemento. Ad esempio, i report possono aumentare le dimensioni quando si aggiungono immagini di grandi dimensioni. È consigliabile archiviare elementi di grandi dimensioni nei sistemi di controllo del codice sorgente, anche se funziona. Valutare i modi per ridurre le dimensioni degli elementi se hanno molte risorse statiche, ad esempio immagini.

Eseguire il rollback delle modifiche

Dopo aver eseguito il backup del lavoro, potrebbero verificarsi casi in cui si vuole ripristinare una versione precedente nell'area di lavoro. Esistono alcuni modi per ripristinare una versione precedente:

• Pulsante Annulla: l'operazione Annulla è un modo semplice e rapido per ripristinare le modifiche immediate apportate, purché non siano ancora state eseguite. È anche possibile annullare ogni elemento separatamente. Altre informazioni sull'operazione di annullamento.

• Ripristino dei commit meno recenti: non è possibile tornare direttamente a un commit precedente nell'interfaccia utente. L'opzione migliore consiste nel alzare di livello un commit precedente come HEAD usando git revert o git reset. In questo modo viene illustrato che è presente un aggiornamento nel riquadro del controllo del codice sorgente ed è possibile aggiornare l'area di lavoro con il nuovo commit.

Poiché i dati non vengono archiviati in Git, tenere presente che il ripristino di un elemento di dati in una versione precedente potrebbe interrompere i dati esistenti e potrebbe richiedere l'eliminazione dei dati o l'operazione potrebbe non riuscire. Prima di ripristinare le modifiche, controllare questa opzione in anticipo.

Uso di un'area di lavoro "privata"

Quando si vuole lavorare in un ambiente isolato, usare un'area di lavoro separata per farlo. Altre informazioni sull’ambiente di lavoro isolato nel lavoro con i rami. Per un flusso di lavoro ottimale per l'utente e il team, considerare i punti seguenti:

• Configurazione dell'area di lavoro: prima di iniziare, assicurarsi di poter creare una nuova area di lavoro (se non è già disponibile), di assegnarla a una capacità di Fabric e di avere accesso ai dati per lavorare nell'area di lavoro.

• Creazione di un nuovo ramo: creare un nuovo ramo dal ramo principale, in modo da disporre della versione più aggiornata del contenuto. Assicurarsi anche di connettersi alla cartella corretta nel ramo, in modo da poter eseguire il pull del contenuto corretto nell'area di lavoro.

• Piccole e frequenti modifiche: è consigliabile usare Git per apportare piccole modifiche incrementali facili da unire e con minore probabilità di entrare in conflitti. Se non è possibile, assicurarsi di aggiornare il ramo dal ramo principale in modo da poter risolvere i conflitti autonomamente.

• Modifiche alla configurazione: se necessario, modificare le configurazioni nell'area di lavoro per migliorare la produttività. Alcune modifiche possono includere la connessione tra elementi o a origini dati diverse o modifiche ai parametri di un determinato elemento. Tenere presente che tutto ciò di cui si esegue il commit diventa parte del commit e può essere accidentalmente unito al ramo principale.

Usare gli strumenti client per modificare il lavoro

Per gli elementi e gli strumenti che lo supportano, potrebbe essere più semplice usare gli strumenti client per la creazione, ad esempio Power BI Desktop per modelli semantici e report, VSCode per notebook e così via. Questi strumenti possono essere l'ambiente di sviluppo locale. Dopo aver completato il lavoro, eseguire l’invio delle modifiche nel repository remoto e sincronizzare l'area di lavoro per caricare le modifiche. Assicurarsi di lavorare con la struttura supportata dell'elemento che si sta creando. Se non si è certi, clonare prima di tutto un repository con contenuto già sincronizzato con un'area di lavoro, quindi iniziare a creare da lì, dove la struttura è già presente.

Gestione di aree di lavoro e rami

Poiché un'area di lavoro può essere connessa a un singolo ramo alla volta, è consigliabile considerarla come mapping uno a uno. Tuttavia, per ridurre la quantità di area di lavoro che comporta, prendere in considerazione queste opzioni:

• Se uno sviluppatore configura un'area di lavoro privata con tutte le configurazioni necessarie, può continuare a usare tale area di lavoro per qualsiasi ramo che si creerà in futuro. Quando uno sprint è finito, le modifiche vengono unite e si avvia una nuova attività, è sufficiente passare alla connessione a un nuovo ramo nella stessa area di lavoro. È inoltre possibile farlo se improvvisamente è necessario correggere un bug al centro di uno sprint. Si consideri una directory di lavoro sul Web.

• Gli sviluppatori che usano uno strumento client, ad esempio VS Code, Power BI Desktop o altri, non necessitano necessariamente di un'area di lavoro. Possono creare rami ed eseguire il commit delle modifiche in tale ramo in locale, eseguirne l’invio nel repository remoto e creare una richiesta pull al ramo principale, il tutto senza un'area di lavoro. Un'area di lavoro è necessaria solo come ambiente di test per verificare che tutto funzioni in uno scenario reale. Spetta all’utente decidere quando ciò debba accadere.

Duplicare un elemento in un repository Git

Per duplicare un elemento in un repository Git:

1. Copiare l'intera directory degli elementi.
2. Modificare logicalId impostando un valore univoco per l'area di lavoro connessa.
3. Modificare il nome visualizzato per distinguerlo dall'elemento originale ed evitare errori di nome visualizzato duplicati.
4. Se necessario, aggiornare i nomi logicalId e/o visualizzati in eventuali dipendenze.

  Test

Questa sezione offre materiale sussidiario sul lavoro in fase di test delle pipeline di distribuzione.

Simulare l'ambiente di produzione

È importante vedere in che modo la modifica proposta influirà sulla fase di produzione. La fase di test delle pipeline di distribuzione consente di simulare un ambiente di produzione reale a scopo di test. In alternativa, è possibile simulare questa operazione connettendo Git a un'altra area di lavoro.

Considerare questi tre fattori nell'ambiente di testing:

• Volume dei dati

• Volume di utilizzo

• Capacità simile a quella dell'ambiente di produzione

Quando si esegue il test, è possibile usare la stessa capacità della fase di produzione. Tuttavia, l'uso della stessa capacità può rendere instabile l’ambiente di produzione durante i test di carico. Per evitare tale instabilità, eseguire il test utilizzando una diversa capacità, con risorse simili alla capacità dell’ambiente di produzione. Per evitare costi aggiuntivi, usare una capacità in cui è possibile pagare solo per il tempo per il test.

Usare le regole di distribuzione con un'origine dati reale

Se si usa la fase di test per simulare l'uso reale dei dati, è meglio separare le fonti di dati di sviluppo da quelle di test. Il database di sviluppo deve essere relativamente piccolo e il database di test deve essere il più simile possibile al database di produzione. Usare le regole dell'origine dati per cambiare origini dati nella fase di test o parametrizzare la connessione se non funzionano tramite pipeline di distribuzione.

Controllare gli elementi correlati

Le modifiche apportate possono influire anche sugli elementi dipendenti. Nel corso del test, verificare che le modifiche non influiscano o interrompano le prestazioni degli elementi esistenti, che possono dipendere dagli elementi aggiornati.

È possibile trovare facilmente gli elementi correlati usando l'analisi dell'impatto.

Aggiornamento degli elementi di dati

Gli elementi di dati sono elementi che archiviano i dati. La definizione dell'elemento in Git definisce la modalità di archiviazione dei dati. Quando si aggiorna un elemento nell'area di lavoro, la definizione viene importata nell'area di lavoro e la si applica ai dati esistenti. Il funzionamento dell'aggiornamento degli elementi di dati è lo stesso per le pipeline di distribuzione e Git.

Poiché i diversi elementi hanno capacità diverse quando si tratta di conservare i dati, durante l’applicazione di modifiche alla definizione tenere presente quando si applicano le modifiche. Alcune procedure che consentono di applicare le modifiche nel modo più sicuro:

• Sapere in anticipo quali sono le modifiche e qual è il loro impatto sui dati esistenti. Usare i messaggi di commit per descrivere le modifiche apportate.

• Per vedere il modo in cui l'elemento gestisce la modifica con i dati di test, caricare le prima modifiche in un ambiente di sviluppo o di test.

• Se tutto va bene, è consigliabile controllarlo anche in un ambiente di gestione temporanea, con dati reali (o il più vicino possibile), per ridurre al minimo i comportamenti imprevisti nell'ambiente di produzione.

• Prendere in considerazione la tempistica migliore, quando si aggiorna l'ambiente Prod per ridurre al minimo i danni causati da eventuali errori agli utenti aziendali che utilizzano i dati.

• Dopo la distribuzione, i test post-distribuzione in Prod consentono di verificare che tutto funzioni come previsto.

• Alcune modifiche verranno sempre considerate modifica che causanp un'interruzione. Speriamo che i passaggi precedenti ti aiutino a monitorarli prima dell'ambiente di produzione. Creare un piano per applicare le modifiche in Prod e ripristinare i dati per tornare allo stato normale e ridurre al minimo i tempi di inattività per gli utenti aziendali.

Testare l'app

Se si distribuisce il contenuto ai clienti tramite un'app, rivedere la nuova versione dell'app prima che venga immessa nell’ambiente di produzione. Dato che ogni fase della pipeline di distribuzione ha una propria area di lavoro, è possibile pubblicare e aggiornare facilmente le app per le fasi di sviluppo e test. La pubblicazione e l'aggiornamento delle app consente di testare l'app dal punto di vista dell’utente finale.

Produzione

Questa sezione offre indicazioni sulla fase di produzione delle pipeline di distribuzione.

Gestire gli utenti autorizzati alla distribuzione nell'ambiente di produzione

Poiché la distribuzione nell'ambiente di produzione deve essere gestita con attenzione, è consigliabile consentire la gestione di questa operazione delicata solo a persone specifiche. Si vorrà probabilmente che tutti gli autori di BI per un'area di lavoro specifica abbiano accesso alla pipeline. Usare le autorizzazioni dell'area di lavoro dell’ambiente di produzione per gestire le autorizzazioni di accesso. Altri utenti possono avere un ruolo visualizzatore dell'area di lavoro di produzione per visualizzare il contenuto nell'area di lavoro, ma non apportare modifiche dalle pipeline di distribuzione o Git.

Inoltre, limitare l'accesso al repository o alla pipeline abilitando le autorizzazioni solo agli utenti che fanno parte del processo di creazione dei contenuti.

Impostare le regole per assicurare la disponibilità della fase di produzione

Le regole di distribuzione sono un modo efficace per assicurare che i dati nell’ambiente di produzione siano sempre connessi e disponibili agli utenti. Applicando le regole di distribuzione, è possibile eseguire le distribuzioni e al tempo stesso essere sicuri che gli utenti finali possano visualizzare le informazioni rilevanti senza interferenze.

Assicurarsi di impostare le regole di distribuzione della produzione per le origini dati e per i parametri definiti nel modello semantico.

Aggiornare l'app di produzione

La distribuzione in una pipeline tramite l'interfaccia utente aggiorna il contenuto dell'area di lavoro. Per aggiornare l'app associata, usare l'API delle pipeline di distribuzione. Non è possibile aggiornare l'app tramite l'interfaccia utente. Se si usa un'app per la distribuzione del contenuto, non dimenticare di aggiornare l'app dopo aver eseguito la distribuzione nell'ambiente di produzione in modo che gli utenti finali possano usare la versione più recente immediatamente.

Distribuzione nell'ambiente di produzione tramite rami Git

Poiché il repository funge da "unica origine di riferimento", alcuni team potrebbero voler distribuire gli aggiornamenti in diverse fasi direttamente da Git. Ciò è possibile con l'integrazione di Git, con alcune considerazioni:

• È consigliabile usare i rami di rilascio. È necessario modificare continuamente la connessione dell'area di lavoro ai nuovi rami di rilascio prima di ogni distribuzione.

• Se la pipeline di compilazione o di versione richiede di modificare il codice sorgente o di eseguire script in un ambiente di compilazione prima della distribuzione nell'area di lavoro, la connessione dell'area di lavoro a Git non sarà utile.

• Dopo la distribuzione in ciascuna fase, assicurarsi di modificare tutte le configurazioni specifiche di tale fase.

Correzioni rapide del contenuto

In alcuni casi nell'ambiente di produzione si verificano problemi che richiedono una correzione rapida. Distribuire una correzione senza averla prima testata non è una procedura consigliabile. Pertanto, implementare sempre la patch nella fase di sviluppo e eseguirne il push nelle altre fasi della pipeline di distribuzione. La distribuzione nella fase di sviluppo consente di controllare il funzionamento della patch prima di distribuirla nell'ambiente di produzione. La distribuzione nella pipeline richiede solo pochi minuti.

Se si usa la distribuzione da Git, è consigliabile seguire le procedure descritte in Adottare una strategia di ramificazione Git.

Contenuto correlato

• Esercitazione sulla gestione del ciclo di vita end-to-end
• Introduzione all'integrazione Git
• Iniziare a usare le pipeline di distribuzione