Conteúdo


Do AccuRev para o Rational Team Concert

Como migrar código fonte

Comments

Visão geral

Os sistemas de gerenciamento de configuração de software são, essencialmente, bancos de dados que fornecem controle de versão para os elementos armazenados. Porém, devido às diferenças de funções e da organização do banco de dados interno, migrar de um sistema de gerenciamento de configuração de software para outro não costuma ser um processo simples.

O IBM® Rational Team Concert™ integra controle de origem com outras ferramentas, como gerenciamento de defeitos e de requisitos. Este artigo descreve como migrar código fonte de um repositório do AccuRev para o Rational Team Concert com ou sem o histórico do arquivo de origem. Código fonte , neste contexto, significa o código para o software em desenvolvimento, e não os arquivos binários do AccuRev ou do Rational Team Concert.

Antes de continuar, determine se é necessário migrar o histórico de arquivos de origem. Ao migrar uma grande quantidade de código fonte, como no caso do depósito AccuRev, é possível escolher migrar apenas o código fonte, sem o histórico que mostra que arquivos foram atualizados e quais alterações foram feitas. Este artigo descreve como migrar o código fonte do AccuRev para o Rational Team Concert sem o histórico de arquivos de origem e com ele.

Design do fluxo no AccuRev

Para entender como os fluxos são projetados no AccuRev, considere um produto de amostra, ANT, que você começa a desenvolver. No início, o projeto do produto no depósito do AccuRev é simples, como mostra a Figura 1. Os arquivos ANT 1.0 estão localizados no fluxo Next2Ship_Build . Os desenvolvedores criam as áreas de trabalho fora desse fluxo. As criações são feitas a partir do fluxo Next2Ship_Build .

Figura 1. Fluxo de amostra para ANT em AccuRev
Sample AccuRev stream

Depois de alguns meses, o ANT 1.0 está pronto para liberação. O engenheiro de liberação cria uma captura instantânea do fluxo Next2Ship_Build , como mostra a Figura 2 com um círculo chamado v1.0_RTM. O engenheiro de liberação então cria um novo fluxo de desenvolvimento v1.0_Build fora da captura instantânea que é usado para a manutenção do ANT 1.0.

Neste ponto, começa o desenvolvimento para o ANT 2.0, no fluxo Next2Ship_Build . Depois de alguns meses, o ANT 2.0 está pronto para liberação. O engenheiro de liberação cria uma captura instantânea do Next2Ship_Build, como mostra a Figura 2, com um círculo chamado v2.0_RTM. O engenheiro de liberação então cria um novo fluxo de desenvolvimento v2.0_Build fora da captura instantânea. Ele é usado para manter ANT 2.0.

Figura 2. Vários fluxos para ANT no AccuRev
AccuRev multiple streams
AccuRev multiple streams

Migrar arquivos de código fonte sem histórico

Observação: este artigo presume que um projeto Rational Team Concert com fluxos e uma área de trabalho já tenham sido criados.

Para migrar os arquivos para o Rational Team Concert sem incluir o histórico do arquivo de origem, siga estas etapas:

  1. Crie um projeto no Rational Team Concert com o modelo requerido e crie um fluxo RTC_Stream nesse projeto. Os fluxos são contêineres para componentes que, por sua vez, são contêineres para artefatos controlados por versão.
  2. Crie uma área de trabalho a partir do fluxo RTC_Stream .
  3. Obtenha os arquivos da captura instantânea v1.0_RTM no AccuRev, copie-os para a área de trabalho do Rational Team Concert e entregue-os para este RTC_Stream.
  4. Crie uma captura instantânea v1.0_RTM a partir de RTC_Stream.
  5. Obtenha os arquivos da captura instantânea v2.0_RTM no AccuRev, copie-os para a área de trabalho do Rational Team Concert e entregue-os para este RTC_Stream.
  6. É possível ver as alterações enviadas para os arquivos novos e modificados.
  7. Para arquivos excluídos, é necessário comparar as áreas de trabalho do AccuRev e do Rational Team Concert, identificar os arquivos que não estão na área de trabalho AccuRev como os excluídos e removê-los manualmente da área de trabalho do Rational Team Concert. Verifique se as alterações enviadas incluem todos os arquivos novos e excluídos. Quando as alterações forem processadas, a área de trabalho do Rational Team Concert será a mesma que a do AccuRev. Ao concluir essa etapa, a captura instantânea do v2.0_RTM terá migrado com sucesso.
  8. Repita as Etapas 5, 6 e 7 para o fluxo principal Next2Ship_Build.
  9. Repita este processo para os fluxos v1.0_Build e v2.0 Build .
  10. Continue o mesmo processo para qualquer fluxo adicional.
  11. Compare as áreas de trabalho do AccuRev e do Rational Team Concert para todos os fluxos para garantir que estejam em sincronia.

