Leggere in inglese

Condividi tramite


Gestione di un'istanza integra di ALM per moduli di app basate su modello

Questo articolo fornisce informazioni sui vari scenari relativi all'implementazione e all'uso di un'di un'istanza integra della gestione del ciclo di vita delle applicazioni (ALM) per la personalizzazione dei moduli nelle soluzioni di app basate su modello.

Le sezioni seguenti descrivono come funziona l'unione dei moduli e come gestire le personalizzazioni. Gli scenari di sviluppo di base con suggerimenti per gestire correttamente ALM per un modulo di app basate su modello sono trattati in dettaglio in ogni sezione che segue. Ogni scenario include passaggi da seguire che possono aiutarti a implementare un processo ALM appropriato durante l'aggiornamento della soluzione o dell'app basata su modello.

Creare un nuovo modulo e gestirlo utilizzando più soluzioni gestite

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. Crea un nuovo modulo denominato ModuloA nell'ambiente di sviluppo e personalizzalo.
  2. Crea una nuova soluzione (denominata Soluzione A nel diagramma sottostante) nell'ambiente di sviluppo, che sarà una soluzione non gestita, e aggiungi il nuovo modulo. Esporta la soluzione come gestita. Questo passaggio esporta un FormXml completo per il modulo.
  3. Nell'ambiente di test, importa la soluzione gestita del passaggio 2, che crea ModuloA nell'ambiente di test. Nel diagramma sottostante, ModuloA viene creato nell'ambiente di test e l'interfaccia utente per il modulo mostra Campo1 e Campo2 che Soluzione A ha aggiunto al modulo.
  4. Quando personalizzi ulteriormente il modulo creato nel passaggio 1 utilizzando un nuovo ambiente di sviluppo (di origine), importa la Soluzione A gestita creata nel passaggio 2, assicurati che per l'istanza di sviluppo lo stato di ModuloA sia gestito. Come mostrato nello schema sottostante, la Soluzione A gestita viene importata nell'ambiente di sviluppo e il modulo viene personalizzato creando personalizzazioni attive. Il ModuloA può quindi essere aggiunto a una nuova soluzione non gestita (Soluzione B nel diagramma) ed esportato come soluzione gestita dall'ambiente di sviluppo. Questo passaggio esporta un FormXml differenziale (diff) per il modulo.
  5. Nell'ambiente di test, importa la soluzione gestita (Soluzione B) del punto 4. Come mostrato nel diagramma sottostante Soluzione B sta aggiungendo un nuovo Campo3 a ModuloA e rimuovendo Campo2, aggiunto da Soluzione A . Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Campo3 e Campo1 nel modulo ma non Campo2 dopo l'unione.

Diagramma ALM del modulo dello scenario 1.

Esempio non integro per questo scenario

Come mostrato nel diagramma seguente, non è una pratica ALM integra creare più soluzioni gestite dall'ambiente di sviluppo in cui la soluzione di base (Soluzione A) è in uno stato non gestito. Questo perché, quando crei un'altra soluzione non gestita (Soluzione B) per il modulo non gestito, il FormXml viene esportato come FormXml completo e non come FormXml diff come mostrato nello scenario valido sopra. Successivamente, le modifiche come la rimozione di una colonna non saranno effettive.

Esempio di istanza ALM non integra per moduli per questo scenario.

