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) 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, FormA viene creato nell'ambiente di test e l'interfaccia utente per il modulo mostra Field1 e Field2 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 FormA sia gestito. Come mostrato nello schema, 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 Soluzione B sta aggiungendo un nuovo Field3 a FormA e rimuovendo Field2, aggiunto da Soluzione A . Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Field3 e Field1 nel modulo ma non Field2 dopo l'unione.

Esempio non integro per questo scenario

Come mostrato in questo diagramma, 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.

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) 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 FormA viene creato nell'ambiente di test e l'interfaccia utente per il modulo mostra Field1 e Field2 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, la patch della Soluzione A sta aggiungendo un nuovo Field3 al FormA e rimuovendo Field2, aggiunto da Soluzione A.

   Nota

   Le patch contenenti 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, Field2 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 l'aggiornamento della Soluzione A sta aggiungendo un nuovo Field4 a FormA e rimuovendo Field2, aggiunto da Soluzione A. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Field1, Field3 e Field4 nel modulo ma Field2 verrà rimosso dall'importazione dopo l'unione del modulo.

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, FormB acquisisce le modifiche unite di Soluzione A e Soluzione B nell'ambiente di test e l'interfaccia utente per il modulo mostra Field1 e Field3 nel modulo ma non Field2 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, le soluzioni gestite Soluzione A e Soluzione B vengono importate nel nuovo ambiente di sviluppo. Modulo B 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 Soluzione C sta aggiungendo un nuovo Field4 a FormB e rimuovendo Field3, aggiunto da Soluzione B. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Field1 e Field4 nel modulo ma non Field2 e Field3.

Esempio non integro per questo scenario

Come mostrato nel diagramma, 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, Field3 viene aggiunto a FormB in Soluzione B. Ma ora quando crei una nuova Soluzione C in questo ambiente, con Soluzione B nello stato non gestita e rimuovi Field3, Field3 verrà rimosso anche nell'ambiente di sviluppo. Field3 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.

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, FormB 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, 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, Patch Soluzione B sta aggiungendo un nuovo Field4 a FormB e rimuovendo Field3, che è stato aggiunto da Soluzione B.

   Nota

   Le patch sono di natura additiva e non possono rimuovere componenti, come le colonne, dal modulo. Quindi, Field3 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 Aggiornamento Soluzione B sta aggiungendo un nuovo Field5 a FormB e rimuovendo Field3, aggiunto da Soluzione B. Nell'interfaccia utente per il modulo nell'ambiente di test viene ora visualizzato Field1, Field4 e Field5 nel modulo ma Field2 e Field3 vengono rimossi.

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) 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, viene creato FormA e l'interfaccia utente per il modulo mostra Field1 e Field2 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 FormA, 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.

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) che sarà una soluzione non gestita, e aggiungi FormB. 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 FormB, 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 FormB. 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 FormB. 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.

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