Pianificazione dell'implementazione di Power BI: Pianificare e progettare contenuto

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo illustra come pianificare e progettare il contenuto come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Centro di eccellenza (COE) e team bi: i team responsabili della supervisione di Power BI nell'organizzazione. Questi team includono decision maker che decidono come gestire il ciclo di vita del contenuto di Power BI.
• Autori di contenuti e proprietari di contenuti: utenti che creano contenuti che vogliono pubblicare nel portale di Fabric per condividerli con altri utenti. Questi utenti sono responsabili della gestione del ciclo di vita del contenuto di Power BI creato.

La gestione del ciclo di vita è costituita dai processi e dalle procedure usate per gestire il contenuto dalla creazione al ritiro finale. Come descritto nel primo articolo di questa serie, la gestione del ciclo di vita del contenuto di Power BI è importante per garantire la distribuzione affidabile e coerente del contenuto agli utenti aziendali.

La prima fase del ciclo di vita del contenuto consiste nel pianificare e progettare il contenuto. In genere si avvia il ciclo di vita del contenuto eseguendo la pianificazione della soluzione BI. Si raccolgono i requisiti per comprendere e definire il problema che la soluzione deve affrontare e arrivare alla progettazione di una soluzione. Durante questa fase di pianificazione e progettazione, si prendere decisioni chiave per prepararsi per le fasi successive.

L'immagine seguente illustra il ciclo di vita del contenuto di Power BI, evidenziando la fase 1, in cui si pianifica e progetta il contenuto.

Nota

Per una panoramica della gestione del ciclo di vita dei contenuti, vedere il primo articolo di questa serie.

Suggerimento

Questo articolo è incentrato sulle considerazioni e sulle decisioni principali per la pianificazione e la progettazione dei contenuti in quanto riguardano la gestione del ciclo di vita.

• Per altre informazioni su come pianificare e progettare in modo efficace una soluzione Fabric o Power BI, è consigliabile leggere l'articolo sulla pianificazione della soluzione.
• Per altre informazioni su come pianificare in modo efficace una migrazione di Power BI, è consigliabile leggere la serie di migrazione di Power BI.

Quando si raccolgono i requisiti, è necessario descrivere chiaramente gli aspetti relativi al contenuto che influiscono sull'approccio alla gestione del ciclo di vita. È consigliabile documentare questi aspetti come parte della pianificazione e della progettazione della soluzione.

Le sezioni seguenti di questo articolo descrivono gli aspetti chiave e le considerazioni di una soluzione che motivano l'approccio alla gestione del ciclo di vita durante la pianificazione e la progettazione del contenuto.

Identificare e descrivere il contenuto

Quando si progetta la soluzione, è necessario descrivere il contenuto, chi lo creerà, chi lo supporterà e quanto sia critico questo contenuto per l'organizzazione. È consigliabile affrontare questi fattori durante o dopo aver completato la raccolta dei requisiti come parte della progettazione della soluzione.

Nota

Analogamente ai requisiti, le risposte a queste domande possono cambiare man mano che si sviluppa la soluzione o in un secondo momento nel ciclo di vita. Dopo aver risposto a queste domande, essere pronti a rivalutarli periodicamente quando si apportano modifiche al contenuto o quando aumenta il numero di utenti usati.

Rispondere alle domande seguenti sul contenuto per prendere decisioni successive sulla gestione del ciclo di vita.

Qual è il formato del contenuto?

Il tipo, l'ambito e la complessità del contenuto motivano le decisioni chiave su come gestirlo. Ad esempio, un singolo report per un gruppo di destinatari limitato richiede un approccio diverso per la gestione del ciclo di vita rispetto a un modello semantico che verrà usato dall'intera organizzazione e da più carichi di lavoro downstream diversi.

Rispondere a domande come le seguenti per determinare il tipo di contenuto che verrà creato.

