Scenari di controllo versioni

Versioni in un ambiente di gruppo

Quando si sta sviluppando un'applicazione, è possibile utilizzare le versioni per distinguere i livelli di completamento. Tuttavia, è necessario utilizzare un repository di codice sorgente esterno per tale scopo. È possibile conservare solo una versione di progetto nello spazio di lavoro, poiché i nomi dei progetti devono essere univoci.

Tramite Eclipse, IBM® Integration Designer fornisce un client per CVS (Concurrent Versions System). È anche possibile condividere un progetto e salvare le versioni utilizzando Rational® Team Concert o altri repository. Consultare i collegamenti correlati per argomenti relativi a specifici sistemi di gestione origine.

Spesso è utile assegnare ciascuna versione a un nuovo ramo o stream nel repository, in modo da potervi tornare se necessario o apportare modifiche a una versione precedente ancora in uso. È possibile ridurre al minimo la confusione se si corrispondono i numeri di versione utilizzati nell'ambiente di runtime con i nomi ramo o flusso.

Moduli di controllo versioni

Utilizzando il controllo delle versioni, è possibile creare un modulo, metterlo in produzione, quindi decidere di crearne una nuova versione e anche metterlo in produzione.

I moduli sono sensibili alla versione solo quando vengono distribuiti tramite serviceDeploy. I moduli con versione esportati come file EAR tramite Integration Designer o aggiunti a UTE tramite Aggiungi / Rimuovi progetti non riconoscono le proprietà di versione di un modulo.

Integration Designer non applica un modello di versione del modulo incrementale. Invece, è possibile assegnare un qualsiasi numero di versione a tre parti al proprio modulo. Ciò significa che in teoria è possibile avere un modulo 5.2.5 che contiene contenuto precedente al modulo 1.0.0.

Quando si eseguono il commit dei moduli con versione come rami, specificare il numero di versione del modulo nel nome del ramo. Aggiungere i commenti del ramo appropriati che identificano il numero di versione. Questa procedura assiste gli altri utenti fornendo informazioni sulla versione di cui stanno eseguendo il checkout.

Non utilizzare eccessivamente la versione del modulo. Idealmente, ogni versione del modulo deve soddisfare uno scopo specifico, ad esempio, un modulo con versione che gestisce il traffico durante le operazioni stagionali. Il controllo delle versioni del modulo non deve mai sostituire il controllo delle versioni del controllo origine e la cronologia delle revisioni. Consentire al sistema di gestione del controllo origine di gestire le tipiche modifiche di sviluppo quotidiane.

Controllo delle versioni delle importazioni SCA

I bind SCA ereditano le relative informazioni sulla versione dal modulo a cui sono associati. Quando si crea un bind di importazione SCA trascinando una versione di un bind di esportazione SCA, il nuovo bind di importazione SCA verrà contrassegnato con la versione dell'esportazione. Il bind statico verrà risolto nel bind di esportazione specifico e nella versione del modulo durante il runtime. Sebbene il bind sia dichiarato staticamente, è possibile modificare il bind di importazione SCA al runtime utilizzando la console di gestione per reimpostare il valore della versione per utilizzare una versione distribuita diversa dell'esportazione o del modulo. Se un'esportazione non è nota all'interno dello spazio di lavoro, è necessario sapere se all'esportazione è assegnata una versione e assegnare manualmente tale valore di versione al bind di importazione.

L'importazione SCA ha un bind statico per una particolare esportazione, il che significa che un'importazione può stabilire una connessione solo all'esportazione per cui è stata creata e configurata. Quindi, se l'importazione non ha una versione dichiarata, è previsto che sia collegata a un'esportazione senza versione. Se ci sono più versioni numerate del servizio distribuite nell'ambiente di runtime e l'importazione non ha una versione dichiarata, l'importazione non riuscirà a risolvere l'esportazione.

È possibile creare un componente di mediazione che contiene una primitiva di ricerca endpoint e assegnarvi una versione e una politica di corrispondenza (ultima corrispondenza compatibile). Questa implementazione consente l'instradamento dinamico alla versione appropriata dell'esportazione o del modulo. Se si promuove la proprietà della versione dalla mediazione, è possibile modificare dinamicamente il valore nell'ambiente di runtime utilizzando la console di gestione.

Refactoring di moduli e librerie con versione

Progettare e modificare soluzioni incapsulate

L'incapsulamento in questo contesto si riferisce al raggruppamento e all'isolamento delle aree di funzionalità - come le implementazioni dei servizi - in modo che possano essere modificate indipendentemente dalle altre parti del sistema. È necessario progettare in modo da poter modificare l'implementazione del servizio indipendentemente dai suoi utenti e dai fornitori di servizi che chiama.

Anche se l'implementazione del servizio è stata separata dal modulo che ne è il consumer, è necessario prestare attenzione al controllo delle versioni quando si apportano le modifiche. Il modulo di utilizzo non deve essere influenzato da ulteriori operazioni o attributi facoltativi, ma la vecchia implementazione potrebbe non essere in grado di eseguire la build rispetto ai nuovi oggetti se stanno passando versioni differenti di oggetti su bind SCA o tra processi BPEL. Le interfacce completamente disaccoppiate sono emerse in quanto i servizi Web hanno meno probabilità di causare problemi.

Versioni per processi di lunga durata

Le applicazioni che implicano componenti di lunga durata sono vulnerabili alle modifiche nel loro ambiente e richiedono un'ulteriore considerazione al momento dello sviluppo sul modo in cui verranno eseguite le modifiche del processo. Si desidera che le nuove istanze di un processo seguano la nuova progettazione e che quelle esistenti vengano aggiornate dinamicamente. IBM Workflow Server supporta questi obiettivi con il controllo della versione del processo, il bind in ritardo e la migrazione dell'istanza di processo.

Il controllo delle versioni dei processi consente di mantenere più definizioni di un processo esistenti, contemporaneamente, durante il runtime. Le istanze esistenti continuano ad essere eseguite secondo le loro progettazioni originali. Le nuove istanze utilizzano la nuova definizione se viene utilizzato il bind in ritardo.

IBM Integration Designer fornisce due stili distinti di richiamo. Fare riferimento all'elenco riportato di seguito per ulteriori dettagli.

Fare riferimento a quanto segue per le versioni in IBM Integration Designer.

• Scenari di controllo delle versioni
• Versione dei processi BPEL
• Versione delle state machine di business

Fare riferimento anche ai seguenti file per la creazione di versioni:

• Migrazione delle istanze del processo in esecuzione ad una nuova versione del processo BPEL
• Documentazione di supporto per la migrazione delle istanze dei processi