Organizzare le soluzioni

Prima di creare soluzioni, dedicare del tempo per pianificare la strategia dell'ambiente e la strategia della soluzione. Considerare gli aspetti seguenti:

Aspetto Considerazione
Ambito dell'applicazione L'implementazione si estende su più applicazioni, ad esempio Sales, Customer Service, Field Service, Finance e così via?
Frequenza di rilascio Con quale frequenza si prevede di distribuire gli aggiornamenti nell'ambiente di produzione?
La metodologia di distribuzione è basata su procedure agile come i cicli sprint?
Supporto per la produzione Come si gestiscono le correzioni urgenti nell'ambiente di produzione senza introdurre prematuramente nuove funzionalità?
Architettura della soluzione Quante soluzioni gestisci?
Queste soluzioni condividono componenti o dipendono l'uno dall'altro?
Pianificazione dell'ambiente Quanti ambienti Microsoft Dataverse sono necessari per supportare il ciclo di vita di sviluppo?
Sono necessari ambienti separati per lo sviluppo, i test e la produzione?
Gli sviluppatori lavorano in modo collaborativo in un ambiente condiviso o richiedono ambienti isolati per funzionare in modo indipendente?

Le sezioni seguenti illustrano tre strategie, disposte dal più semplice al più complesso, evidenziando i rispettivi vantaggi e svantaggi.

Strategia di soluzione singola

Tutte le personalizzazioni vengono raggruppate in una soluzione non gestita durante lo sviluppo, che viene successivamente esportata come singola soluzione gestita per la distribuzione.

Consigliato per:

  • Implementazioni di piccole medie dimensioni
  • Scenari in cui è improbabile la modularizzazione futura
Vantaggio Svantaggio
Configurazione e gestione semplificate dell'ambiente. Richiede maggiore impegno per ridimensionare o modularizzare in un secondo momento, se necessario.
Distribuzione semplificata. Con una sola soluzione da gestire, l'esportazione e l'importazione tra ambienti è semplice e meno soggetta a errori. Una singola soluzione contenente un numero elevato di personalizzazioni potrebbe comportare tempi di distribuzione più lunghi. Per ridurre le dimensioni della soluzione, usare la segmentazione di tabella. Per ridurre i tempi di importazione, passare alle raccomandazioni sulle prestazioni.
Più facile individuare, controllare e gestire le modifiche. Quando più sviluppatori lavorano nello stesso ambiente di sviluppo, rischiano di sovrascrivere le modifiche dell'altro. Questo rischio può essere ridotto implementando il controllo delle versioni del codice sorgente, adottando una strategia di diramazione e usando un ambiente di sviluppo dedicato per ogni ramo. Il controllo delle versioni del codice sorgente e la strategia di diramazione forniscono meccanismi di rilevamento delle modifiche, supporto per la collaborazione e risoluzione dei conflitti. Altre informazioni: Adottare una strategia di diramazione Git.

Nota

I miglioramenti recenti in Microsoft Power Platform hanno ridotto i tempi di importazione per le soluzioni gestite, incluse quelle che usano l'opzione di aggiornamento. Queste ottimizzazioni includono una migliore gestione delle dipendenze dei componenti e un sovraccarico ridotto per i componenti non modificati. Per informazioni su come trarre vantaggio da questi miglioramenti, vedere Raccomandazioni sulle prestazioni.

Più soluzioni all'interno di un singolo ambiente di sviluppo

Più soluzioni non gestite vengono mantenute all'interno di un singolo ambiente di sviluppo, ognuna in genere dedicata a funzionalità o moduli non correlati.

Attenzione

L'uso di più soluzioni in un singolo ambiente può introdurre problemi con la distribuzione in ambienti downstream, inclusi gli ambienti di produzione. Se si sceglie di usare più soluzioni nell'ambiente di sviluppo, comprendere l'importanza di rispettare le linee guida descritte in questa sezione. Per altre informazioni, vedere Informazioni da conoscere prima di usare più soluzioni nello stesso ambiente.

Consigliato per:

  • Implementazioni di piccole e medie dimensioni con aree funzionali distinte e indipendenti che non condividono componenti.
Vantaggio Svantaggio
Configurazione e gestione semplificate dell'ambiente. La gestione di più soluzioni non gestite all'interno dello stesso ambiente di sviluppo aumenta la probabilità di conflitti di dipendenza. Ad esempio, è possibile che si verifichi una situazione in cui la soluzione A non può essere importata perché dipende dalla soluzione B, mentre la soluzione B non può essere importata perché dipende dalla soluzione A.
Le aree funzionali possono essere distribuite in modo indipendente l'una dall'altra. Più sviluppatori che lavorano nello stesso ambiente di sviluppo potrebbero sovrascrivere le modifiche dell'altro. L'uso di una soluzione non gestita non fornisce l'isolamento. Ogni modifica viene applicata direttamente all'ambiente, indipendentemente dalla soluzione da modificare.