• Quali tipi di elemento si prevede di creare e quanti di ognuno di essi? Ad esempio, si creeranno elementi di dati come flussi di dati o modelli semantici, elementi di report come report o dashboard o una combinazione di entrambi?
• In che modo il contenuto viene distribuito ai consumer di contenuti? Ad esempio, i consumer useranno gli elementi di dati per creare il proprio contenuto, visualizzeranno solo report centralizzati o una combinazione di entrambi?
• Quanto è complesso il contenuto? Ad esempio, è un piccolo prototipo o un modello semantico di grandi dimensioni che comprende più processi aziendali?
• Si prevede che la scalabilità, l'ambito e la complessità del contenuto aumentano nel tempo? Ad esempio, il contenuto comprenderà altre aree geografiche o aree aziendali in futuro?
• Quanto tempo si prevede che l'azienda richieda questo contenuto? Ad esempio, questo contenuto supporterà un'iniziativa chiave dell'azienda con una sequenza temporale limitata?

Suggerimento

Prendere in considerazione la possibilità di creare un diagramma dell'architettura per descrivere il formato del contenuto. È possibile includere origini dati, tipi di elementi e consumer di contenuto diversi e le relazioni tra questi componenti discreti. Un diagramma dell'architettura può essere utile per descrivere in modo conciso il contenuto e la sua complessità e consente di pianificare la gestione del ciclo di vita. È possibile usare le icone dell'infrastruttura e le icone di Azure per creare questi diagrammi in software esterno. In alternativa, è possibile usare diagrammi di Azure, forniti con icone e strumenti di disegno per creare questi diagrammi.

Per un esempio di questi diagrammi, vedere i diagrammi dello scenario di utilizzo della pianificazione dell'implementazione di Power BI.

Chi creerà e supporterà il contenuto?

Gli autori di contenuti hanno esigenze, competenze e flussi di lavoro diversi. Questi fattori influenzeranno il successo di diversi approcci di gestione del ciclo di vita. I team più grandi e centrali con la collaborazione spesso richiedono una gestione più sofisticata del ciclo di vita dei contenuti rispetto ai team più piccoli di autori self-service.

Rispondere a domande come le seguenti per determinare chi creerà o supporterà il contenuto.

• Quante persone diverse si prevede di creare questo contenuto? Più creatori di contenuti collaborano o è un singolo responsabile della creazione del contenuto?
• Gli autori di contenuti hanno familiarità con la gestione del ciclo di vita e i concetti correlati, ad esempio il controllo della versione? Gli autori di contenuti comprendono i vantaggi della gestione del ciclo di vita?
• I creatori di contenuti che sviluppano la soluzione saranno gli stessi utenti che lo supportano dopo la distribuzione?
• Gli autori di contenuti o i loro team dispongono di procedure di gestione del ciclo di vita esistenti per supportare le soluzioni esistenti?
• Gli autori di contenuti usano attualmente strumenti di gestione del ciclo di vita come Azure DevOps?

Importante

Assicurarsi di documentare chiaramente chi è responsabile della creazione di contenuto e chi lo supporterà dopo la distribuzione nell'ambiente di produzione. Coinvolgere tutti questi utenti nella pianificazione della gestione del ciclo di vita dei contenuti.

Qual è l'importanza del contenuto?

A seconda dell'importanza del contenuto per l'azienda, verranno prese decisioni diverse su come gestirlo. I contenuti critici per l'azienda richiedono approcci più affidabili per la gestione del ciclo di vita dei contenuti per salvaguardare la qualità e ridurre le possibili interruzioni.

Rispondere a domande come le seguenti per determinare se il contenuto è critico.

• Quanto è fondamentale questo contenuto per l'azienda? Quanto è urgente la richiesta di svilupparla?
• Le decisioni o le azioni critiche per l'azienda verranno prese dalle informazioni fornite da questo contenuto?
• In che misura si prevede di distribuire questo contenuto a livello di organizzazione a un team locale limitato?
• I dirigenti o altri decision maker strategici si affidano a questo contenuto per il loro lavoro?
• Qual è l'impatto di questo contenuto? Ad esempio, se il contenuto non è improvvisamente disponibile, quali effetti aziendali potrebbero verificarsi, ad esempio ricavi persi o processi aziendali interrotti?

Dopo aver identificato e descritto in modo sufficiente il contenuto che si creerà, è necessario decidere in che modo gli autori di contenuti devono collaborare.

Decidere in che modo gli autori di contenuti devono collaborare

Man mano che una soluzione aumenta nell'ambito e nella complessità, potrebbe essere necessario che più creatori di contenuti e proprietari lavorino in collaborazione. Quando si creano soluzioni complesse, è consigliabile usare strumenti efficaci che consentono di strutturare, gestire e supportare la collaborazione. Esistono molti modi per collaborare quando si produce contenuto di Power BI, ad esempio usando Microsoft Teams o Azure DevOps.