Creare un nuovo modulo ed effettuare personalizzazioni utilizzando patch e aggiornamenti

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. Crea un nuovo modulo denominato ModuloA nell'ambiente di sviluppo e personalizzalo.

  2. Crea una soluzione (Soluzione A nel diagramma sottostante) che sarà una soluzione non gestita, e aggiungi il nuovo modulo. Esporta la soluzione come gestita. Questo passaggio esporta un FormXml completo per il modulo.

  3. Nell'ambiente di test, importa la soluzione gestita del passaggio 2, che crea il modulo nell'ambiente di test. Nel diagramma sottostante, ModuloA viene creato nell'ambiente di test e l'interfaccia utente per il modulo mostra Campo1 e Campo2 che Soluzione A ha aggiunto al modulo.

  4. Quando personalizzi ulteriormente il modulo creato nel passaggio 1 utilizzando le patch, utilizza lo stesso ambiente in cui Soluzione A è in uno stato non gestito e crea una patch per la soluzione e personalizza il modulo. Quindi, esporta la patch come soluzione gestita. Questo passaggio esporta un FormXml completo per il modulo.

  5. Nell'ambiente di test, importa la soluzione con patch gestita del punto 4. Come mostrato nel diagramma sottostante, la patch della Soluzione A sta aggiungendo un nuovo Campo3 al ModuloA e rimuovendo Campo2, aggiunto da Soluzione A.

    Nota

    Le patch contenenti il formXml completo vengono sempre confrontate con il livello di base da cui è stata creata la patch e ignorano eventuali patch intermedie tra la base e la patch corrente. Di conseguenza, il Campo2 viene rimosso poiché esiste nel livello di base Soluzione A e la rimozione viene rilevata. D'altro canto, Campo3 viene aggiunto da questa soluzione di patch e non può essere rimosso da patch successive. Pertanto, i campi aggiunti tramite soluzioni di patch sono di natura additiva.

  6. Quando personalizzi ulteriormente il modulo creato nel passaggio 1 utilizzando gli aggiornamenti, utilizza lo stesso ambiente in cui Soluzione A è in uno stato non gestito e clona Soluzione A per creare una soluzione di aggiornamento e personalizzare il modulo. Esporta quindi l'aggiornamento della Soluzione A come soluzione gestita. Questo passaggio esporta un FormXml completo per il modulo.

  7. Nell'ambiente di test, importa l'aggiornamento della Soluzione A gestito del punto 6. Come mostrato nel diagramma sottostante l'aggiornamento della Soluzione A sta aggiungendo un nuovo Campo4 a ModuloA e rimuovendo Campo2, aggiunto da Soluzione A. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Campo1, Campo3 e Campo4 nel modulo ma Campo2 verrà rimosso dall'importazione dopo l'unione del modulo.

Diagramma ALM del modolo dello scenario 2.

Personalizzare un modulo gestito esistente e gestirlo utilizzando molteplici soluzioni gestite

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. Modifica un modulo gestito esistente, denominato ModuloB in questo esempio, nell'ambiente di sviluppo e personalizza il modulo. Nota che la soluzione A è la soluzione gestita già installata per il modulo nell'ambiente di sviluppo.
  2. Crea una nuova soluzione (Soluzione B nel diagramma sottostante) che è una soluzione non gestita, e aggiungi ModuloB. Esporta la soluzione come gestita. Questo passaggio esporta un FormXml differenziale (diff) per il modulo.
  3. Nell'ambiente di test, importa la soluzione gestita del passaggio 2, che crea un secondo livello di soluzione per il modulo. Nel diagramma sottostante, ModuloB acquisisce le modifiche unite di Soluzione A e Soluzione B nell'ambiente di test e l'interfaccia utente per il modulo mostra Campo1 e Campo3 nel modulo ma non Campo2 che è stato rimosso da Soluzione B.
  4. Quando personalizzi ulteriormente il modulo personalizzato nel passaggio 1 utilizzando nuove soluzioni gestite, assicurati che per il nuovo ambiente di sviluppo lo stato di ModuloB sia gestito. Come mostrato nello schema sottostante, le soluzioni gestite Soluzione A e Soluzione B vengono importate nel nuovo ambiente di sviluppo. ModuloB viene personalizzato creando personalizzazioni attive, che possono poi essere aggiunte a una nuova soluzione (Soluzione C nel diagramma) ed esportate come soluzione gestita.
  5. Nell'ambiente di test, importa la Soluzione C gestita del punto 4. Come mostrato nel diagramma sottostante Soluzione C sta aggiungendo un nuovo Campo4 a ModuloB e rimuovendo Campo3, aggiunto da Soluzione B. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Campo1 e Campo4 nel modulo ma non Campo2 e Campo3.