Depois de concluir essas etapas, os arquivos do código fonte migram do depósito do AccuRev para uma área do projeto Rational Team Concert. Porém, o histórico de arquivos de origem rastreado no AccuRev não migra. O histórico do arquivo de origem é perdido ao usar esse método.

O restante do artigo descreve como migrar os arquivos do código fonte e manter o histórico ao mesmo tempo.

Migrar arquivos de código fonte com histórico

Para manter o histórico do arquivo de origem, é necessário recriar os depósitos do AccuRev como áreas do projeto Rational Team Concert. O objetivo é que cada área do projeto corresponda ao depósito do AccuRev em termos de:

  • Hierarquia de fluxo
  • Conteúdo do fluxo
  • Capturas Instantâneas

Ao recriar os depósitos do AccuRev como áreas do projeto Rational Team Concert, mantém-se o histórico de alterações do sistema AccuRev, as práticas de desenvolvimento atuais permanecem inalteradas e preservam-se os direitos e as permissões de acesso. Embora a migração seja realizada com mínimo impacto aos desenvolvedores, não é possível migrar áreas de trabalho do AccuRev para o Rational Team Concert.

Para migrar arquivos do código fonte e manter o histórico dos mesmos, use o design mostrado na Figura 3 e siga o fluxo de trabalho para criar um sistema de migração.

Figura 3. Diagrama de blocos do sistema de migração
Block diagram to represent the migration flow
Block diagram to represent the migration flow

O sistema de migração mostrado na Figura 3 inclui os seguintes componentes principais.

ComponenteDescrição
Servidor AccuRevMáquina que hospeda o repositório de origem do AccuRev.
Máquina cliente de origemMáquina com acesso de rede ao servidor AccuRev.
Cliente AccuRevAplicativo que é executado na máquina cliente de origem. Fornece a interface com o usuário para o repositório do AccuRev. Os usuários podem escolher uma GUI ou interface de linha de comando.
Agente de origemAplicativo customizado executado na máquina cliente de origem. Possui acesso ao repositório do AccuRev por meio da interface de linha de comando fornecida pelo cliente AccuRev.
Caixa de correioPasta em um sistema de arquivos compartilhado usado para enviar pacotes do agente de origem para o agente de destino.
PacoteEstrutura de dados que define completamente qualquer atualização do repositório do AccuRev.
Servidor JazzMáquina que hospeda o repositório (Rational Team Concert) de destino.
Máquina cliente de destinoMáquina com acesso de rede ao servidor Jazz.
API Java do Rational Team ConcertConjunto de classes Java que permitem às operações do Rational Team Concert serem criptografadas.
Agente de destinoAplicativo customizado executado na máquina cliente de destino. Ele tem acesso ao repositório Rational Team Concert por meio da API Java do Rational Team Concert.

Fluxo de trabalho para migrar um depósito AccuRev

Use o seguinte fluxo de trabalho para desenvolver um sistema de migração que migre um depósito do AccuRev para um projeto Rational Team Concert:

  1. o usuário instrui o agente de origem a migrar um depósito específico do AccuRev.
  2. O agente de origem usa o cliente AccuRev para obter o histórico do depósito. O histórico do depósito é uma lista ordenada por tempo de transações do AccuRev aplicadas ao depósito.
  3. O agente de origem realiza um ciclo pelo histórico do depósito e cria pacotes colocados na caixa de correio do depósito.
  4. Cada pacote descreve uma ou mais transações mais genéricas e contém todo material de apoio exigido, como as versões de arquivo específicas.
  5. O usuário instrui o agente de destino a monitorar uma caixa de correio de depósito específica.
  6. O agente de destino processa os pacotes na caixa de correio do depósito na ordem em que foram criados.
  7. O agente de destino cria a área do projeto Rational Team Concert ao processar o primeiro pacote.
  8. O agente de destino realiza um ciclo por cada pacote e converte as transações genéricas em transações do Rational Team Concert e aplica-as à área do projeto Rational Team Concert.

O sistema é dimensionado para permitir migração paralela de vários depósitos do AccuRev.

O processo de fluxo de trabalho continua até que os agentes de origem e de destino sejam interrompidos. Dessa maneira, o sistema de migração gradualmente sincroniza a área do projeto Rational Team Concert com o depósito do AccuRev e os mantêm em sincronia.

Descrição de um pacote

Um pacote é a unidade de comunicação entre o agente de origem e o agente de destino. Cada pacote descreve uma ou mais transações genéricas. Como mostra a Figura 4, um pacote é uma pasta em um sistema de arquivos compartilhado. Os nomes das pastas estão na forma Pkg-nnnnn, em que nnnnn é um número em sequência crescente. Essa convenção de nomenclatura permite o processamento dos pacotes na ordem de criação.