Suggerimento

Anche quando i creatori di contenuti lavorano in modo indipendente, possono comunque trarre vantaggio dalla pianificazione e dalla strutturazione del lavoro usando strumenti come Microsoft Teams e Azure DevOps.

Microsoft Teams

Per progetti più piccoli o più semplici, gli autori di contenuti possono collaborare usando Microsoft Teams.

Usando Microsoft Teams, gli autori di contenuti strutturano la comunicazione, la pianificazione e il lavoro in team e canali. Microsoft Teams è spesso una scelta ottimale per scenari di collaborazione più semplici. Ad esempio, i team decentralizzati che producono contenuto per un pubblico limitato possono usare raccolte documenti per archiviare file e controllo della versione. Possono anche usare altri strumenti e servizi integrati.

Suggerimento

È consigliabile usare Microsoft Teams per facilitare una gestione efficace del ciclo di vita dei contenuti in scenari self-service con distribuzione decentralizzata dei contenuti.

Per collaborare e comunicare in Microsoft Teams, è possibile usare i servizi di supporto per tutto il ciclo di vita del contenuto di Power BI.

• Planner: i proprietari di contenuti possono usare Planner per creare piani, che usano per tenere traccia delle attività e definire l'ambito del lavoro del contenuto. Le attività possono descrivere problemi, bug o funzionalità nella soluzione e gli stakeholder corrispondenti.
• SharePoint: gli autori di contenuti possono archiviare e gestire i file in una raccolta documenti di Microsoft Teams o in un sito connesso per ogni canale. I file di contenuto archiviati in SharePoint possono usare il controllo della versione per tenere traccia e gestire le modifiche del contenuto. Per altre informazioni sul rilevamento e la gestione delle modifiche tramite SharePoint, vedere Fase 2: Sviluppare contenuto e gestire le modifiche.
• Approvazioni: gli autori e i proprietari di contenuti possono configurare e usare flussi di lavoro per approvare le modifiche o le versioni del contenuto dopo la revisione.
• Infrastruttura e Power BI: autori e proprietari di contenuti possono accedere al portale di Fabric da Microsoft Teams. Da qui possono gestire o discutere il contenuto e aggiungere report utili alle schede nei canali di Teams.
• Altre integrazioni: gli autori di contenuti possono usare altri servizi Microsoft o di terze parti che si integrano con Microsoft Teams per soddisfare al meglio il flusso di lavoro e le esigenze preferite.

È consigliabile definire un processo strutturato per il modo in cui gli autori di contenuti devono usare Microsoft Teams per collaborare. Assicurarsi di determinare:

• Come gestire l'accesso a team e canali.
• Responsabile della gestione di team e canali.
• L'ambito e l'organizzazione del lavoro in team, canali e piani distinti.
• Come gli autori di contenuti devono usare una raccolta documenti per organizzare i file e tenere traccia e gestire le modifiche. Ad esempio, come organizzare la raccolta documenti e se gli autori di contenuti devono archiviare e archiviare i file.
• Indica se gli autori di contenuti devono usare l'aggiornamento di OneDrive per pubblicare automaticamente i file di Power BI Desktop (con estensione pbix).
• Come vengono risolti i conflitti di sincronizzazione file.
• Quando archiviare e rimuovere file da una raccolta documenti che non sono più rilevanti.

Azure DevOps

Gli autori di contenuti e i proprietari possono anche comunicare e collaborare in un hub centrale organizzato usando Azure DevOps.

Nota

Azure DevOps è una suite di servizi che si integrano con Power BI e Fabric per pianificare e orchestrare la gestione del ciclo di vita dei contenuti. Quando si usa Azure DevOps in questo modo, si sfruttano in genere i servizi seguenti:

• Azure Repos: consente di creare e usare un repository Git remoto, ovvero un percorso di archiviazione remoto usato per tenere traccia e gestire le modifiche del contenuto.
• Azure Pipelines: consente di creare e usare un set di attività automatizzate per gestire, testare e distribuire contenuto da un repository remoto a un'area di lavoro.
• Piani di test di Azure: consente di progettare test per convalidare la soluzione e automatizzare il controllo della qualità insieme ad Azure Pipelines.
• Azure Boards: consente di usare le bacheche per tenere traccia delle attività e dei piani come elementi di lavoro e collegare o fare riferimento agli elementi di lavoro di altri servizi Di Azure DevOps.
• Wiki di Azure: consente di condividere informazioni con il proprio team per comprendere e contribuire al contenuto.