Diagramma ALM del modolo dello scenario 3.

Esempio non integro per questo scenario

Come mostrato nel diagramma seguente, non è una pratica ALM integra creare più soluzioni gestite dall'ambiente di sviluppo che contiene un'altra soluzione non gestita creata per lo stesso modulo. Da notare che lo stato della Soluzione B è non gestita. Quando crei un'altra soluzione non gestita (Soluzione C) per ModuloB, il FormXml viene esportato come FormXml diff come mostrato nel passaggio 4 nello scenario precedente. Tuttavia, ModuloB contiene anche le modifiche di Soluzione B, che verranno sovrascritte dalle nuove modifiche.

Ad esempio, come mostrato nel diagramma sottostante, Campo3 viene aggiunto a ModuloB in Soluzione B. Ma ora quando crei una nuova Soluzione C in questo ambiente, con Soluzione B nello stato non gestita e rimuovi Campo3, Campo3 verrà rimosso anche nell'ambiente di sviluppo. Campo3 non verrà rilevato nel FormXml diff quando la soluzione viene esportata, poiché la modifica dell'aggiunta e della rimozione di questa colonna è stata apportata nello stesso livello attivo. Ciò significa che quando Soluzione C viene importato nell'ambiente di test, il modulo eseguirà comunque il rendering di Campo3 poiché FormXml diff non lo registra mai come rimosso (come se fosse stato rimosso nel passaggio 5 dello scenario con istanza integra di ALM per moduli visto sopra). La personalizzazione del modulo in questo modo renderà l'ambiente di sviluppo non coerente con l'ambiente di test.

Un altro esempio di istanza ALM non integra per moduli per questo scenario.

Personalizzare un modulo gestito esistente e gestirlo utilizzando patch e aggiornamenti

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. Personalizza un modulo gestito esistente, denominato ModuloB in questo esempio, nell'ambiente di sviluppo e personalizza il modulo. Nota che Soluzione A è la soluzione gestita già installata per il modulo nell'ambiente di sviluppo.

  2. Crea una soluzione (Soluzione B) che sarà una soluzione non gestita, e aggiungi ModuloB. Esporta la soluzione come gestita. Questo passaggio esporta un FormXml diff per il modulo.

  3. Nell'ambiente di test, importa la Soluzione B gestita del passaggio 2, che crea un secondo livello di soluzione per il modulo. Nel diagramma sottostante, ModuloB ottiene le modifiche unite di Soluzione A e Soluzione B nell'ambiente di prova. Inoltre, l'interfaccia utente per ModuloB mostra Campo1 e Campo3 nel modulo ma non Campo2, che è stato rimosso da Soluzione B.

  4. Quando personalizzi ulteriormente il modulo personalizzato nel passaggio 1 utilizzando una soluzione patch, puoi utilizzare lo stesso ambiente di sviluppo del passaggio 1 dove Soluzione B esiste in uno stato non gestito. Come mostrato nello schema sottostante, Soluzione A è in uno stato gestito e Soluzione B è in uno stato non gestito. Il modulo viene personalizzato ulteriormente e crei una patch per Soluzione B aggiungendo il ModuloA questa soluzione ed esportandola come soluzione patch gestita. Questo passaggio esporta un FormXml diff.

  5. Nell'ambiente di test, importa la Soluzione B patch gestita del punto 4. Come mostrato nel diagramma sottostante, Patch Soluzione B sta aggiungendo un nuovo Campo4 a ModuloB e rimuovendo Campo3, che è stato aggiunto da Soluzione B.

    Nota

    Le patch sono di natura additiva e non possono rimuovere componenti, come le colonne, dal modulo. Quindi, Campo3 non verrà rimosso dal modulo. L'interfaccia utente per il modulo nell'ambiente di test ora mostra Campo1, Campo3 e Campo4 nel modulo ma non Campo2.

  6. Quando personalizzi ulteriormente il modulo creato nel passaggio 1 utilizzando gli aggiornamenti, utilizza lo stesso ambiente in cui Soluzione b è in uno stato non gestito e clona Soluzione B per creare una soluzione di aggiornamento e personalizzare ModuloB. Esporta l'aggiornamento come soluzione gestita. Questo passaggio esporta un FormXml diff per il modulo.

  7. Nell'ambiente di test, importa la soluzione di aggiornamento Soluzione B gestita del punto 6. Come mostrato nel diagramma sottostante Aggiornamento Soluzione B sta aggiungendo un nuovo Campo5 a ModuloB e rimuovendo Campo3, aggiunto da Soluzione B. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Campo1, Campo4 e Campo5 nel modulo ma Campo2 e Campo3 vengono rimossi.

