Procedure consigliate per la gestione del ciclo di vita in Fabric

Questo articolo fornisce indicazioni per i creatori di dati e analisi che gestiscono i loro contenuti durante tutto il ciclo di vita in Fabric. Si concentra sull'uso dell'integrazione Git per il controllo del codice sorgente e delle pipeline di distribuzione come strumento per il rilascio. Per indicazioni generali sulla pubblicazione di contenuti aziendali, vedi Pubblicazione di contenuti aziendali.

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 - Utilizzare la fase di produzione di una pipeline di distribuzione per rendere il contenuto disponibile per la fruizione.

Procedure consigliate per la preparazione del contenuto

Per preparare al meglio il contenuto per la gestione continuativa durante tutto 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 dovrebbero avere accesso alla pipeline?

• Chi deve supervisionare la distribuzione nella fase di produzione?

• Quale area di lavoro si desidera assegnare a una pipeline o connettere a Git?

• A quale ramo si collega 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 stai assegnando il tuo spazio di lavoro?

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

Connetti fasi differenti a database differenti

Un database di produzione deve essere sempre stabile e disponibile. È preferibile non sovraccaricarlo con query generate dagli autori BI per i loro modelli semantici di sviluppo o di 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.
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.

Procedure consigliate per la fase di sviluppo delle pipeline di distribuzione

Questa sezione fornisce linee guida per lavorare con le pipeline di distribuzione e per utilizzarle nella fase di sviluppo.

Esegui il backup del tuo 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.

• Esegui il commit in un ramo creato da te e che nessun altro sviluppatore utilizza. Se utilizzi un'area di lavoro come ambiente di authoring, leggi ulteriori informazioni su come utilizzare i branch.

• Raggruppa in un unico commit le modifiche che devono essere distribuite insieme. Questo consiglio si applica a un singolo elemento o a più elementi correlati alla stessa modifica. Raggruppare in un unico commit tutte le modifiche correlate può esserti utile in seguito quando esegui la distribuzione in altri ambienti, crei pull request o annulli le modifiche.

• I commit di grandi dimensioni potrebbero superare il limite massimo di dimensione consentito per un 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. Non è una buona pratica 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.

Ripristino 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. Scopri di più sull'operazione Annulla.

• 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 vuoi lavorare in isolamento, usa un'area di lavoro separata come ambiente isolato. Leggi di più su come isolare il tuo ambiente di lavoro in lavorare con i branch. 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. Assicurati anche di collegarti alla cartella corretta nel branch, in modo da poter importare nell'area di lavoro il contenuto corretto.

  Note

  Per impostazione predefinita, il passaggio del ramo Git di un'area di lavoro connessa (o il controllo di un nuovo ramo) è limitato agli amministratori dell'area di lavoro. Tuttavia, un amministratore dell'area di lavoro può abilitare l'impostazione per area di lavoro Consenti agli utenti con almeno il ruolo Collaboratore di modificare il ramo Git per delegare le funzionalità di cambio di ramo a Collaboratori o Membri. Per altre informazioni, vedere Consenti ai collaboratori e ai membri di cambiare rami.

• 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, assicurati di aggiornare il tuo branch da main, in modo da poter risolvere prima i conflitti da solo.

• 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. Ricorda che tutto ciò che includi in un commit diventa parte del commit e può finire accidentalmente nel ramo principale.

Usa gli strumenti del client per modificare il tuo 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, VS Code 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. Consideralo come 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 logicalId e/o i nomi visualizzati in eventuali dipendenze.

Procedure consigliate per la fase di test delle pipeline di distribuzione

Questa sezione fornisce indicazioni per lavorare con la 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 le origini dati nella fase di test o parametrizzare la connessione se non si usano le 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. L'operazione di aggiornamento degli elementi di dati è la stessa sia per Git sia per le pipeline di distribuzione.

Poiché i diversi elementi hanno capacità diverse in termini di conservazione dei dati quando vengono applicate modifiche alla definizione, prestare attenzione nell’applicare tali 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. Si spera che i passaggi precedenti ti aiutino a individuarli prima della messa in 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.

Procedure consigliate per la fase di produzione delle pipeline di distribuzione

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 il ruolo di visualizzatore dell'area di lavoro di produzione per visualizzare i contenuti nell'area di lavoro, ma non apportare modifiche da Git o dalle pipeline di distribuzione.

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, implementa sempre la correzione nella fase di sviluppo e propagala nelle restanti 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 lungo tutta la 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

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