Usando Azure DevOps, gli autori di contenuti usano progetti per strutturare le comunicazioni, la pianificazione e il lavoro. Inoltre, gli autori di contenuti possono orchestrare la gestione del ciclo di vita dei contenuti da Azure DevOps eseguendo il controllo del codice sorgente, la convalida e la distribuzione. Il controllo del codice sorgente è il processo di gestione di modifiche più granulari al codice e ai metadati del contenuto.

Azure DevOps è spesso una scelta ottimale per scenari di collaborazione più avanzati, perché sono disponibili servizi di supporto e opzioni per orchestrare la creazione e la distribuzione dei contenuti.

Suggerimento

È consigliabile usare Azure DevOps per facilitare una gestione efficace del ciclo di vita dei contenuti in scenari aziendali con distribuzione centralizzata dei contenuti. La collaborazione tramite Azure DevOps o strumenti simili è preferibile in scenari più grandi o più complessi rispetto alla collaborazione tramite Microsoft Teams o SharePoint. Ciò è dovuto al fatto che sono disponibili più strumenti e opzioni per facilitare una collaborazione e un'automazione più affidabili.

È consigliabile definire un processo strutturato per il modo in cui gli autori di contenuti devono usare Azure DevOps per collaborare. Assicurarsi di determinare:

• Come vengono definiti l'ambito e il modo in cui vengono creati, denominati e usati i rami di contenuto.
• Come gli autori raggruppano e eseguono il commit delle modifiche e li descrivono con i messaggi di commit.
• Chi è responsabile della revisione e dell'approvazione delle modifiche usando le richieste pull.
• Come eseguire il pull dei conflitti di merge delle richieste vengono risolti e gli utenti che li risolvono.
• Modalità di unione delle modifiche apportate in rami diversi in un singolo ramo.
• Come viene testato il contenuto e chi esegue test prima della distribuzione del contenuto.
• Come e quando le modifiche vengono distribuite nelle aree di lavoro di sviluppo, test e produzione.
• Come e quando è possibile eseguire il rollback delle modifiche o delle versioni della soluzione distribuite.

Nota

È anche possibile usare Microsoft Teams insieme ad Azure DevOps perché esistono diversi modi per integrare questi servizi. Ad esempio, è possibile visualizzare e gestire Azure Boards e monitorare gli eventi in Azure Pipelines da Microsoft Teams.

La cosa più importante è che si usano strumenti e servizi che facilitano la collaborazione per l'utente e che meglio si adattano alle esigenze del team e al modo in cui lavorano.

Quando hai deciso se e come i creatori di contenuti devono collaborare, dovresti decidere dove archiviare i tuoi file. Molti di questi file verranno archiviati in cui si sceglie di collaborare.

Decidere dove archiviare i file

Quando si crea contenuto, in genere si producono tipi diversi di file. È importante decidere dove archiviare questi file in modo da poterli gestire in modo efficace.

Suggerimento

Archiviare i file a cui possono accedere più membri del team e dove è possibile tenere traccia delle modifiche (noto come controllo della versione). Questo approccio garantisce che la partenza di un membro del team o la perdita di un file non comporti interruzioni.

I tipi di file da archiviare spesso includono:

• File di contenuto: file che contengono i dati o i metadati del contenuto. I file di contenuto con dati come pbix e i file di progetto Power BI (con estensione pbip) contengono informazioni riservate. Archiviare i file di contenuto in una posizione sicura accessibile solo da coloro che devono accedervi. È anche consigliabile archiviare i file di contenuto in un percorso che supporta il controllo della versione, ad esempio una raccolta documenti in Microsoft Teams o un repository Git in Azure DevOps. Esempi di file di contenuto includono:
  • File di Power BI Desktop (con estensione pbix)
  • File di progetto power BI (con estensione pbip)
  • File di report impaginati di Power BI (con estensione rdl)
  • File di metadati del modello (con estensione bim o TMDL)
  • File di metadati del flusso di dati (.json)