Quando si hanno più soluzioni nello stesso ambiente di sviluppo, dopo aver importato le soluzioni gestite nell'ambiente di destinazione, spesso si creano livelli. Per altre informazioni, vedi Livelli di soluzione e comportamento di unione.

Cosa è necessario sapere prima di lavorare con più soluzioni nello stesso ambiente

Seguire queste procedure quando si usano più soluzioni non gestite in un unico ambiente di sviluppo:

  • Usare un solo editore delle soluzioni. L'editore della soluzione è proprietario dei componenti di una soluzione gestita e l'associazione non può essere modificata in un secondo momento. Ad esempio, se si importa una tabella personalizzata come gestita tramite la soluzione A con Publisher X, non è possibile spostarla successivamente nella soluzione B con Publisher Y. L'unica opzione consiste nell'eliminare la tabella, aggiornare la soluzione A per rimuovere la tabella dal sistema di destinazione, quindi ricreare la tabella nella soluzione B con Publisher Y e importare la soluzione B. Questo processo di rimozione comporta la perdita di tutti i dati archiviati nella tabella personalizzata, a meno che i dati non vengano migrati prima.
  • Usare una singola soluzione non gestita nell'ambiente di sviluppo. Se è necessario personalizzare un componente gestito da un'altra soluzione gestita, aggiungere il componente alla soluzione non gestita. Per personalizzare il componente gestito, le proprietà gestite devono essere impostate su personalizzabili. Esportare quindi la soluzione non gestita come gestita per la distribuzione in altri ambienti. Per altre informazioni, vedere Proprietà gestite.
  • Se si usano più soluzioni, non includere lo stesso componente non gestito in più soluzioni.
  • Se si usano più soluzioni, mantenere una sola soluzione che include tutte le tabelle. Non avere due soluzioni differenti in cui entrambe contengano tabelle. Questa condizione esiste per il frequente rischio di una singola relazione tra le tabelle, che crea una dipendenza tra soluzioni e causa l'aggiornamento della soluzione o l'eliminazione di problemi nell'ambiente di destinazione in un secondo momento.
  • Se si usano più soluzioni, evitare di creare dipendenze tra soluzioni. Le dipendenze applicano un ordine di importazione e possono causare problemi. Ad esempio, se è disponibile una soluzione per le tabelle e un'altra per i flussi cloud e un flusso si basa su una colonna personalizzata, funziona in fase di sviluppo perché la colonna esiste. Tuttavia, se si importa solo la soluzione flusso cloud nell'ambiente di destinazione, il processo di importazione potrebbe non riconoscere la dipendenza dalla colonna personalizzata. Di conseguenza, la soluzione di flusso viene installata correttamente, ma il flusso non funziona. Per altre informazioni, vedere Esempi di dipendenze create da più soluzioni.

Cosa evitare quando si usano più soluzioni nello stesso ambiente

Ecco un esempio in cui la piattaforma non consente di disinstallare o aggiornare nessuna delle due soluzioni gestite perché le due soluzioni provenienti da editori diversi tentano di aggiornare lo stesso componente. La situazione:

  • Due soluzioni gestite di editori diversi vengono installate nello stesso ambiente.
  • Almeno un componente (componente 1) è di proprietà di Publisher A, ma esteso da Publisher B. La soluzione di Publisher A è il livello di base per tale componente e la soluzione di Publisher B si trova sopra di esso.
  • Almeno un altro componente (componente 2) è di proprietà di Publisher B ed esteso da Publisher A. Questa condizione è l'inversa del punto elenco precedente.
Livello Componente 1 Componente 2
In alto Soluzione B (Publisher B) Soluzione A (Publisher A)
Base Soluzione A (Publisher A) Soluzione B (Publisher B)

Questo problema si verifica perché presenta una dipendenza circolare per il componente con entrambe le soluzioni e la piattaforma non consente di disinstallare o aggiornare il componente. In questo esempio:

  • Sol A non può essere disinstallato perché è proprietario del componente 1 ed esiste una personalizzazione sovrapposta proveniente da una soluzione appartenente a Publisher B. Per disinstallare Sol A è necessario prima disinstallare Sol B.
  • Sol B non può essere disinstallato perché possiede il componente 2 ed esiste una personalizzazione sovrapposta proveniente da una soluzione appartenente a Publisher A. Per disinstallare Sol B, è prima necessario disinstallare Sol A.