Figura 4. estrutura do pacote
Sample package with transaction folders

Cada pacote contém um arquivo de descrição de pacote e, potencialmente, pastas de transação.

O arquivo de descrição de pacote description.xml é encontrado na pasta raiz do pacote Pkg-nnnnn. A estrutura básica desse arquivo é:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<package>
 // package body
</package>"
  • Corpo do pacote: consiste em um ou mais descritores de transação. Eles são estruturas XML que definem operações em um repositório. Cada descritor de transação tem um registro de data e hora e um ID de transação únicos.
  • Descritores de transação: listados no arquivo de descrição do pacote na ordem do registro de data e hora (mais antigo primeiro).
  • ID da transação: especifica a pasta da transação em que qualquer conteúdo de arquivo associado à transação pode ser encontrado.
  • Pasta da transação: contém uma árvore de diretório esparsa. Apenas pastas e arquivos associados à transação são incluídos.

Descritor da transação

O agente de origem processa as transações AccuRev para criar transações genéricas. O agente de destino processa transações genéricas para executar as transações do Rational Team Concert. Um descritor de transação representa uma transação genérica. É uma estrutura XML que define totalmente uma operação atômica em um repositório. A listagem de código a seguir mostra a sintaxe básica do descritor de transação. Os colchetes [ ] indicam tags opcionais.

<transaction xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
"xsi:type="streamData" user="AccuRev" type="xxxxxxxx"
timeStamp="1129138647" id="1.0">
//Transaction body
</transaction>

O cabeçalho da transação inclui as tags a seguir. As tags xmlns e xsi podem ser ignoradas.

  • id: identifica a transação de maneira única. É um número decimal.
  • timeStamp: identifica a hora em que a transação ocorreu no repositório de origem. É um valor de 10 dígitos.
  • user: especifica o ID do usuário responsável por essa transação no repositório de origem.
  • type: especifica a estrutura da transação. Determina quais tags adicionais podem ser encontradas no cabeçalho da transação e a estrutura do corpo da transação.
  • comment: o texto é opcional.

Transações genéricas

Muitos descritores de transação no arquivo de descrição do pacote não têm corpo. Eles representam transações AccuRev que foram encontradas no histórico do depósito, mas que não são necessárias para a migração. Apenas operações em um fluxo são relevantes para a migração.

Há quatro tipos de transações genéricas:

  • chstream
  • mkstream
  • purge
  • promote
    • defunct
    • keep
    • move
    • undefunct

A sintaxe a seguir é usada para todos os tipos. Os colchetes [ ] indicam elementos opcionais.

chstream: altera os atributos de um fluxo

<transaction type="chstream"
<streamID>10</streamID> <streamName>TestSCM-SqlServer</streamName> [<oldStreamName>TestSCM-SqlServer</oldStreamName>] <baseStreamName>TestSCM</baseStreamName> [<baseStreamType>normal</baseStreamType>] <isHidden>false</isHidden> <streamType>workspace</streamType> <basisTime>0</basisTime> </transaction>
  • <streamID>: manipulador único atribuído ao fluxo por AccuRev
  • <oldStreamName>: não é exigido se <streamType> for workspace.
  • <baseStreamType>: não é exigido se <streamType> for workspace.

mkstream: cria um novo fluxo

<transaction type="mkstream" 
                <streamID>1</streamID>
                <streamName>TestSCM</streamName>
                <isHidden>false</isHidden> Ok
                <streamType>normal</streamType> 
                <basisTime>0</basisTime> 
</transaction>
  • <streamID>: manipulador único atribuído ao fluxo por AccuRev.
  • <streamType>: pode ser normal, pass through ou workspace.

purge: restaura elementos à última versão inserida no fluxo

<transaction type="purge"
                <streamName>TestSCM_SanMateo</streamName> 
                <streamType>normal</streamType> 
                <baseStreamName>TestSCM</baseStreamName> 
                <baseStreamType>normal</baseStreamType> 
                <file>
<fileId>49127</fileId> <isDirectory>true</isDirectory> <path>\Purge_rename</path> <sequenceId>51.0</sequenceId> <fileStatus>keep</fileStatus> <comment>purged file</comment> <defectID>123</defectID> </file> </transaction>
  • <file>: identifica um elemento de assunto. Isso pode ser repetido para vários elementos.
  • <fileStatus>: identifica a operação no elemento.
  • <comment> e <defectID>: são inseridas informações nas propriedades do arquivo Rational Team Concert e no comentário de Change Set.

promote: envia alterações de um fluxo para outro

A operação promote inclui quatro subtipos. Uma única transação promote pode ter qualquer número e combinação desses subtipos.

  • defunct
  • move
  • keep
  • undefunct

promote (defunct): remove um elemento do controle de versão

 <transaction type="promote">
                <toStream>TestSCM</toStream>
<file> <fileId>192</fileId> <isDirectory>true</isDirectory> <path>\HotfixComponents\Database\db2</path> <sequenceId>23.0</sequenceId> <fileStatus>defunct</fileStatus> [<comment>Example defunct</comment>] [<defectID>123</defectID>] </file> </transaction>
  • <file>: identifica o elemento de assunto.
  • <fileStatus>: identifica a operação no elemento.
  • <comment>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.
  • <defectID>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.

promote (move): renomeia ou transfere elementos dentro da árvore do diretório de origem

<transaction type="promote" >
                <file>
                <fileId>254</fileId> 
                <isDirectory>true</isDirectory> 
                <path>\HotfixComponents\Database\oracle\scripts</path> 
                <source>\HotfixComponents\Database\oracle\scripts-kmd</source>
                <destination>\HotfixComponents\Database\oracle\scripts</destination>
                <sequenceId>39.0</sequenceId> 
                <fileStatus>move</fileStatus> 
                <comment>defunct</comment>
                <defectID>123</defectID>
                </file>
                <toStream>TestSCM</toStream>
                fromStream>Where</fromStream> 
</transaction>
  • <file>: identifica o elemento de assunto.
  • <fileStatus>: identifica a operação no elemento.
  • <comment>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.
  • <defectID>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.

promote (keep): fornece uma nova versão de um elemento

<transaction type="promote">
                <toStream>TestSCM</toStream> 
                <file>
                <fileId>264</fileId> 
                <isDirectory>false</isDirectory> 
                <path>\HotfixComponents\Database\sqlserver\scripts\yfs_table_not_sized_73_HF16.sql
                </path> 
                <sequenceId>41.0</sequenceId> 
                <fileStatus>keep</fileStatus> 
                <mergedAgainstStreamName>TestSCM</mergedAgainstStreamName>
                <mergedAgainstStreamType>normal</mergedAgainstStreamType>
                <mergedAgainstBaseStreamName>TestSCM</mergedAgainstBaseStreamName>
                <mergedAgainstBaseStreamType>normal</mergedAgainstBaseStreamType>
                <comment>defunct</comment>]
                <defectID>123</defectID>
                </file>
</transaction>
  • <file>: identifica o elemento de assunto.
  • <fileStatus>: identifica a operação no elemento.
  • <mergedAgainst...>: indica se o artefato foi criado por uma mesclagem.
  • <mergedAgainstBase...>: indica a base usada para a mesclagem (ancestral).
  • <comment>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.
  • <defectID>: as informações são inseridas nas propriedades do arquivo Rational Team Concert e no comentário Change Set.

promote (undefunct): restaura o controle de versão do elemento nomeado

<transaction type="promote">
                <toStream>TestSCM</toStream> 
                <fromStream>TestSCM</fromStream>
                <file>
                <fileId>44604</fileId> 
                <isDirectory>false</isDirectory> 
                <path>\buildallmigration.xml</path> 
                <sequenceId>1401.0</sequenceId> 
                <fileStatus>undefunct</fileStatus>  
                </file>
</transaction>
  • <file>: identifica o elemento de assunto.
  • <fileStatus>: identifica a operação no elemento.

Arquivos de propriedades

Todos os arquivos de propriedades são arquivos de texto simples. Linhas que começam com # são comentários. Os agentes de origem e de destino usam sintaxes diferentes para os arquivos de propriedades.

Arquivo de propriedades do agente de origem

O arquivo de propriedades define os principais parâmetros operacionais para o agente de origem. Ele deve estar na mesma pasta que o executável do agente de origem. A sintaxe é ilustrada pelo exemplo a seguir.

#
# File system path to mailbox
# mailbox_dir=<full path to mailbox directory>
mailbox_dir=C:\\mailbox\\
#
# Maximum number of transactions per package
# transactions_per_package=<transaction max>>
transactions_per_package=100
#
# folders to exclude from the migration
Foundation_folders_to_exclude=\\this\\, \\that\\, \\the_other\\
#
# How often to check a migrated depot for new transactions
# refresh_transaction_mins=<period>
refresh_transaction_mins=5
#
# Who to send e-mail notifications to?
# email_receivers=<email addr>[, <email_addr> …]
email_receivers=person1@in.ibm.com,person2@us.ibm.com
#
# The level of log messages to be logged for each depot migration. This property 
# will not affect the common logger level which is always set to ALL.
# logging_level=<ALL | FINE | INFO | WARNING | SEVERE>
logging_level=INFO
#
# The number of log files to write before rolling over (must be at least 1)
# log_file_count=<number of files>
log_file_count=50
#
# The maximum size of each log file in bytes (must be at least 0)
# log_file_size=<size of bytes>
log_file_size=500000

Arquivo de propriedades do agente de destino

Esse arquivo define os principais parâmetros operacionais para o agente de destino. Ele deve estar na mesma pasta que o executável do agente de destino. A sintaxe é ilustrada pelo exemplo a seguir.

#
# Connection information for the Jazz Server
# rtc_repository_Address=<jazz repository URI>
# rtc_username=<userID>
# rtc_password=<password>
rtc_repository_Address=https\://jazz705.hursley.ibm.com\:9443/ccm
rtc_username=Y9AB2Y866@nomail.relay.ibm.com
rtc_password=xxxxxxxx
#
# Scheduled down-time for the Jazz Server
# downtime=<{24 hour time}-{24 hour time}>
downtime=03:00-04:00
#
# File system path to mailbox
# mailbox_dir=<full path to mailbox directory>
mailbox_dir=C:\\mailbox\\
#
# RTC Process Template
# rtc_process_template_id=”<template>.process.ibm.com”
process_template=”scrum2.process.ibm.com”
#
# How often to check for new depot mailboxes
# refresh_depots_mins=<period>
refresh_depots_mins=5
#
# How often to check a migrated depot mailbox for new packages
# refresh_transaction_mins=<period>
refresh_transaction_mins=5
#
# Who to send e-mail notifications to?
# email_receivers=<email addr>[, <email_addr> …]
email_receivers=person1@in.ibm.com,person2@us.ibm.com
#
# The level of log messages to be logged for each depot migration. This property 
# will not affect the common logger level which is always set to ALL.
# logging_level=<ALL | FINE | INFO | WARNING | SEVERE>
logging_level=INFO
#
# The number of log files to write before rolling over (must be at least 1)
# log_file_count=<number of files>
log_file_count=50
#
# The maximum size of each log file in bytes (must be at least 0)
# log_file_size=<size of bytes>
log_file_size=500000

Tanto os agentes de origem quanto os de destino criam os arquivos de log. Esses arquivos são salvos no mesmo sistema de arquivos compartilhado que a caixa de correio. As entradas nos arquivos de log têm a seguinte sintaxe:

{Date} {SourceClassName} {SourceMethodName} {Log Message Level} {Log Message}
  • Date: registro de data e hora para a entrada.
  • SourceClassName e SourceMethodName: identificam um local no código.
  • Log Message Level:
    • FINE: registra as transações em detalhes.
    • INFO: registra transações em um alto nível.
    • WARNING: registra apenas erros não fatais.
    • SEVERE: registra apenas erros fatais (com rastreio de pilha).
  • Log Message: cadeia de caractere de texto.

Descrição do agente de origem

O agente de origem, como mostra a Figura 5, é um aplicativo Java que executa na máquina cliente de origem. Ele é controlado por meio de uma interface com o usuário simples e com parâmetros globais fornecidos por um arquivo de propriedades.

Figura 5. Depósitos executando o agente de origem
List of depots in the source agent
List of depots in the source agent

A máquina cliente de origem deve ter acesso de rede ao servidor AccuRev. O cliente AccuRev também deve estar em execução na máquina cliente de origem. Ele deve ter efetuado login no repositório do AccuRev. O arquivo de propriedades do agente de origem deve estar no mesmo diretório que o executável.

O principal objetivo do agente de origem é criar um fluxo de pacotes contendo descritos de transação que direcionem o agente de destino para a construção de uma área de projeto no repositório do Rational Team Concert de destino.

O agente de origem realiza essa tarefa analisando o histórico do depósito do AccuRev, que é a sequência de transações do AccuRev que foram usadas para construir o depósito.

O agente de origem é capaz de processar vários depósitos em paralelo.
Apenas as seguintes transações do AccuRev são convertidas para descritores de transação:

  • chstream
  • defunct
  • mkstream
  • move
  • promote
  • purge (quando usado em um fluxo)
  • undefunct

O comando hist do AccuRev fornece o histórico do depósito. O comando cat permite extrair elementos controlados por versão do repositório e adicioná-los ao pacote.

Descrição do agente de destino

O agente de destino, como mostra a Figura 6, é um aplicativo Java executado na máquina cliente de destino. Ele é controlado por meio de uma interface com o usuário simples e com parâmetros globais fornecidos por um arquivo de propriedades.

Figura 6. Depósitos executando o agente de origem
List of depots in the source agent
List of depots in the source agent

A máquina cliente de destino deve ter acesso de rede ao servidor Rational Team Concert. O ID do aplicativo definido no arquivo de propriedades do agente de destino deve estar no servidor Rational Team Concert e a senha deve ser válida. O modelo de processo deve ser implementado no servidor Rational Team Concert. O arquivo de propriedades do agente de destino deve estar no mesmo diretório que o executável.

O principal objetivo do agente de destino é processar em sequência os pacotes que aparecem em uma caixa de correio do depósito. O agente de destino é capaz de processar várias caixas de correio do depósito em paralelo. Ele recria o depósito AccuRev como uma área do projeto Rational Team Concert aplicando transações genéricas encontradas no pacote.

