Scenari supportati per l'utilizzo di Rinomina server

Scenari supportati in questa versione.

Importante:

Le operazioni di rinominazione del server modificano gli URL pubblici degli artefatti di riferimento in un'installazione IBM® Engineering Lifecycle Management e potrebbero influenzare i collegamenti esterni. Ad esempio, le modifiche all'URL potrebbero rendere non validi i riferimenti esterni, come quelli nelle notifiche email oppure i riferimenti OSLC (Open Services for Lifecycle Collaboration) esterni dagli strumenti che non supportano la ridenominazione del server.

Se la ridenominazione di un server viene eseguita in un ambiente di produzione, tali modifiche potrebbero disturbare gli utenti. Tuttavia, l'operazione di ridenominazione del server è utile per le attività di gestione di routine, come l'aggiornamento dei dati in un ambiente di staging utilizzando un'istantanea dell'ambiente di produzione.

Per rinominare un server, è necessario ottenere un file di chiave di funzionalità dall'assistenza IBM. Quando si contatta il supporto IBM Support, indicare che si sta richiedendo un file di chiavi della funzione di ridenominazione del server. Il file di chiavi si chiama ImportURLMappings.activate. Copiare il file nella directory 'JazzInstallDir/server/conf per le applicazioni che si desidera rinominare. La chiave è necessaria solo per eseguire il comando 'repotools importURLMappings.

È possibile rinominare il server per spostare una distribuzione pilota in produzione o per spostare una distribuzione di produzione esistente su un nuovo hardware. L'operazione di ridenominazione del server sposta tutti i progetti esistenti e le risorse utente da una distribuzione ad un'altra. L'operazione non supporta lo spostamento di un progetto selezionato, cioè non è possibile spostare progetti selezionati durante la ridenominazione del server.

Leggete la descrizione dei seguenti scenari supportati e non supportati. Per le fasi generali della procedura di rinominazione di un server, consultare la sezione Procedura di rinominazione del server. Per informazioni sui requisiti di ogni scenario, vedere Requisiti della versione software.
Importante: La registrazione di applicazioni aggiuntive dopo la rinominazione del server non è supportata a causa del rischio potenziale di corruzione dei dati. Se è necessario registrare applicazioni aggiuntive in un ambiente IBM Engineering Lifecycle Management rinominato e non sono disponibili opzioni alternative, contattare il supporto IBM per assistenza.

Scenario supportato: Impostazione di un ambiente di staging di prova con dati di produzione

Questo scenario consente di creare una copia di un'implementazione esistente di IBM Engineering Lifecycle Management solo a scopo di test. In questo scenario, durante l'esecuzione in produzione, è possibile installare Engineering Lifecycle Management anche nell'ambiente di staging di prova e copiare i dati e i file di configurazione dalla produzione all'ambiente di staging. Si utilizza quindi Rinomina server per modificare gli URL nell'ambiente di staging.

È utile per provare nuove caratteristiche o funzioni con dati reali senza impattare sul database di produzione. Un esempio potrebbe essere quello di provare una modifica alla configurazione dei processi o alle definizioni dei tipi di elementi di lavoro Engineering Workflow Management. Questo scenario richiede che il server di produzione e il server di test copiato non si colleghino tra loro.

Inoltre, è importante non collegare un client di Engineering Workflow Management sia al repository di produzione che a quello di staging. Utilizzare sempre uno spazio di lavoro di staging per connettersi al server di staging.

Per ulteriori dettagli, consultare Topologie e file di mappatura per la configurazione di un ambiente di staging di prova e Configurazione di un ambiente di staging di prova con dati di produzione.

Importante: questo scenario non può essere utilizzato per eseguire un aggiornamento dalla versione 3 alla versione 4, che richiede una rete isolata in cui gli URL rimangono costanti prima e durante la procedura di aggiornamento. Per ulteriori dettagli su questo scenario di aggiornamento, consultare Preparazione di un ambiente di test per il processo di aggiornamento.

Scenario supportato: Passaggio di un'implementazione pilota alla produzione

Questo scenario inizia con un'installazione pilota di dimensioni ridotte, creata a scopo di valutazione. Il pilota ha un numero limitato di utenti, che testano le funzionalità del prodotto e creano dati. Dopo il periodo di valutazione, l'obiettivo è scalare, aggiungere altri utenti e dati e non perdere i dati esistenti creati durante il periodo pilota.

Per diversi motivi, come la necessità di spostare il pilota su un hardware più robusto o di rispettare gli standard di denominazione aziendali, è necessario rinominare il server. Lo scenario da pilota a produzione deve soddisfare i seguenti requisiti:

  • Il pilota deve essere una singola implementazione di Engineering Lifecycle Management(Jazz Team Server con le applicazioni di Engineering Lifecycle Management registrate) senza collegamenti ad altre implementazioni di Engineering Lifecycle Management.
  • Tutti i client utente e i motori di compilazione devono essere alla versione 6.0 o successiva prima di rinominare il server.
  • Dopo aver rinominato il server, l'installazione pilota deve essere definitivamente disattivata.
  • Non sono consentite integrazioni con prodotti di terzi, ad eccezione delle integrazioni con ClearQuest® e DevOps Code ClearCase®. ClearQuest e DevOps Code ClearCase devono essere sistemi di produzione in grado di comunicare con l'implementazione di Engineering Lifecycle Management nell'ambiente pilota. Attualmente, lo spostamento di ClearQuest o DevOps Code ClearCase da un sistema pilota a un sistema di produzione è uno scenario non supportato.
  • Non si deve usare il database Derby o si deve migrare dal database Derby prima di rinominarlo.

Per ulteriori dettagli, vedere Topologie e file di mappatura per lo scenario pilota alla produzione e Spostamento di una distribuzione pilota o di produzione completa tramite la ridenominazione del server.

Scenario supportato: Spostamento di un'installazione di produzione esistente

È possibile rinominare un server su un'installazione di Engineering Lifecycle Management in piena produzione. È possibile spostare l'installazione su un nuovo hardware o eseguire una rinominazione in loco sull'hardware esistente. Questo scenario da produzione a produzione deve soddisfare i seguenti requisiti:

  • A differenza dello scenario da pilota a produzione, ora sono supportate le implementazioni multiple di Engineering Lifecycle Management, ad esempio due Jazz Team Server collegati.
  • Se si passa a un nuovo hardware, il vecchio hardware deve essere messo definitivamente fuori servizio.
  • Sono consentite più integrazioni con prodotti di terze parti rispetto a quanto consentito in precedenza. Per informazioni sulle integrazioni supportate, consultare Impatto della ridenominazione del server sui prodotti integrati e il wiki Jazz.net sulla distribuzione.
  • Si presume che si stia utilizzando un database aziendale e non il database Derby.

Scenari non supportati

I seguenti scenari non sono supportati:

  • Clonazione di un'applicazione o di un'implementazione di Engineering Lifecycle Management per l'uso in produzione
    Nota: Tuttavia, è possibile utilizzare la configurazione da riga di comando per automatizzare le nuove distribuzioni. Vedere Esecuzione della configurazione dalla riga di comando.
  • Dividere un'implementazione di produzione di Engineering Lifecycle Management clonando e rinominando e quindi archiviando parti dei dati del repository
  • Passaggio di un'applicazione di Engineering Lifecycle Management a un altro Jazz Team Server
  • Spostare, copiare o eliminare progetti o artefatti selezionati tra le applicazioni online di Engineering Lifecycle Management.