Esempi di dipendenze create da più soluzioni

  • Barre multifunzione dell'applicazione. Quando più soluzioni modificano la barra multifunzione dell'applicazione o la mappa del sito della stessa app.
  • Plugin o flussi cloud. Se il plug-in o il flusso si attiva su una colonna personalizzata o aggiorna una tabella personalizzata, l'oggetto dipende da tali tabelle personalizzate.
  • Ruoli di sicurezza. Quando esistono tabelle personalizzate, i ruoli di sicurezza dipendono in genere da tali tabelle per l'accesso degli utenti.

Più soluzioni con più ambienti di sviluppo dedicati

Questa strategia prevede lo sviluppo di ogni soluzione non gestita nel proprio ambiente di sviluppo dataverse isolato. Questa strategia viene comunemente usata nelle architetture modulari in cui, ad esempio, applicazioni diverse, ad esempio Sales, Customer Service o Field Service, vengono compilate e gestite in modo indipendente. Viene creata e distribuita come soluzione gestita in ogni ambiente di sviluppo specifico dell'app una soluzione di base contenente componenti comuni, ad esempio tabelle di account e contatti. Ogni app ha quindi una propria soluzione non gestita, sovrapposta alla soluzione gestita di base, consentendo ai team di estendere le funzionalità senza modificare le basi di base.

Consigliato per:

  • Progetti aziendali su larga scala.
  • Team con diversi sviluppatori o partner
  • Scenari che necessitano di una rigorosa governance e di pipeline CI/CD.
Vantaggio Svantaggio
È più facile crescere ed evolvere il sistema aggiungendo o aggiornando moduli senza influire sugli altri utenti. Maggiore sovraccarico di infrastruttura e manutenzione.
Più team possono lavorare in parallelo su moduli diversi senza entrare in conflitto con le modifiche apportate dagli altri. Richiede una solida strategia e governance dell'ambiente.
È più semplice implementare procedure automatizzate di test e DevOps. Distribuzione più complessa.
Le soluzioni più piccole sono più veloci da distribuire, soprattutto nelle pipeline CI/CD se è necessario distribuire solo un'app specifica.
I bug o le regressioni sono più facili da tracciare quando le modifiche sono isolate in moduli specifici.

Come costruire la stratificazione della tua soluzione

Nota

Prima di creare le soluzioni nei passaggi seguenti, utilizza lo stesso editore per tutte le soluzioni nei tuoi ambienti. Ulteriori informazioni: Autore di soluzioni

  1. Nell'ambiente di sviluppo "base" è disponibile la soluzione di base con le tabelle non gestite comuni e nessun'altra tabella. Esportare quindi questa soluzione come gestita.
  2. Si configura un secondo ambiente di sviluppo per l'estensione o il livello "app" che si troverà successivamente sopra il livello di base.
  3. Si importa il livello di base gestito nell'ambiente di sviluppo a livello di app e si crea una soluzione non gestita per il livello dell'app. Sovrapposizione di soluzioni appropriata che utilizza molteplici soluzioni con più ambienti.
  4. È ora possibile estendere il modello di dati aggiungendo tabelle, colonne, relazioni tra tabelle, plug-in, flussi e così via, alla soluzione "app" specifica. Quindi esporta la soluzione app come gestita. Si noti che la soluzione dell'app dipende ancora dalla soluzione di livello di base, ma la gestione di più soluzioni in questo modo è un approccio migliore. Si consideri l'esempio indicato prima del flusso che si basa su una colonna personalizzata. Nella maggior parte dei casi, sia la colonna personalizzata che il flusso si trovano nella stessa soluzione dell'app. Tuttavia, anche se la colonna personalizzata fa parte della soluzione di base, è necessario completare e distribuire la soluzione di base come gestita per prima, in caso contrario, il flusso all'interno della soluzione app non può nemmeno essere creato.
  5. Nell'ambiente di produzione, importi il layer di base gestito e quindi importi il layer app gestito. In questo modo vengono creati due livelli gestiti nell'ambiente con dipendenze chiare tra le soluzioni gestite.
  6. Ripeti questo schema per avere tutte le differenti soluzioni che devi gestire. Tuttavia ti consigliamo di mantenere il numero di soluzioni il più basso possibile per mantenere gestibile la sovrapposizione delle soluzioni.

Usare la segmentazione di tabella
Scenario 5: supportare lo sviluppo in team

  • Ultimo aggiornamento: