Procedure consigliate per la gestione del ciclo di vita

Questo articolo fornisce indicazioni per i creatori di dati e analisi che gestiscono il contenuto durante tutto il ciclo di vita in Microsoft Fabric. L'articolo è incentrato sull'uso dell'integrazione Git per il controllo del codice sorgente e le pipeline di distribuzione come strumento di rilascio. Per indicazioni generali sulla pubblicazione di contenuti aziendali, pubblicazione di contenuti aziendali.

Importante

Questa funzionalità è disponibile in anteprima.

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 contenuto nella fase di sviluppo delle pipeline di distribuzione.

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

• Produzione : usare una fase di produzione delle pipeline di distribuzione per rendere il contenuto disponibile per l'utilizzo.

Preparazione del contenuto

Per preparare al meglio il contenuto per la gestione in corso nel corso del 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.

Separare lo sviluppo tra i team

Diversi team dell'organizzazione hanno in genere competenze, proprietà e metodi di lavoro diversi, anche quando si lavora sullo stesso progetto. È importante impostare i limiti, dando a ogni team la propria indipendenza per lavorare come preferiscono. 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 in 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 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/prod in una pipeline. Alcune delle considerazioni da tenere in considerazione sono:

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

• Quali operazioni devono essere eseguite dagli utenti con accesso alla pipeline in ogni fase?

• Chi sta esaminando il contenuto nella fase di test?

• I revisori della fase di test devono avere accesso alla pipeline?

• Chi deve supervisionare la distribuzione nella fase di produzione?

• Quale area di lavoro si sta assegnando a una pipeline o ci si connette a Git?

• A quale ramo si connette 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?

• A quale fase si assegna l'area di lavoro?

• È necessario apportare modifiche alle autorizzazioni dell'area di lavoro da assegnare?

Connessione fasi diverse a database diversi

Un database di produzione deve essere sempre stabile e disponibile. È consigliabile non eseguirne l'overload con query generate dagli autori di BI per i modelli semantici di sviluppo o test. Creare database separati per lo sviluppo e i test per proteggere i dati di produzione e non sovraccaricare il database di sviluppo con l'intero volume di 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 ogni fase di distribuzione.

Sviluppo

Questa sezione fornisce indicazioni per l'uso delle pipeline di distribuzione e l'uso della fase di sviluppo.

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 eseseguono l'override del 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 creato e nessun altro sviluppatore sta usando. Se si usa un'area di lavoro come ambiente di creazione, leggere le informazioni sull'uso dei rami.

• Eseguire il commit di modifiche che devono essere distribuite 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 la distribuzione 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 insieme 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.

Rollback delle modifiche

Dopo aver eseguito il backup del lavoro, potrebbero verificarsi casi in cui si vuole ripristinare una versione precedente e ripristinarla 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 isolamento, usare un'area di lavoro separata come ambiente isolato. Altre informazioni sull'isolamento dell'ambiente di lavoro nell'uso dei 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 Infrastruttura e di avere accesso ai dati per lavorare nell'area di lavoro.

• Creazione di un nuovo ramo: creare un nuovo ramo dal ramo principale , quindi è disponibile la 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ò che si esegue il commit diventa parte del commit e può essere accidentalmente unito nel 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 il push delle modifiche nel repository remoto e sincronizzare l'area di lavoro per caricare le modifiche. Assicurati di lavorare con la struttura supportata dell'elemento che stai 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 1:1. 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 futuro creato. 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. È anche 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 il push nel repository remoto e creare una richiesta pull al ramo principale, 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 a te decidere quando dovrebbe 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 fornisce indicazioni per l'uso di una 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. Una 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.

Assicurarsi che questi tre fattori siano risolti nell'ambiente di test:

• Volume dei dati

• Volume di utilizzo

• Una capacità simile a quella di produzione

Durante i test, è possibile usare la stessa capacità della fase di produzione. Tuttavia, l'uso della stessa capacità può rendere instabile la produzione durante i test di carico. Per evitare la produzione instabile, testare l'uso di una capacità diversa simile alle risorse per la capacità di produzione. Per evitare costi aggiuntivi, usare una capacità in cui è possibile pagare solo per il tempo di test.

Usare le regole di distribuzione con un'origine dati reale

Se si usa la fase di test per simulare l'utilizzo dei dati reali, è consigliabile separare le origini dati di sviluppo e 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. Durante il test, verificare che le modifiche non influiscano o interrompano le prestazioni degli elementi esistenti, che possono dipendere da quelli 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 funzionalità diverse quando si tratta di conservare i dati quando vengono applicate 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 come l'elemento gestisce la modifica con i dati di test, caricare le modifiche prima in un ambiente di sviluppo o test.

• Se tutto va bene, è consigliabile controllarlo anche in un ambiente di staging, 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 modifiche di rilievo. Speriamo che i passaggi precedenti ti aiuteranno 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 contenuto ai clienti tramite un'app, esaminare la nuova versione dell'app prima che sia in produzione. Poiché 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 di un utente finale.

Importante

Il processo di distribuzione non include l'aggiornamento del contenuto o delle impostazioni dell'app. Per applicare modifiche al contenuto o alle impostazioni, aggiornare manualmente l'app nella fase della pipeline richiesta.

Produzione

Questa sezione fornisce indicazioni per la fase di produzione delle pipeline di distribuzione.

Gestire chi può eseguire la distribuzione nell'ambiente di produzione

Poiché la distribuzione nell'ambiente di produzione deve essere gestita con attenzione, è consigliabile consentire solo a persone specifiche di gestire questa operazione sensibile. Tuttavia, è probabile che tutti gli autori di business intelligence per un'area di lavoro specifica abbiano accesso alla pipeline. Usare le autorizzazioni dell'area di lavoro 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 solo le autorizzazioni per gli utenti che fanno parte del processo di creazione del contenuto.

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

Le regole di distribuzione sono un modo efficace per garantire che i dati nell'ambiente di produzione siano sempre connessi e disponibili agli utenti. Con le regole di distribuzione applicate, le distribuzioni possono essere eseguite mentre si garantisce che i clienti possano visualizzare le informazioni pertinenti senza disturbi.

Assicurarsi di impostare le regole di distribuzione di produzione per le origini dati e 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 usi un'app per la distribuzione del contenuto, non dimenticare di aggiornare l'app dopo la distribuzione nell'ambiente di produzione in modo che gli utenti finali siano immediatamente in grado di usare la versione più recente.

Distribuzione nell'ambiente di produzione tramite rami Git

Poiché il repository funge da "single source-of-truth", 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 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 ogni fase, assicurarsi di modificare tutte le configurazioni specifiche di tale fase.

Correzioni rapide del contenuto

In alcuni casi si verificano problemi nell'ambiente di produzione che richiedono una correzione rapida. La distribuzione di una correzione senza testarla prima è una procedura non valida. Pertanto, implementare sempre la correzione nella fase di sviluppo e eseguirne il push nelle altre fasi della pipeline di distribuzione. La distribuzione nella fase di sviluppo consente di verificare che la correzione funzioni prima di distribuirla nell'ambiente di produzione. La distribuzione nella pipeline richiede solo alcuni minuti.

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

Contenuto correlato

• Esercitazione sulla gestione del ciclo di vita end-to-end
• Introduzione all'integrazione di Git
• Introduzione alle pipeline di distribuzione