Modifica un modulo gestito esistente utilizzando il diagramma con patch e aggiornamenti.

Gestire soluzioni e personalizzazioni non gestite per un nuovo modulo in più ambienti di sviluppo

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. In Ambiente di sviluppo 1, crea un nuovo ModuloA e personalizzalo.
  2. Crea una soluzione (Soluzione A nel diagramma sottostante) che sarà una soluzione non gestita, e aggiungi il nuovo modulo. Esporta la soluzione come non gestita. Questo passaggio esporta un FormXml completo per il modulo.
  3. In Ambiente di sviluppo 2, importa la soluzione non gestita del passaggio 2, che crea il modulo in Ambiente di sviluppo 2. Nel diagramma sottostante, viene creato ModuloA e l'interfaccia utente per il modulo mostra Campo1 e Campo2 che Soluzione A ha aggiunto al modulo.
  4. Personalizza ulteriormente il modulo in Ambiente di sviluppo 2 effettuando personalizzazioni attive nell'ambiente, come l'aggiunta di una nuova colonna denominata Campo3. ModuloA ora mostra Campo1, Campo2 e Campo3.
  5. In 'Ambiente di sviluppo 1, personalizzi ulteriormente il ModuloAggiungendo anche Campo4. L'interfaccia utente per il modulo in Ambiente di sviluppo A ora mostra Campo1, Campo2 e Campo4.
  6. Esporta la Soluzione A non gestita con le modifiche apportate nel punto 5. Questo passaggio esporta un FormXml completo per il modulo.
  7. Nell'Ambiente di sviluppo 2, importa l'Aggiornamento Soluzione A non gestito del punto 6. Poiché la soluzione che stai importando contiene il FormXml completo per ModuloA, sovrascrive la personalizzazione attiva effettuata in Ambiente di sviluppo 1. Quindi, il modulo ora mostra solo Campo1, Campo2 e Campo4, ma non Campo3, che era l'ulteriore personalizzazione attiva eseguita in Ambiente di sviluppo 1. Questo comportamento si verifica con qualsiasi importazione di soluzione non gestita che dispone del FormXml completo per il modulo.

Soluzioni non gestite in più ambienti.

Gestire soluzioni e personalizzazioni non gestite per un modulo esistente in più ambienti di sviluppo