• File di origine dati: file utilizzati da elementi di dati come modelli semantici o flussi di dati. Il contenuto dipende direttamente dai file dell'origine dati, quindi è importante considerare attentamente dove vengono archiviati perché la loro rimozione comporterà un errore di aggiornamento dei dati. Inoltre, questi file potrebbero contenere informazioni riservate. Archiviare quindi i file di origine dati in un ambiente sicuro, affidabile e affidabile con accesso limitato da parte di altri utenti. Esempi di file di origine dati possono includere:
  • Origini dati strutturate, ad esempio cartelle di lavoro di Excel, Parquet o FILE CSV.
  • Origini dati semistrutturate, ad esempio file JSON o XML.
  • Origini dati non strutturate, ad esempio immagini importate nei report.
• File di supporto: file che supportano la creazione o la gestione del contenuto, ma non sono necessari per il funzionamento. I file di supporto devono essere archiviati in un percorso che supporta il controllo della versione e dove altri strumenti e creatori di contenuti possono accedervi. Esempi di file di supporto possono includere:
  • File best practice analyzer rules (.json).
  • File del tema (.json) di Power BI.
  • File di codice sorgente per contenuto e query.
  • File di visualizzazione personalizzata (con estensione pbiviz).
• Modelli e documentazione: file che facilitano la creazione di contenuto self-service o descrivono il contenuto esistente. I modelli e la documentazione devono essere facilmente accessibili dalle persone che devono usarli. Esempi di modelli e documentazione possono includere:
  • File modello di Power BI (con estensione pbit).
  • Modelli di visualizzazione e report di esempio.
  • Progetti e documentazione della soluzione.
  • Pianificazione e roadmap della soluzione.
  • Richieste utente e problemi di soluzione.

Attenzione

Alcuni file di contenuto come i file con estensione pbix e pbip possono contenere dati sensibili importati da origini dati. Inoltre, anche i file di metadati come i file TMDL o pbit possono contenere informazioni riservate. Assicurarsi di adottare le precauzioni necessarie per archiviare questi file in posizioni sicure e di praticare una prevenzione efficace della perdita dei dati.

Sono disponibili diverse opzioni per archiviare i file. Assicurarsi di selezionare il percorso appropriato, a seconda del tipo di file, del relativo contenuto e della modalità di utilizzo.

SharePoint Online o OneDrive

Una soluzione comune per l'archiviazione dei file consiste nell'usare i siti di SharePoint . SharePoint è ampiamente accessibile per la maggior parte degli utenti e altamente integrato con Power BI e altre applicazioni di Microsoft 365, come Microsoft Teams. Inoltre, dispone di un controllo della versione predefinito, che consente di archiviare la maggior parte dei tipi di file. Il controllo della versione consente di visualizzare e gestire versioni salvate diverse di un file.

Quando si archiviano file in SharePoint, prendere in considerazione i punti seguenti.