Observação: o nome do depósito AccuRev é usado no nome da caixa de correio do depósito. O nome da área do projeto Rational Team Concert de destino é obtido do nome da caixa de correio do depósito. A área do projeto Rational Team Concert, portanto, tem o mesmo nome que o depósito AccuRev. O agente de destino usa a API Rational Team Concert Java para sintetizar uma transação do Rational Team Concert de cada transação genérica.

Comunicação entre os agentes de origem e destino

A interface para toda a comunicação entre os agentes de origem e destino é uma pasta do sistema de arquivos compartilhada chamada Mailbox, como mostra a Figura 7. A caixa de correio contém uma pasta de Logs e várias pastas de caixa de correio do depósito.

Figura 7. MailBox
MailBox folder

Plataformas do cliente de origem e destino

Os agentes de origem e destino são independentes de plataforma. Porém, eles devem ser executados na mesma plataforma, como Windows™ ou Linux®, para evitar problemas resultantes de diferentes de plataforma em arquivos de texto como:

  • Separadores de caminho:
    \ (Windows
    / em Linux
  • Marcadores de fim de linha:
    <CR><LF> (Windows)
    <LF> (Linux)

Coordenação de agentes de origem e destino

Por design, os agentes de origem e destino operam de maneira assíncrona. A coordenação dos agentes é uma atividade manual. As duas interfaces do usuário tornam possível iniciar, parar e redefinir migrações de maneira independente.

Iniciar uma migração de maneira independente em qualquer agente não é um problema. O efeito de parar uma migração é diferente dependendo de ela ser parada no agente de destino ou no de origem.

  • Se a migração for parada no agente de destino, o agente de origem continuará adicionando pacotes à caixa de correio até concluir a migração ou ser forçado a pausar por a caixa de correio estar cheia.
  • Se for interrompida no agente de origem, o agente de destino continuará processando os pacotes da caixa de correio até ela estar vazia.

Em qualquer agente, a migração somente pode ser redefinida se já tiver sido parada. Porém, é necessário ter cuidado para apenas redefinir a migração se ela tiver sido parada em outro agente. O efeito de parar uma migração é diferente dependendo de ela ser parada no agente de destino ou no de origem.

  • Se a migração for redefinida no agente de origem, o status da migração se torna Resetting. As variáveis de estado da migração salvas no arquivo de propriedades são redefinidas, as pastas no pacote na caixa de correio são limpas e o status da migração se torna Ready. Quando a migração é reiniciada, ela processa o histórico do depósito desde o início novamente.
  • Se a migração for redefinida no agente de destino, o status da migração se torna Resetting. As variáveis de estado da migração salvas no arquivo de propriedades são redefinidas e a área do projeto Rational Team Concert é renomeada (anexando Archived e um registro de data e hora) antes de ser arquivada. O status de migração então é alterado para Ready. Quando a migração é reiniciada, os pacotes são processados do início novamente.

Notificações por email

Os arquivos de propriedades do agente de origem e destino contêm uma lista de email_receivers. Isso é uma lista separada por vírgula de endereços de email. Os agentes enviarão emails para esses endereços no caso de uma migração parar devido a um erro fatal.

Solução de problemas do agente de origem

Para solucionar problemas do agente de origem, use as seguintes dicas e soluções.

Nem todas as áreas de trabalho são migradas

As áreas de trabalho podem não ser migradas por dois motivos:

  • As áreas de trabalho do AccuRev têm duas partes. Se o fluxo da área de trabalho existir no repositório, mas a árvore da área de trabalho existir no sistema de arquivos da estação de trabalho do usuário, a árvore da área de trabalho está inacessível ao sistema de migração.
  • Todos os usuários do AccuRev podem ter muitas áreas de trabalho. A migração de todas essas áreas de trabalho aumenta significativamente o esforço de migração, com isso, algumas áreas de trabalho do usuário não podem ser migradas pelo sistema de migração.

Se a mesma estação de trabalho for usada para acessar tanto o AccuRev quanto o Rational Team Concert, os usuários podem migrar as próprias áreas de trabalho da seguinte maneira:

  1. Crie uma área de trabalho do Rational Team Concert, que consiste em uma área de trabalho do repositório e uma área de trabalho pessoal.
  2. Carregue a área de trabalho do Rational Team Concert do fluxo do Rational Team Concert que está sendo migrado do fluxo AccuRev que sustenta a área de trabalho do AccuRev do usuário.
  3. Substitua os artefatos na área de trabalho pessoal do Rational Team Concert pelos artefatos ativos da árvore da área de trabalho do AccuRev.
  4. Faça o check-in do conjunto de alterações resultante.

Transações do AccuRev ignoradas

O agente de origem não processa os seguintes tipos de transação do AccuRev porque elas não são relevantes à migração.

TransaçãoDescrição
archiveUsada para preparar arquivos para transferir ao armazenamento offline.
check outUsado para bloquear um artefato para atualização exclusiva.
compressForma alternativa para archive.
defcompUsado para especificar que arquivos incluir/excluir ao atualizar uma área de trabalho.
dispatchUsado para passar informações ao AccuWork.
purgeCancela alterações feitas na área de trabalho do usuário. O agente de origem manipula a limpeza quando se aplica a um fluxo.
unarchiveReverte o efeito de archive.

O add, move, defunct, undefunct são processados como parte de transações promote.

As transações ocorrem fora de ordem

AccuRev tem um recurso chamado TimeSafe que essencialmente permite que a configuração do repositório seja reconstruída para qualquer ponto no tempo. Isso significa que muitos comandos incluem um parâmetro time spec .

Por exemplo, mkstream pega uma time spec, o que permite criar um fluxo de captura instantânea que contenha a configuração do fluxo a qualquer momento entre a criação do fluxo e o momento atual. Quando a transação mkstream vai para o histórico do depósito, ela recebe um carimbo de data e hora com o horário atual. A time spec é fornecida pela tag de tempo de base na transação.

O Rational Team Concert não tem esse recurso, portanto, o agente de origem inicia uma migração obtendo o histórico completo do depósito. Ele realiza uma varredura inicial do histórico buscando transações fora de ordem, que são transações em que o tempo de base é diferente do registro de data e hora. Isso é armazenado em uma lista FIFO.

O agente de origem então começa a processar o histórico do depósito. A próxima transação a ser processada é determinada comparando o registro de data e hora da próxima transação no histórico do depósito com o tempo de base da transação no topo da FIFO. A que for mais antiga é processada.

O efeito de rede é tal que o fluxo de transações apresentado ao agente de destino é ordenado por tempo de base. Para o exemplo fornecido, a transação mkstream é movida para que o agente de destino possa executá-la no presente momento.

Executando novamente uma migração

Durante uma migração, o agente de origem cria pacotes do histórico de transações AccuRev. Cada pacote contém um arquivo de descrição de pacote e uma pasta de transação para cada transação que atualizou um ou mais arquivos de origem. A pasta de transação é preenchida com as versões adequadas dos arquivos de origem.

A extração de versões de arquivo específicas é o elemento demorado de uma migração. Se uma migração for interrompida e reiniciada, os arquivos de descrição de pacote são gerados novamente. Antes de extrair uma versão de arquivo, o agente de origem verifica a pasta de transação para ver se a versão já está presente. Se estiver, a extração é ignorada.

Esse processo torna a migração executada novamente muito mais rápida do que a migração original.

Manipulação de exceção

Muitas exceções podem fazer uma migração falhar:

  • Perda de acesso à pasta da caixa de correio.
  • A caixa de correio do depósito está cheia.
  • Perda de conectividade com o AccuRev Server.

Em vez de tentar recuperar-se de todos os tipos de falha, o agente de origem simplesmente registra o evento e interrompe a migração. Intervenção manual é necessária para reiniciar.

Descrição das operações do agente de destino

No Rational Team Concert, certas operações e atributos do agente de destino são gerenciados de modo diferente que no AccuRev. Para acomodar as diferenças, configure o Rational Team Concert para manipular essas configurações específicas do AccuRev.

ID do aplicativo

O agente de destino opera o Rational Team Concert usando um ID de aplicativo. Atualizações ao repositório do Rational Team Concert feitas pelo sistema de migração são atribuídas a esse ID do usuário.

De modo similar, as atualizações do repositório Rational Team Concert recebem um registro de data e hora de acordo com quando são aplicadas pelo agente de destino.

Retenção de informações do AccuRev

Algumas informações do repositório AccuRev não podem ser diretamente aplicadas ao repositório do Rational Team Concert, por exemplo:

  • ID do usuário do AccuRev responsável por uma transação.
  • ID da transação do AccuRev.
  • Registro de data e hora do AccuRev para uma transação.
  • O comentário aplicado a uma transação do AccuRev.
  • Número de edição do AccuWork (ou número de registro do HP Quality Center, ou ambos) associado à transação.

Essas informações são enviadas para o agente de destino no descritor da transação e salvas no Rational Team Concert como um comentário Change Set ou por propriedades de arquivo.

Fluxos de passagem

O AccuRev tem suporte para um tipo especial de fluxo chamado fluxo de passagem. As alterações promovidas para um fluxo de passagem fluem direto para o fluxo pai. Os fluxos de passagem são principalmente usados para gerenciar a hierarquia de fluxo. Redefinir o pai de um fluxo de passagem é mais fácil que redefinir o pai individualmente de todos os fluxos e áreas de trabalho que fluem para ele.

O Rational Team Concert não tem suporte para fluxos de passagem. Em vez disso, o agente de destino lida com eles da seguinte maneira. A transação mkstream indica que o fluxo é de passagem. O agente de destino faz o fluxo, mas anexa _passthrough ao nome do fluxo.

O resultado é que o fluxo aparece na hierarquia de fluxos da área do projeto Rational Team Concert e é identificado como de passagem. Com esse método, é possível excluí-lo mais tarde.

Fluxos ocultos

A GUI do AccuRev permite ocultar os fluxos da visualização. Essa é uma conveniência de apresentação, em vez de um atributo de um fluxo.

No Rational Team Concert, cada fluxo tem um atributo de visibility . Isso torna o fluxo visível a Áreas da Equipe específicas.

O sistema de migração trata fluxos ocultos como qualquer outro fluxo. Um fluxo oculto no AccuRev se torna visível na área do projeto Rational Team Concert. O fluxo pode ser ocultado ou removido no Rational Team Concert como uma atividade pós-migração.

Herança

No AccuRev, promover um elemento (um arquivo ou diretório) o torna ativo no fluxo de destino e inativo na área de trabalho ou fluxo de origem. Se o fluxo de destino for parte de uma hierarquia, o elemento ativo fica imediatamente disponível ao primeiro nível de fluxos dinâmicos descendentes.

O elemento é automaticamente herdado por um fluxo descendente se estiver inativo nesse fluxo. Depois de ser herdado, um elemento se torna ativo no fluxo e pode ser herdado pelo próximo nível de fluxos descendentes.

O Rational Team Concert não flui alterações através da hierarquia de fluxo dessa maneira, assim, o agente de destino deve simular o comportamento do AccuRev. O agente de destino executa uma transação promote genérica para o fluxo de destino como uma transação deliver do Rational Team Concert. Essa transação tem um conjunto de alterações por elemento, mas a entrega é atômica.

Esses conjuntos de mudanças se tornam alterações recebidas pendentes para qualquer fluxo que vá para o fluxo de destino. O agente de destino então inspeciona esses fluxos e entrega os conjuntos de alterações quando adequado. Esse processo continua descendo na hierarquia do fluxo.

Manipulação de exceção

As seguintes condições de exceção podem causar a falha de uma migração.

  • Perda de acesso à pasta da caixa de correio
  • Perda de conectividade com o servidor Jazz ou outro serviço crucial.

Em vez de tentar recuperar-se de todos os tipos de falha, o agente de origem simplesmente registra o evento e interrompe a migração. Intervenção manual é necessária para reiniciar.

Tarefas pós-migração

O sistema de migração cria e preenche uma área do projeto Rational Team Concert com as informações encontradas no depósito do AccuRev. Todas as áreas do projeto são criadas a partir do mesmo modelo. Porém, há alguns aspectos da configuração do Rational Team Concert que não podem ser manipulados através de um modelo.

  • Área do projeto: para concluir a configuração da área do projeto, é necessário atribuir administradores e membros do projeto.
  • Áreas da equipe: para concluir a configuração de cada área da equipe, é necessário atribuir membros da equipe.
  • Áreas do projeto: para concluir a configuração do projeto, é necessário atribuir administradores e membros do projeto.
  • Área da equipe: para concluir a configuração da área da equipe, é necessário atribuir membros da equipe.

Depois da migração, realize as seguintes verificações pós-migração nos fluxos.

  • A hierarquia do fluxo do Rational Team Concert corresponde à hierarquia do fluxo do AccuRev?
  • Cada fluxo do Rational Team Concert tem o mesmo conteúdo de fluxo que o do AccuRev equivalente?
  • Os conjuntos de alterações de saída de cada fluxo do Rational Team Concert correspondem à lista de arquivos ativos no fluxo do AccuRev?
  • Para concluir a configuração da hierarquia do fluxo:
    • Defina os atributos de visibilidade e propriedade do fluxo do Rational Team Concert.
    • Exclua fluxos de passagem (opcional).
    • Exclua ou altere a propriedade e a visibilidade para a área da equipe dos administradores apenas para os fluxos que agora estão ocultos no AccuRev, mas presentes no Rational Team Concert (opcional). Não há como ocultar fluxos no Rational Team Concert, portanto, verifique se os destinos do fluxo foram ajustados adequadamente.

Conclusão

Este artigo explicou como migrar o código fonte do AccuRev para o Rational Team Concert com e sem histórico. Descreveu algumas diferentes no desenvolvimento dos fluxos em cada ferramenta e apresentou etapas que mostram como acomodar essas diferenças. Verificações pós-migração garantem que a migração seja bem-sucedida.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=979387
ArticleTitle=Do AccuRev para o Rational Team Concert
publish-date=05202014