Segui questi passaggi per implementare un'istanza integra di ALM per moduli per questo scenario.

  1. In Ambiente di sviluppo 1, personalizza un modulo esistente, denominato ModuloB in questo esempio. Quindi personalizza il modulo.
  2. Crea una soluzione (Soluzione B nel diagramma sottostante) che sarà una soluzione non gestita, e aggiungi ModuloB. Esporta la soluzione come non gestita. Questo passaggio esporta un FormXml diff per il modulo.
  3. In Ambiente di sviluppo 2, importa la soluzione non gestita del passaggio 2, che crea un secondo livello di soluzione per il modulo. L'interfaccia utente di ModuloB mostra Campo1, Campo2 e Campo3 dopo la fusione del modulo.
  4. Personalizza ulteriormente il modulo in Ambiente di sviluppo 2 effettuando personalizzazioni attive nell'ambiente, come l'aggiunta di una nuova colonna denominata Campo4. ModuloB ora mostra Campo1, Campo2, Campo3 e Campo4.
  5. In 'Ambiente di sviluppo 1, personalizza ulteriormente il ModuloAggiungendo una nuova colonna denominata Campo5. L'interfaccia utente per il modulo in Ambiente di sviluppo 1 ora mostra Campo3 e Campo5.
  6. Esporta Soluzione B non gestita con le modifiche apportate nel punto 5. Questo passaggio esporta un FormXml diff per il modulo.
  7. In Ambiente di sviluppo 2, importa Aggiornamento Soluzione B non gestito del punto 6. Poiché la soluzione che stai importando contiene il FormXml diff per ModuloB, verrà unito alla personalizzazione attiva effettuata in Ambiente di sviluppo 1. Quindi il modulo ora mostra Campo1, Campo2, Campo3, Campo4 e Campo5. Questo comportamento si verifica per qualsiasi importazione di soluzione non gestita che dispone del FormXml diff per il modulo.
  8. Se l'unione del modulo nel passaggio 7 non è quello desiderato anche se stai importando un FormXml diff con la soluzione non gestita e vuoi poter sovrascrivere le personalizzazioni attive effettuate in Ambiente di sviluppo 2, rimuovi il livello attivo per ModuloB. Maggiori informazioni: Rimuovere un livello non gestito.
  9. Esporta Soluzione B non gestita con le modifiche apportate nel punto 5. Questo passaggio esporta un FormXml diff per il modulo.
  10. In Ambiente di sviluppo 2, importa Aggiornamento Soluzione B non gestito del punto 9. Poiché non esiste un livello attivo per il modulo in Ambiente di sviluppo 2, (vedi passaggio 8), tutte le modifiche di Soluzione B non gestita vengono importati anche se stai importando il FormXml diff per ModuloB. Quindi il modulo ora mostra solo Campo1, Campo2, Campo3 e Campo5. Questo comportamento si verifica per qualsiasi importazione di soluzione non gestita che dispone del FormXml diff per il modulo. Questo è lo stesso risultato del passaggio 7 dello scenario Gestire soluzioni e personalizzazioni non gestite per un modulo esistente in più ambienti di sviluppo.

Diagramma della gestione del ciclo di vita dell'applicazione per moduli dello scenario 6.

FormXML completo e differenziale

Ogni pacchetto di soluzioni esportato include un file customizations.xml. Ogni volta che un modulo è incluso in una soluzione, la relativa definizione del modulo esiste nelle sezioni FormXml del file customizations.xml. Il FormXml può essere completo o differenziale (diff).

FormXml completo

Il FormXml che ottieni esportando una soluzione per un modulo in uno stato non gestito è denominato FormXml completo. Completo significa che contiene l'intera definizione del modulo. Quando crei un nuovo modulo e lo esporti, il modulo sarà sempre un FormXml completo poiché il modulo nell'ambiente da cui si sta esportando è in uno stato non gestito e anche in uno stato di creazione. Se esporti altre soluzioni da questo stesso ambiente, queste includeranno anche un FormXml completo. Perché l'attributo solutionaction indica un FormXml diff, il FormXml completo nel file customization.xml nella soluzione esportata non conterrà alcun attributo solutionaction.

FormXml differenziale (diff)

Il FormXml che ottieni esportando una soluzione per un modulo in uno stato gestito è denominato FormXml differenziale o diff. Diff significa che il FormXml contiene solo le modifiche apportate nelle personalizzazioni attive in quell'ambiente e non l'intera definizione del modulo. Quando personalizzi un modulo gestito esistente e lo esporti, il modulo sarà sempre un FormXml diff poiché conterrà solo le modifiche attive apportate allo stesso. Il FormXml diff nel file customization.xml nella soluzione che esporti conterrà attributi solutionaction che definiscono le modifiche, come Aggiunto, Rimosso, Modificato.

Il FormXml diff garantisce che la soluzione includerà solo le modifiche necessarie per l'app e sarà meno interessata dalle modifiche di altri livelli. Inoltre il FormXml diff rende la soluzione meno ingombrante e rende più rapide le importazioni.

Vedi anche

Elementi consigliati per un'istanza integra di ALM per moduli