• Organizzazione: assicurarsi di mantenere una struttura coerente e logica in modo che sia semplice trovare file specifici. Usare convenzioni di denominazione valide, organizzare i file in cartelle e archiviare file che non sono più rilevanti per i progetti in corso.
• Aggiornamento di OneDrive: è possibile collegare un modello semantico pubblicato o un report a un file con estensione pbix archiviato in un sito di SharePoint o OneDrive for Business (noto anche come Sito aziendale o dell'istituto di istruzione). Con questo approccio non è più necessario pubblicare il modello semantico per rendere effettive le modifiche. Le modifiche sono invece visibili dopo un aggiornamento automatico di OneDrive, che si verifica ogni ora. Anche se conveniente, tenere presente che questo approccio presenta alcune avvertenze e sfide. Quando le cose vanno, non può essere facilmente invertito.
• Report di anteprima: in SharePoint è possibile visualizzare i report di Power BI senza dover installare Power BI Desktop o scaricare il file con estensione pbix in locale. Quando si aprono i report in questo modo, vengono visualizzati nel browser. Questa funzionalità può essere un'alternativa pratica alla visualizzazione dei report dal portale di Fabric. È abilitata per impostazione predefinita nelle impostazioni del tenant di Fabric.

Suggerimento

Quando si collabora usando Microsoft Teams, è consigliabile archiviare i file nella raccolta documenti del canale. Questo approccio consente di centralizzare i file e facilitare la collaborazione.

È consigliabile archiviare i tipi di file seguenti in SharePoint.

• Modelli e documentazione: archiviare modelli e documentazione in SharePoint quando non si dispone di una soluzione di archiviazione esistente. SharePoint è ideale per questi file perché è possibile concedere l'accesso ad altri e gestire i file senza operazioni di installazione o processi complessi.
• File di supporto: archiviare i file di supporto in SharePoint quando non si dispone di una soluzione di archiviazione esistente. Tuttavia, alcuni file di supporto,ad esempio il tema di Power BI .json file per i report, potrebbero essere archiviati meglio in un sistema di controllo della versione che consente di visualizzare e gestire le modifiche salvate.
• File di contenuto: archiviare il contenuto in SharePoint quando non è fondamentale per l'azienda o quando non si ha accesso a un repository remoto come Azure Repos.
• Origini dati: archiviare le origini dati in SharePoint solo quando sono di piccole dimensioni e complessità. Esercizio disciplina quando si usa SharePoint per archiviare i file di origine dati. Prendere in considerazione altre possibili alternative, ad esempio OneLake.

Attenzione

Non usare SharePoint come alternativa a un'architettura di dati appropriata. Anche se l'archiviazione di file di origine dati in SharePoint può risultare utile in alcuni scenari limitati, questo approccio non viene ridimensionato quando si dispone di origini dati più grandi, più complesse o quando è necessaria una latenza dei dati inferiore.

Avviso

Non usare file system personali o account OneDrive personali per archiviare i file. Se il proprietario lascia l'organizzazione, questi file non saranno più disponibili.

OneLake

Se si ha una capacità fabric, OneLake può essere una buona scelta per archiviare i file di origine dati. È possibile caricare o sincronizzare i file in OneLake usando OneLake Esplora file, in cui possono essere trasformati in tabelle da usare in carichi di lavoro downstream come Power BI. Per origini dati più grandi o aggiornate regolarmente, è possibile caricare automaticamente i file in OneLake usando Fabric Data Factory o altre applicazioni che usano l'APIAzure Data Lake Archiviazione (ADLS) Gen2 o python SDK Archiviazione di Azure.

Attenzione

Azioni come il caricamento o il download di file da OneLake usano unità di capacità di Fabric. È consigliabile monitorare le metriche della capacità e adottare misure per evitare il sovraccarico della capacità causato da spostamenti non necessari di file di grandi dimensioni.

Inoltre, i file a cui accedono gli utenti con OneLake Esplora file sono vulnerabili a modifiche o perdite accidentali. È consigliabile evitare di usare OneLake Esplora file per soluzioni critiche per l'azienda.

Avviso

OneLake Esplora file presenta diverse importanti limitazioni e considerazioni. Ad esempio, OneLake non supporta il controllo della versione per i file, ad esempio SharePoint o OneDrive. Prendere in considerazione queste considerazioni e limitazioni quando si decide dove archiviare i file.

Suggerimento

Quando si archiviano dati in OneLake, è consigliabile abilitare continuità aziendale e ripristino di emergenza (BCDR) per ridurre il rischio di perdita di dati. Con bcdr abilitato, i dati vengono duplicati e archiviati in due aree geografiche diverse, in base alle associazioni di aree standard di Azure.

Repository remoto

Gli autori di contenuti possono eseguire il commit e salvare il lavoro dal computer locale in un repository remoto, ad esempio un repository Git Azure Repos, a intervalli regolari durante lo sviluppo. Un repository remoto contiene la versione più recente della soluzione ed è accessibile dall'intero team di sviluppo. In genere, un repository remoto semplifica approcci di gestione del ciclo di vita più avanzati rispetto all'uso di Teams, SharePoint o OneDrive. Questo perché usando un repository remoto, gli autori di contenuti possono trarre vantaggio da opzioni più sofisticate per collaborare ai file o tenere traccia e gestire le modifiche dei file. Ad esempio, gli autori di contenuti possono lavorare nel proprio ramo del repository remoto per apportare modifiche e richiedere di unire tali modifiche nel ramo principale quando sono pronte.

Prendere in considerazione l'archiviazione dei tipi di file seguenti in un repository remoto.

• Modelli e documentazione: archiviare modelli e documentazione in un repository remoto quando si gestisce il progetto con servizi correlati come Azure DevOps.
• File di supporto: archiviare i file di supporto in un repository remoto quando ne è disponibile uno per tenere traccia e gestire facilmente le modifiche.
• File di contenuto: archiviare il contenuto in un repository remoto quando è fondamentale per l'azienda o si intende collaborare con altri sviluppatori nello stesso contenuto. Un repository remoto è ideale per tenere traccia delle modifiche del contenuto e facilitare la collaborazione.

Suggerimento

Quando si usa un repository remoto, è consigliabile archiviare report e modelli semantici di Power BI come file di power BI Desktop (con estensione pbip) anziché file con estensione pbix. Ciò è dovuto al fatto che le modifiche salvate non possono essere identificate in un file con estensione pbix.

Nessun file: contenuto creato nel portale di Fabric

Gli autori di contenuti possono creare contenuti direttamente nel portale di Fabric. In questo scenario, in genere non funzionano direttamente con i file di contenuto. In genere è consigliabile creare contenuto nel portale di Fabric solo quando i tipi di elemento non possono essere creati altrove (ad esempio flussi di dati, dashboard o scorecard). È anche possibile creare report e modelli semantici nel portale di Fabric quando non hanno accesso a un computer Windows e pertanto non possono usare Power BI Desktop. Per altre informazioni, vedere Strumenti e dispositivi utente.

Attenzione

Non è possibile scaricare come file alcuni contenuti creati nel portale di Fabric. Ad esempio, i report creati nel portale di Fabric non possono essere scaricati come file con estensione pbix.

Quando si crea contenuto nel portale di Fabric, è consigliabile usare invece le API fabric o l'integrazione Git per eseguire il backup delle definizioni di contenuto. Quando si esegue il backup delle definizioni di contenuto, si riduce l'interruzione se il contenuto viene eliminato accidentalmente o modificato involontariamente. Se il contenuto viene eliminato o modificato accidentalmente, è possibile sostituirlo usando il backup.

Elenco di controllo : durante la pianificazione e la progettazione di contenuti, le decisioni chiave e le azioni includono:

• Eseguire la pianificazione della soluzione: raccogliere i requisiti aziendali e i requisiti tecnici per comprendere sufficientemente il problema che il contenuto risolverà e progettare il modo in cui il contenuto risolverà il problema.
• Identificare chi creerà il contenuto: a seconda del flusso di lavoro, delle competenze e delle esigenze del singolo creatore di contenuti, potrebbero essere necessari approcci diversi alla gestione del ciclo di vita.
• Identificare se più creatori di contenuti devono collaborare: assicurarsi che i creatori di contenuti che collaborano usino tipi di file che supportano il controllo della versione, ad esempio i file con estensione pbip.
• Decidere in che modo i creatori di contenuti collaboreranno: decidere quanto sofisticata sarà la collaborazione. Inoltre, decidere come facilitare questa collaborazione, ad esempio usando Microsoft Teams o Azure DevOps.
• Configurare gli strumenti di collaborazione: assicurarsi di eseguire la configurazione necessaria per la prima volta per la soluzione o il progetto. Prendere decisioni chiave su come gestire la collaborazione usando questi strumenti.
• Archiviare file di origine dati in SharePoint o OneLake: archiviare file di origine dati di piccole dimensioni e semplici in SharePoint. In caso contrario, usare OneLake o ADLSGen2 (se disponibili).
• Archiviare il contenuto e i file di supporto in SharePoint o in un repository remoto: per progetti più semplici e più piccoli, usare SharePoint per la maggior parte dei file se è organizzato e si consiglia una buona gestione degli accessi. Per ambienti più grandi o quando è necessaria la collaborazione parallela, è consigliabile usare un repository remoto, che fornirà visibilità dettagliata delle modifiche al contenuto.
• Archiviare modelli e documentazione in SharePoint: assicurarsi che i modelli e la documentazione siano facili da trovare, usare e comprendere.
• Pianificare lo sviluppo e la distribuzione: per concludere questa prima fase, eseguire una pianificazione specifica per gestire le aree chiave e condurre la configurazione iniziale. Ad esempio, stabilire strumenti e testare le connessioni all'origine dati.

Contenuto correlato

Nell'articolo successivo di questa serie viene illustrato come sviluppare contenuto e gestire le modifiche nell'ambito della gestione del ciclo di vita del contenuto.