Desenvolvimento de equipe e gerenciamento de artefato no WebSphere Integration Developer v6.2

Este artigo discute gerenciamento de controle de origem e versão de módulo no WID v6.2. Ele é uma versão atualizada de desenvolvimento de equipe com o WebSphere Integration Developer e o WebSphere Process Server de 2006, que foi baseada no WID v6.0.2. Usamos Subversion como ferramenta de gerenciamento de controle de origem.

Introdução

Neste documento, discutimos os procedimentos de source control management (SCM) em relação ao WebSphere Integration Developer (WID) v6.2. Impulsionamos as capacidades de desenvolvimento de equipe do WID e do Eclipse usando Subversion como mecanismo de gerenciamento remoto de controle de origem.

Iniciamos com uma visão geral dos princípios básicos de desenvolvimento de equipe e discutimos a estrutura de um módulo WID. São examinados procedimentos completos que demonstram como interagir com o servidor Subversion no WID, incluindo os elementos essenciais de gerenciamento de controle de origem do Subversion. Tópicos avançados do Subversion também são discutidos.

Supomos que você tenha alguma experiência com WID e os princípios básicos de gerenciamento de controle de origem. Este artigo é baseado estritamente na interação do lado do cliente entre WID e Subversion; a configuração do servidor é um tópico avançado que vai além do escopo desta discussão.


Visão geral de um projeto WID e desenvolvimento colaborativo

Estrutura de projeto WID

Cada aplicativo WID consiste em um módulo SCA e um conjunto opcional de dependências de biblioteca de serviço. O módulo SCA contém os principais artefatos necessários para implementar e executar o aplicativo. Os artefatos principais podem incluir—mas não estão limitados a—objetos de negócio, interfaces, mapas e processos de negócio. Quando o aplicativo é implementado e instalado, o código Java é gerado com base na lógica do artefato principal.

Cada módulo SCA também contém um conjunto de módulos gerados temporários. Como os módulos temporários definem as dependências de JEE e um conteúdo opcional da Web, eles geralmente não precisam ser modificados pelo usuário. Como os módulos temporários não contêm lógica escrita de BPM, eles não são visíveis na perspectiva do Business Integration, mas podem ser visualizados na perspectiva de JEE ou Resource.

Os nomes dos módulos temporários são baseados no nome de base do módulo SCA. Por exemplo, suponha que um módulo SCA, HelloWorld, exista no espaço de trabalho WID. Depois que o módulo SCA é construído, os seguintes módulos temporários serão criados:

  • HelloWorldApp
  • HelloWorldEJB
  • HelloWorldWeb
Figura 1. Módulos temporários de um aplicativo WID
Módulos temporários de um aplicativo WID

Observe que ModuleNameWeb só será criado se o módulo SCA possuir ligações de terminal de serviço da Web definidas no módulo SCA. Em geral, somente o módulo SCA e bibliotecas dependentes precisam ser gerenciados no controle de origem, mas em alguns casos também pode ser necessário gerenciar os módulos temporários.

Artefatos escritos e gerados

Os artefatos que são criados pelo usuário no WID são chamados de escritos. Se o usuário cria uma nova interface WSDL ou objeto de negócio, um arquivo correspondente .wsdl ou .xsd existirá no espaço de trabalho. Em alguns casos, um tipo de artefato único consiste em múltiplos arquivos auxiliares. Por exemplo, quando um novo processo BPEL é criado, alguns arquivos escritos, incluindo .bpel, .bpelex e Artifacts.wsdl, são criados no espaço de trabalho. Cada um desses arquivos é escrito, já que são todos necessários para que o módulo seja construído com sucesso.

Depois que um módulo é construído no WID, um código Java é gerado para os artefatos escritos durante o processo de implementação. Artefatos gerados normalmente são classes Java baseadas na lógica definida nos artefatos escritos de BPM. Como os artefatos gerados do WID não são necessários durante o desenvolvimento do aplicativo, não precisam ser gerenciados no controle de origem.

No WID v6.0.2, há muitas inconsistências entre artefatos escritos e gerados. Houve a geração de algum artefato durante a construção, enquanto outros artefatos foram gerados durante a instalação do aplicativo. Esse processo foi muito aprimorado no WID v6.2, já que toda geração de artefato ocorre agora durante a implementação e instalação do aplicativo. Portanto, nenhum arquivo Java gerado aparece em um módulo SCA do WID v6.2.

Diferentemente dos módulos SCA, os módulos temporários são de certa forma únicos. Os módulos temporários aparecem no espaço de trabalho depois que o módulo SCA é construído. Por causa disso, os módulos temporários não precisam ser gerenciados no SCM, desde que não contenham nenhum conteúdo customizado ou mudanças no descritor de implementação JEE. Se conteúdo escrito for adicionado a um módulo temporário ou forem feitas mudanças de implementação JEE, então os módulos temporários afetados também precisarão ser gerenciados no controle de origem para que essas mudanças sejam preservadas. Se for adicionado conteúdo customizado ao módulo temporário da Web, como uma página HTML ou JSP, o módulo ModuleNameWeb precisará ser gerenciado no repositório remoto de controle de origem. Para evitar confusão, pense em criar um módulo da Web separado para qualquer conteúdo customizado da Web, em vez de contar com o módulo temporário ModuleNameWeb.

Propriedades derivadas x propriedades não derivadas

Intimamente ligadas a artefatos escritos e gerados estão as propriedades de derivação de um artefato. Um artefato pode ser derivado ou não derivado, conforme especificado nas propriedades de derivação do arquivo na visualização Physical Resources ou na perspectiva Resource, como mostrado abaixo.

Figura 2. Propriedades de derivação de um artefato
Propriedades de derivação de um artefato

Em alguns produtos SCM, como CVS, as propriedades de derivação de uma pasta ou arquivo determinam se um artefato é ou não gerenciado no sistema SCM. Embora o CVS ignore todos os artefatos derivados, o Subversion não segue esse padrão. Cada arquivo no espaço de trabalho, independentemente de suas propriedades de derivação, será consolidado no repositório por padrão. É possível definir filtros nas preferências do Subversion para excluir arquivos, para que não sejam gerenciados pelo controle de origem. Felizmente, no WID v6.2 normalmente isso é desnecessário, já que a geração de artefato não ocorre até a implementação ou instalação do aplicativo.

Artefatos derivados não aparecem nos módulos SCA do WID v6.2, assim as propriedades de derivação de um artefato nunca devem ser modificadas. Em versões anteriores do WID, as propriedades de derivação de um artefato podiam ser mudadas sem muitas consequências, mas o WID v6.2 é menos indulgente. Qualquer artefato específico de WPS que tem sua propriedade mudada para derivado é imediatamente excluído do espaço de trabalho pelos construtores de WID. Isso acontece porque o WID entende que os artefatos derivados são gerados, e artefatos gerados só devem estar presentes durante o momento de implementação ou instalação. Portanto, se um artefato é mudado para derivado, o WID presume que esse arquivo seja gerado e, do mesmo modo, não deve existir no espaço de trabalho.

A lição aqui é muito simples: as propriedades de derivação dos artefatos do WID v6.2 são rigorosamente reforçadas no módulo SCA principal e nunca devem ser modificadas.

Editor de implementação de módulo (e como ele se relaciona com o módulo de Aplicativo)

Em versões anteriores do WID, as propriedades de implementação do módulo, como segurança de serviços da Web e modificações ao descritor de implementação JEE, tinham que ser feitas no descritor de implementação do módulo de Aplicativo temporário.

Isso causava dois problemas. Primeiro, uma nova implementação de módulo sobrescreve qualquer modificação customizada feita em ModuleNameApp, de modo que as mudanças customizadas tinham que ser reconfiguradas com frequência. Segundo, ao fazer essas mudanças, o módulo de Aplicativo continha mudanças escritas, e portanto tinha de ser gerenciado no controle de origem. De forma ideal, queremos limitar os módulos e artefatos no controle de origem àqueles que são estritamente escritos.

A partir do WID v6.2, várias propriedades de implementação agora podem ser configuradas através do editor de implementação de módulo localizado no módulo SCA principal. O editor de implementação de módulo salva mudanças no ibm-deploy.scaj2ee no módulo SCA, que se equipara ao descritor de implementação JEE durante a implementação. Embora o editor de implementação de módulo não possua cada propriedade do descritor de implementação, na maioria dos casos ele é suficiente para as necessidades de implementação.

O editor de implementação de módulo pode ser aberto clicando com o botão direito no nome do módulo e selecionando Open Deployment Editor.

Figura 3. O editor de implementação de módulo
O editor de implementação de módulo

Desenvolvimento de equipe com WID e Eclipse

Plug-ins WID para cliente Subversion

Para interagir com o servidor Subversion, é preciso instalar um plug-in cliente em seu ambiente WID. Há dois plug-ins cliente Subversion que podem ser usados no WID: Subclipse e Subversive. Embora os dois plug-ins possuam conjuntos de recursos semelhantes, dizem que o Subversive é o caminho estratégico oficial avançado para o Eclipse; portanto, usamos o plug-in Subversive para os cenários discutidos neste documento.

O plug-in cliente Subversion não está incluído na lista de plug-ins padrão do Eclipse ou WID, então ele precisa ser instalado. Depois que o plug-in for instalado, será possível interagir inteiramente com o repositório Subversion a partir do WID.

As seções de Anexos e de Referências possuem algumas informações sobre a configuração de plug-in cliente do Subversion.

Perspectivas e visualização no WID

Há várias perspectivas e visualizações no WID e Eclipse que são úteis para o desenvolvimento colaborativo. As quatro a seguir são essenciais para desenvolvimento de equipe:

  • Business Integration
  • Resource
  • Team Synchronizing
  • SVN Repository Exploring (Observe que se você não estiver usando o Subversion, o nome desta perspectiva pode variar)
Figura 4. Perspectivas usadas para desenvolvimento de equipe no WID
Perspectivas usadas para desenvolvimento de equipe no WID

Perspectiva Business Integration

A perspectiva Business Integration é a parte essencial do WID, já que a integração de design de artefato, desenvolvimento e componente acontece aqui. Além disso, a maioria das atividades de desenvolvimento de equipe (verificação, consolidação, atualização) pode ser executada através dessa visualização.

Visualização Physical Resources
Como parte da perspectiva Business Integration, a visualização Physical Resources lista os artefatos e recursos relevantes para os módulos e bibliotecas WID. A visualização Physical Resources é semelhante à visualização Project Explorer da perspectiva Resource, exceto pelo fato de que somente os módulos SCA são mostrados—módulos temporários não são mostrados.

Embora não tão significativa no v6.2, a visualização Business Integration inclui uma opção Show Files que exibe todos os arquivos escritos de um artefato. Por exemplo, um processo BPEL salva sua lógica de fluxo de processo em um arquivo .bpel, mas há outros arquivos auxiliares–.bpelex, .mon e Artifacts.wsdl—que são necessários para que o processo BPEL seja construído apropriadamente. A opção Show Files irá destacar todos os quatro arquivos.

Use a opção Show Files como segue:

  1. A partir da visualização Business Integration, clique com o botão direito no artefato e selecione Show Files.
Figura 5. Mostrar arquivos
Mostrar arquivos
  1. Alguns artefatos, como processos BPEL, possuem múltiplos arquivos auxiliares. Usando a opção Show Files, você verá a seguinte janela. O filtro Artifact Secondary Files mostra somente o artefato principal. Se clicar em Yes, esse filtro será desativado e todos os arquivos auxiliares serão destacados.
Figura 6. Filtro de desativação
Filtro de desativação
  1. Observe que os arquivos são destacados na visualização Physical Resources.
Figura 7. Recursos HelloWorldProcess
Recursos HelloWorldProcess

Perspectiva Resource

A visualização Project Explorer listada na perspectiva Resource vem com o Eclipse e lista cada módulo e artefato no espaço de trabalho, incluindo todos os módulos temporários.

Perspectiva Team Synchronizing

A visualização Synchronize na perspectiva Team Synchronizing permite sincronizar o espaço de trabalho com o repositório remoto Ela exibirá qualquer mudança emitida ou recebida e pode identificar qualquer conflito de mesclagem apropriado.

Perspectiva SVN Repository Exploring

A perspectiva SVN Repository Exploring lista todos os módulos ou projetos que são gerenciados no Subversion no momento. Se o seu projeto usa um provedor SCM diferente, então pode existir uma perspectiva semelhante.

Projetos na perspectiva SVN Repository Exploring são listados de acordo com o número mais recente de revisão, mas revisões mais antigas de módulos também podem ser visualizadas e verificadas a partir do controle de origem. Ramificações ou tags que foram definidas para um módulo específico também podem ser verificadas através da visualização SVN Repositories. Também é possível usar a visualização History para ver a série de mudanças de um módulo.

Visualização SVN Repositories
Essa é a principal visualização na perspectiva SVN Repository Exploring. A árvore de revisão HEAD é listada por padrão e contém todos os módulos subjacentes com seus respectivos troncos, ramificações e tags listados no repositório.

Visualização SVN Repository Browser
Semelhante à visualização SVN Repositories, essa visualização mostra o último modificado por data e hora, proprietário do artefato e tamanho do arquivo.

Visualização History
A visualização History exibe todo o histórico de revisão e log de mudanças de um dado módulo ou artefato. Essa visualização é semelhante à do SVN Repository Browser, exceto que os artefatos são classificados por número de revisão em vez de por nome de módulo.

Desenvolvimento de equipe com mediações e módulos WESB

Ao criar um fluxo de mediação no WID v6.2, há a opção de otimizar o fluxo de mediação para desenvolvimento de equipe. Por padrão, o fluxo de mediação é salvo como um único arquivo .medflow file para todas as operações. Assim, se houver um fluxo com cinco operações, toda a lógica estará em um único arquivo .medflow.

Se a lógica de fluxo de mediação é salva como arquivos múltiplos, haverá um arquivo .medflow para cada mapeamento de operação. Isso é benéfico para desenvolvimento colaborativo, já que um fluxo de operação pode ser atribuído a cada desenvolvedor. Observe que se o fluxo de mediação usa somente uma única operação, não há benefício em ativar a opção desenvolvimento colaborativo.

Figura 8. Opções de desenvolvimento de equipe de fluxo de mediação
Opções de desenvolvimento de equipe de fluxo de mediação

Há algumas estipulações ao salvar mediações como fluxos múltiplos:

  • Os mapeamentos de operação de fluxo de mediação devem estar no mesmo módulo, independentemente se a opção desenvolvimento de equipe está ativada ou não. Não crie um módulo separado para cada fluxo de operação.
  • Todos os usuários devem verificar o módulo a partir do controle de origem. Como cada operação possui seu próprio arquivo .medflow, conflitos de mesclagem para lógica de fluxo de mediação não podem ocorrer. Conflitos de mesclagem podem ocorrer, no entanto, se artefatos de fluxo de não mediação forem modificados por múltiplos usuários.

Recomendações gerais ao se trabalhar em um ambiente de equipe

Gerenciando módulos SCA, bibliotecas e módulos temporários

  • A funcionalidade de desenvolvimento de equipe foi amplamente aprimorada no WID v6.2. Praticamente toda interação com o servidor SCM pode ser feita na perspectiva Business Integration. O paradigma derivado x não derivado também foi inacreditavelmente simplificado. Todos os artefatos no módulo de serviço agora são escritos (não derivados), enquanto todos os artefatos gerados e classes Java—como os arquivos criados a partir de um aplicativo BPEL—são gerados no momento da implementação ou instalação do aplicativo.
  • Ao usar bibliotecas, lembre-se de que mudar um BO ou WSDL compartilhado pode ter efeitos colaterais inesperados em outros módulos ou componentes que também usam essa biblioteca.
  • Módulos temporários são criados pelos construtores do WID durante a implementação, e normalmente não precisam ser gerenciados no controle de origem.
  • O módulo temporário ModuleNameApp pode ter de ser gerenciado no controle de versão em casos raros em que o editor de implementação de módulo perde um recurso que existe de outro modo no descritor de implementação JEE ModuleNameApp.
  • O módulo temporário ModuleNameWeb também pode ter de ser gerenciado no controle de origem se contiver código customizado, como interfaces cliente da Web. Em casos em que um conteúdo customizado da Web é adicionado, pense em criar um projeto da Web separado para conteúdo da Web customizado dinâmico. Do contrário, o módulo ModuleNameWeb gerado terá de ser gerenciado no controle de origem.

Propriedades de derivação de um artefato

  • Nunca mude explicitamente o sinalizador derivado nas propriedades do artefato. Diferente do v6.0.2, as propriedades de derivação são mais transparentes no v6.2 e não devem ser modificadas pelo usuário. Na verdade, se um artefato WID não derivado (isto é, escrito) é alterado para derivado, o WID excluirá permanentemente o arquivo do módulo SCA. Isso acontece porque os construtores do WID v6.2 presumem que um arquivo derivado é um arquivo gerado. Sob a perspectiva do WID, arquivos gerados só podem ser criados no momento da implementação ou instalação. Portanto, o WID supõe que esse artefato derivado está lá por engano e o exclui do espaço de trabalho. Observe que esse comportamento só existe para módulos SCA; outros módulos, como projetos da Web ou Java, podem conter artefatos derivados, que não serão removidos durante a implementação.
  • Pense em usar a opção Show Files na visualização Business Integration para ver uma lista de arquivos auxiliares de um dado componente.

Módulos de registro de saída do controle de versão

  • Ao trabalhar com um módulo gerenciado no SCM, certifique-se de verificar o módulo inteiro a partir do repositório remoto. Nunca verifique um artefato individual, como um único arquivo WSDL ou XSD, a partir de um módulo gerenciado no controle de origem.
  • Embora um módulo possa ser verificado por múltiplos usuários simultaneamente, somente uma pessoa deveria ter acesso de gravação ao módulo a qualquer momento. Reforçar essas práticas pode prevenir conflitos de mesclagem irritantes. Se precisar fazer mudanças em um módulo e quiser evitar que outros usuários realizem qualquer mudança, pense em usar o bloqueio do módulo para acesso de gravação exclusivo.

Sincronizando com o repositório remoto

  • Sempre sincronize mudanças com o repositório antes de qualquer consolidação ou atualização. Embora uma sincronização completa não seja absolutamente necessária antes de consolidar ou atualizar artefatos, fazer isso não só fornecerá uma lista completa de mudanças, mas também pode evitar uma sobrescrição inadvertida de artefatos modificados salva por outros usuários.
  • Se ocorrerem conflitos de sincronização, os desenvolvedores devem mesclar manualmente as mudanças em vez de confiar em técnicas de mesclagem baseadas em texto que são usadas nas ferramentas de mesclagem do WID. Embora a fusão baseada em texto funcione bem com código Java, essa prática não é tão útil para artefatos WID baseados em XML. Se usar as ferramentas de mesclagem para combinar dois processos BPEL, você estará mesclando código XML bruto ou texto simples, o que é contrário ao editores GUI padrão que existem em muitos artefatos WID.
  • Quando um artefato é removido da cópia de trabalho local e o módulo é consolidado no repositório, ele também será removido da revisão HEAD. No entanto, dependendo do conjunto de recursos SCM, o artefato pode ainda estar no repositório em um conjunto anterior de revisão.

Versão de módulo

  • Atente-se para o fato de que os módulos são "sensíveis a versão" quando são implementados através do serviceDeploy. Módulos com versão exportados como arquivos EAR através do WID ou adicionado ao UTE através de Add/Remove Projects não consideram as propriedades de um módulo com versão.
  • Pense em gerenciar a versão inicial do módulo (isto é, 1.0.0) no tronco no controle de origem. Todas as versões subsequentes devem ser colocadas em suas próprias ramificações no tronco-raiz.
  • Saiba que o WID atualmente não força um padrão de versão de módulo incremental. Em vez disso, a versão do módulo é completamente arbitrária e atribuída pelo usuário. Isso significa que teoricamente você pode ter um módulo 5.2.5 com um conteúdo mais antigo do que o módulo 1.0.0.
  • Ao consolidar módulos com versão como ramificações, especifique o número da versão do módulo no nome da ramificação. Também adicione comentários apropriados à ramificação que identifiquem o número da versão. Isso ajudará outros usuários, oferecendo informações sobre a versão que estão verificando.
  • Não abuse demais de versão de módulos. De forma ideal, cada versão de módulo deve preencher um propósito específico—por exemplo, um módulo com versão que manipula tráfego durante operações sazonais. A versão de módulo nunca deve ocupar o lugar do histórico de versão e revisão do SCM. Deixe o sistema de gerenciamento de controle de origem manipular as mudanças típicas de desenvolvimento diárias.

Desenvolvimento de equipe com Subversion

Preferências do Subversive

As preferências podem ser visualizadas ou mudadas em Window > Preferences > Team > SVN. Usamos as opções padrão do Subversive para os exemplos discutidos neste documento, e isso deve ser suficiente para a maioria dos usuários. Consulte a documentação do Subversive para obter informações sobre configurações e opções de preferência.

Figura 9. Preferência de plug-in cliente do Subversive
Preferência de plug-in cliente do Subversive

Embora algumas preferências possam ser modificadas, sempre mantenha a opção padrão para usar o arquivo .project para o nome do projeto, em vez de usar o nome da pasta. Embora essa configuração possa ser modificada, os módulos WID se baseiam no nome definido no arquivo .project, que também é usado por sca.module, sca.modulex e outros artefatos no módulo. Ao ler o nome do módulo a partir de arquivo de metadados .project, em vez de uma pasta definida pelo usuário, as discrepâncias de nome do módulo podem ser evitadas. Essa configuração pode ser encontrada em Preferences > Team > SVN > Repository.

Figura 10. Preferência do arquivo .project do Subversion
Preferência do arquivo .project do Subversion

Layout e estrutura de projeto do Subversion

Os projetos no Subversion são organizados no repositório em uma estrutura hierárquica de árvore. Há uma variedade de maneiras de organizar os módulos no Subversion, dependendo das necessidades do projeto e complexidade da solução. Para os exemplos apresentados neste documento, preferimos colocar cada módulo ou biblioteca no diretório-raiz, mas não há um jeito certo ou errado de organizar os módulos no repositório do Subversion. Projetos menores podem se beneficiar se os módulos e versões forem colocados em uma única pasta, enquanto que soluções corporativas complexas podem necessitar de múltiplos locais de repositório. Em qualquer caso, a estrutura de layout de projeto no repositório deve ser consistente.

Tronco, ramificações e tags

Em um módulo gerenciado, haverá um tronco para conter a base ou ativar versão do módulo, assim como ramificações e tags opcionais. Quando um módulo é gerenciado inicialmente no SCM, os artefatos são gerenciados no tronco. Cada módulo ou biblioteca WID gerenciado no repositório contém seu próprio tronco.

Pode ser preciso fazer uma cópia do tronco para manter uma árvore de desenvolvimento separada. É quando as ramificações são úteis. As ramificações contêm um caminho de desenvolvimento independente para um dado módulo, e são usadas com frequência quando é preciso gerenciar múltiplos fluxos de desenvolvimento de um módulo. Embora os artefatos de ramificação possam se transformar em algo funcionalmente diferente do tronco, uma ramificação sempre começa como uma cópia do tronco ou de outra ramificação. Por exemplo, é possível criar uma ramificação que contenha uma lógica de processo diferente para manipular transações durante as compras de fim de ano, talvez oferecendo descontos especiais ou incentivos de compra. Do mesmo modo, a ramificação é muitas vezes útil no WID na implementação de versão de módulo. No entanto, só se deve criar ramificações quando se tem uma linha de desenvolvimento separada; a ramificação nunca deve substituir o histórico de revisão de um dado módulo.

Ramificações, e tags de modo semelhante, possuem seu próprio conjunto gerenciado de artefatos e histórico de revisão. Tags são muito semelhantes a ramificações, exceto pelo fato de que elas gerenciam uma captura instantânea de um projeto ou módulo e não permitem que usuários realizem mudanças. As diferenças entre ramificações e tags são discutidas abaixo.

Tag x ramificação

A tag é semelhante à ramificação no Subversion. Uma tag é uma captura instantânea de um projeto em um determinado momento. Por exemplo, você pode querer criar uma tag para uma liberação de produção específica, quando todo o desenvolvimento de código estiver finalizado.

Você pode estar pensando que tags são muito semelhantes a ramificações. Na verdade, se usar as ferramentas de linha de comando do Subversion para criar tags, perceberá que não há diferença no modo de criar uma tag ou ramificação—fundamentalmente, elas são a mesma coisa. Em outras palavras, não há diferenças técnicas entre tags e ramificações—elas são meramente classificadas de modo diferente de acordo com o uso pretendido. Se os usuários não realizarem mudanças em uma captura instantânea, ela permanecerá uma tag. No entanto, se mudanças forem consolidadas na captura instantânea ou na tag, ela se torna uma ramificação.

Números de revisão do repositório

Quando um módulo ou artefato é consolidado no repositório, um número de revisão é atribuído ao módulo e seus artefatos, em que cada número de revisão representa uma captura instantânea histórica de um artefato. Por padrão, a revisão mais atual, ou HEAD, aparecerá na visualização do repositório; no entanto, revisões anteriores podem ser acessadas através da perspectiva SVN Repository Exploring.

Figura 11. Números de revisão de repositório para artefatos gerenciados
Números de revisão de repositório para artefatos gerenciados

Adicionando projetos WID ao Subversion

Projetos podem ser adicionados ao repositório remoto através da visualização Business Integration. Embora o procedimento discutido aqui seja específico para o Subversion, conceitos semelhantes se aplicam se outro sistema de controle de versão for usado, como CVS ou Clearcase. Projetos adicionados ao Subversion aparecerão na revisão HEAD do repositório.

Para adicionar um projeto local ao controle de origem, faça o seguinte:

  1. A partir da visualização Business Integration, clique com o botão direito no nome do módulo e selecione Team > Share Project...
Figura 12. Compartilhar projeto
Compartilhar projeto
  1. Selecione o tipo de repositório (neste caso, estamos usando o Subversion). Clique em Next.
Figura 13. Compartilhar projeto - SVN
Compartilhar projeto - SVN
  1. Crie ou selecione o repositório no qual o módulo deve ser gerenciado.
    • Se nenhum outro projeto no seu espaço de trabalho atual é gerenciado pelo Subversion, você precisará Create a new repository location. Insira o URL do repositório e credenciais de autenticação. Em Advanced, certifique-se de que a caixa de opção Enable Structure Detection está ativada com as seguintes configurações:
    • Se não, selecione Use existing repository location. Clique em Next.
Figura 14. Ativar detecção de estrutura
Ativar detecção de estrutura
Figura 15. Usar local de repositório existente
Usar local de repositório existente
  1. Especifique o layout e local do projeto. Observe que isso é puramente subjetivo—não há uma forma certa ou errada de organizar seus módulos no controle de origem, e você pode descobrir que um padrão organizacional diferente, mais simples ou mais complexo, funciona melhor para você. Recomendamos a seguinte configuração:
    • Selecione Advanced Mode.
    • Mantenha o valor de Name on Repository ajustado em Use project name.
    • Mude Project Repository Layout para Use single project layout.
    • Deixe o valor Use Subversion recommended layout ('trunk', 'branches' and tags) assinalado. Suas configurações devem se parecer com a figura 16.
    • Clique em Next.
Figura 16. Especificar local
Especificar local
  1. Insira uma descrição opcional no campo de comentários. Um comentário geral padrão será criado para você, mas você pode mudá-lo para algo mais específico. Deixe a opção Launch the Commit Dialog for the shared resources ativada.
Figura 17. Ativar Commit Dialog for the shared resources
Ativar Commit Dialog for the shared resources
  1. Clique em Finish para confiar o módulo ao repositório.
  2. Uma nova caixa de diálogo de comentários aparecerá. Eles são diferentes dos comentários anteriores já que se aplicam aos artefatos, e não ao módulo. Insira um valor e clique em OK.
  3. O módulo agora é gerenciado no controle de origem. Observe que agora há um número de revisão e URI próximos ao nome do módulo na visualização Business Integration.
Figura 18. Novo URI
Novo URI

Gerenciando soluções de integração no controle de origem

Soluções de integração do WID introduzidas na v6.2. Esses são projetos não implementáveis que permitem uma referência de módulos entrelaçados de forma lógica em um espaço de trabalho, incluindo módulos SCA, módulos de mediação, bibliotecas e projetos Java. O diagrama de solução de integração mostra as chamadas e relações entre os módulos.

Embora as soluções de integração não possuam uma lógica implementável, elas ainda podem ser gerenciadas no controle de origem como qualquer outro projeto WID. Além disso, há algumas opções nas soluções de integração que permitem simplificar algumas tarefas de desenvolvimento de equipe.

Para adicionar projetos à solução de integração:

  1. Clique com o botão direito em Project References e selecione Add or Remove Project References.
Figura 19. Adicionar ou remover referências de projeto
Adicionar ou remover referências de projeto
  1. Aparecerá uma janela contendo uma lista de projetos do espaço de trabalho. Marque ou desmarque os módulos que deseja que sejam gerenciados no repositório. Clique em OK para salvar as alterações.
Figura 20. Selecionar projetos
Selecionar projetos

Módulos que são referenciados na solução de integração podem ser verificados no controle de origem, como segue:

  1. Clique com o botão direito em Project References e selecione Check Out Referenced Shared Projects.
Figura 21. Verificar projetos compartilhados referenciados
Verificar projetos compartilhados referenciados
  1. Os projetos são verificados no repositório remoto e qualquer módulo existente no espaço de trabalho será sobrescrito.

Na maioria dos casos, é melhor verificar os módulos referenciados diretamente no repositório, em vez de usar a funcionalidade da solução de integração. Quando se usa a solução de integração para verificar o módulo, somente o tronco da revisão HEAD é verificado. Além disso, soluções de integração podem ser gerenciadas no SCM como qualquer outro módulo WID. Em seu núcleo, as soluções de integração são muito simples, consistindo em apenas projectSet.psf e solution.graphml, que identificam as dependências do módulo da solução.

Verificar projetos no Subversion

É possível verificar módulos no Subversion fazendo o seguinte:

  1. Abra a perspectiva SVN Repository Exploring. Se necessário, adicione um New Repository Location ao espaço de trabalho.
Figura 22. Novo local de repositório
Novo local de repositório
  1. Atualize o local do repositório para visualizar a captura instantânea mais recente no repositório.
Figura 23. Atualizar o local do repositório
Atualizar o local do repositório
  1. Expanda o módulo ou projeto que deseja verificar. Se estiver usando o padrão de layout trunk/branches/tags discutido anteriormente, expanda também a pasta apropriada. Neste caso, verificaremos a cópia do tronco.
Figura 24. Cópia do tronco
Cópia do tronco
  1. Clique com o botão direito na pasta do tronco e selecione Check Out para importar o módulo para o seu espaço de trabalho local.
Figura 25. Verificação
Verificação

Excluindo projetos e artefatos

Pode chegar um momento em que um artefato específico ou um módulo inteiro não é mais necessário em um projeto. Se um artefato é removido da cópia de trabalho local, ele não aparecerá mais na revisão HEAD do repositório, já que o módulo foi consolidado no repositório remoto. No entanto, o artefato ainda existe na revisão HEAD, de modo que pode ser recuperado se necessário. Módulos e artefatos também podem ser removidos diretamente do repositório Subversion.

Sincronizar mudanças entre a cópia de trabalho e o repositório

À medida que trabalha com módulos gerenciados no controle de origem, pode haver mudanças entre o local e as cópias remotas dos módulos. Para manter os artefatos na cópia de trabalho local e repositório remoto de acordo um com o outro, o espaço de trabalho local deve ser sincronizado com o repositório remoto. A perspectiva Team Synchronizing sincronizará as cópias locais e remotas e identificará os artefatos que precisam ser consolidados ou atualizados. Se um artefato foi modificado ou consolidado por múltiplos usuários, um alerta de conflito de mesclagem é mostrado no assistente de sincronização.

Para sincronizar o módulo do espaço de trabalho com o repositório remoto, faça o seguinte:

  1. Na visualização Business Integration, clique com o botão direito no nome do módulo e selecione Team > Synchronize with Repository.
Figura 26. Sincronizar com repositório
Sincronizar com repositório
  1. Uma caixa de diálogo pop-up aparecerá avisando que a perspectiva Team Synchronizing será aberta. Clique em Yes.
Figura 27. Perspectiva Team Synchronizing
Perspectiva Team Synchronizing
  1. Uma lista de artefatos modificados aparecerá na visualização Synchronize. Observe que, neste caso, há artefatos com mudanças de saída, mudanças de entrada e conflitos.
Figura 28. SourceControlTest
SourceControlTest
  1. Por padrão, Incoming/Outgoing Mode está selecionado, significando que todas as mudanças e conflitos aparecerão na lista de sincronização. Como mostrado abaixo, é possível mudar o filtro para mostrar somente mudanças de saída, mudanças de entrada ou conflitos.
Figura 29. Mudanças de filtro
Mudanças de filtro

Na parte inferior da janela WID, é listado número de mudanças de entrada, saída e conflitantes.

Figura 30. Mudanças de entrada, saída e conflitantes
Mudanças de entrada, saída e conflitantes
  1. Neste ponto, é possível consolidar, atualizar ou mesclar através da visualização Synchronize. Clique com o botão direito no módulo ou artefato para fazer essas mudanças (veja as seções seguintes para mais detalhes sobre consolidação, atualização ou mesclagem).

Embora seja possível atualizar ou consolidar antes da sincronização, isso é muito pouco recomendado. O assistente de sincronização mostrará uma lista completa de mudanças que foram feitas nas versões de módulo local e remota. Se essas mudanças forem consolidadas ou atualizadas sem sincronização, você pode sobrescrever trabalho essencial de outros usuários. Evite esses problemas sempre sincronizando antes. Além disso, quando estiver trabalhando com módulos que sofrem revisões frequentes, sincronize sempre para verificar se sua cópia de trabalho local está atualizada.

Consolide mudanças no repositório

Qualquer mudança feita à cópia de trabalho local deve ser salva no repositório remoto antes que as mudanças tenham efeito. É aí que entra a consolidação. Quando o projeto é adicionado ao repositório, uma consolidação inicial salva todos os artefatos da cópia de trabalho local no repositório.

Artefatos devem ser consolidados no repositório sob estas circunstâncias:

  • Mudanças em artefatos que existem atualmente no repositório, isto é, um BO existente é modificado para incluir novos campos de dados.
  • Adição de novos artefatos a um módulo atualmente no repositório, isto é, um novo processo BPEL é adicionado à cópia de trabalho local.
  • Remoção de artefatos do módulo, isto é, um arquivo WSDL é excluído da cópia de trabalho.

Se houver um sinalizador "sujo" (>) em seu espaço de trabalho, isso sugere que sua cópia local é diferente da cópia do repositório remoto. Você pode querer sincronizar ou consolidar suas mudanças no repositório para assegurar que a cópia remota esteja em concordância com a cópia de trabalho local.

Figura 31. O sinalizador aponta que algo mudou no espaço de trabalho
O sinalizador aponta que algo mudou no espaço de trabalho

Consolide mudanças no espaço de trabalho fazendo o seguinte:

  1. Sincronize o espaço de trabalho com o repositório remoto. Se não forem encontradas mudanças entre a cópia de trabalho local e o repositório remoto, não há nada a ser consolidado ou atualizado.
  2. Abra a perspectiva Team Synchronizing para visualizar o resumo de sincronização.
  3. Consolide as mudanças no repositório. Tanto é possível consolidar cada mudança no módulo como consolidar artefatos individuais. Clique com o botão direito no nome do módulo ou artefato e selecione Commit... Aparecerá uma caixa de diálogo de consolidação.
Figura 32. Caixa de diálogo de consolidação
Caixa de diálogo de consolidação

Ou você pode clicar no botão Commit All Outgoing Changes no topo da janela de visualização Synchronize.

Figura 33. Botão Commit All Outgoing Changes
Botão Commit All Outgoing Changes
  1. Insira um comentário opcional na caixa de diálogo de consolidação. Clique em OK para consolidar as mudanças.
Figura 34. Inserir comentários de consolidação
Inserir comentários de consolidação
  1. Depois que o módulo é consolidado e o espaço de trabalho é sincronizado, observe que não há mais mudanças abertas no módulo especificado.
Figura 35. Nenhuma mudança no módulo
Nenhuma mudança no módulo

Observações:

  • Sincronize sempre para verificar atualizações de outros usuários. Isso é especialmente importante para artefatos principais que podem ser usados em múltiplos módulos, como bibliotecas com WSDLs e XSDs.
  • Se tentar consolidar itens que foram modificados por outros usuários, você terá um conflito de mesclagem. Embora haja ferramentas de mesclagem na perspectiva Team Synchronizing, essas ferramentas foram projetadas para código tradicional, como Java, e não funcionam bem para artefatos WID baseados em XML. Portanto, conflitos de mesclagem devem ser manipulados manualmente.
  • A operação de consolidação só pode ser usada para módulos que já são gerenciados no controle de origem. Se está criando um novo módulo, então use a caixa de diálogo Share Project....
  • Se fizer qualquer mudança na cópia de trabalho local, observe que o marcador de sinalizador (>) aparece próximo ao nome do módulo.

Atualizar mudanças do repositório para a cópia de trabalho local

Discutimos a consolidação na seção anterior, que você usou para salvar as mudanças locais no repositório. No entanto, algumas vezes outros usuários podem ter feito mudanças em um módulo que você verificou. Neste caso, sua cópia de trabalho local está fora de sincronização e precisa ser atualizada. Uma atualização é efetivamente o pólo oposto da consolidação—em vez de empurrar mudanças do espaço de trabalho local para o repositório, uma atualização pegará qualquer mudança do repositório que possa ter ocorrido desde que o módulo foi verificado. Como não é possível saber quando um módulo precisará de atualização, você deve sincronizar sua cópia local com o repositório remoto de forma periódica.

Atualize sua cópia de trabalho local como segue:

  1. Sincronize seu espaço de trabalho com o repositório remoto. Se tudo estiver sincronizado, as atualizações não serão necessárias.
  2. Visualize a lista de sincronização através da perspectiva Team Synchronizing.
  3. Atualize seu espaço de trabalho local. De forma semelhante à operação de consolidação, você pode atualizar tanto o módulo inteiro como artefatos individuais Clique com o botão direito no nome do módulo ou artefato e clique em Update...
Figura 36. Módulo de atualização
Módulo de atualização

Do mesmo modo, é possível atualizar todas as mudanças de entrada diretamente a partir das opções do botão da visualização Synchronize.

Figura 37. Atualizar todas as mudanças de entrada
Atualizar todas as mudanças de entrada
  1. O espaço de trabalho agora está atualizado.

Gerenciando conflitos

Suponhamos que há dois usuários, Joe e Tom, que estão trabalhando no mesmo projeto WID. Cada um verificou um conjunto de módulos do repositório e, sem contar um ao outro sobre seus planos, cada um faz uma série de mudanças em um processo BPEL em um módulo ShipOrderModule. Joe faz suas mudanças rapidamente e sincroniza sua cópia com o repositório remoto. Não há conflitos, então ele consolida as mudanças e fecha seu espaço de trabalho. Algumas horas depois, Tom decide consolidar suas mudanças no processo. Ele sincroniza e imediatamente nota um conflito—Joe também está trabalhando no mesmo conjunto de artefatos.

Tom tem três opções nesse momento:

  1. Ele pode forçar suas mudanças no repositório HEAD, sobrescrevendo assim as mudanças de Joe (o artefato de Joe ainda vai existir em uma revisão anterior, desde que já esteja consolidado).
  2. Ele pode atualizar sua cópia de trabalho local para refletir as mudanças feitas por Joe no repositório, mas perderá todo seu trabalho recente.
  3. Ele pode usar um conjunto de ferramentas de mesclagem para mesclar as mudanças entre a cópia de Joe e seu próprio trabalho.

Há algumas opções à disposição quando se trata de conflitos de fusão. Para código de origem tradicional, como Java, a melhor e mais fácil opção é usar o conjunto de ferramentas de mesclagem para auxiliar a integração das duas versões do código. No entanto, isso não é muito prático para artefatos WID, já que são baseados em XML e são normalmente muito difíceis de integrar em um formato de texto bruto. Quase sempre os artefatos WID são desenvolvidos usando ferramentas GUI, de modo que realizar uma integração baseada em texto é algo arriscado e propenso a erros. Atualmente, não há como fazer uma mesclagem e comparação gráficas para artefatos WID.

Se um artefato principal é mesclado indevidamente, o processo necessário para corrigir esses problemas pode consumir muito tempo e pode afetar outros artefatos ou módulos de modo adverso. Se você definitivamente precisa mesclar artefatos WID devido a conflito, certifique-se de manter cópias locais dos dois artefatos, caso precise reverter para um ou outro.

Os conflitos de mesclagem tratam da importância de práticas frequentes de sincronização. Se tom tivesse sincronizado de forma frequente em vez de esperar algumas horas, ele teria percebido que o processo BPEL tinha sido modificado por Joe muito antes que ele fizesse qualquer modificação significativa no processo. Ele poderia, então, ter discutido as modificações com Joe e talvez tê-las integrado à sua cópia de trabalho local para evitar ambiguidade durante a consolidação.

Então, qual é a melhor abordagem? Se possível, tente evitar conflitos de mesclagem em geral. Se você sabe que múltiplos usuários estarão trabalhando com um módulo ou biblioteca em comum, discuta isso com sua equipe e tenha certeza de que somente uma pessoa fará as mudanças em um artefato em um dado momento. Também é possível usar as opções Lock e Unlock no menu Team para bloquear acesso de leitura ou gravação a módulos ou artefatos específicos.

Opção Mark as Merged

A visualização Synchronize possui uma opção Mark as Merged que permite substituir os marcados de conflitos, marcando o artefato como se ele já estivesse mesclado. Isso é útil quando você mesclou o artefato em questão manualmente e não quer usar o conjunto de ferramentas de comparação e mesclagem baseado em texto para mesclar conflitos.

Para marcar o arquivo como mesclado, clique com o botão direito no módulo ou artefato na visualização Synchronize e selecione Mark as Merged. O indicador de conflito de mesclagem será removido e consequentemente o artefato agora pode ser consolidado ou atualizado.

Bloqueando e desbloqueando recursos

Para evitar conflitos de mesclagem, você pode querer evitar que múltiplos usuários tenham acesso de gravação a um módulo ou recurso. É possível fazer isso configurando bloqueios em um módulo em particular. Quando um módulo ou artefato é bloqueado, outros usuários ainda podem verificar o módulo, mas não poderão consolidar qualquer mudança até que o bloqueio seja liberado.

Bloqueie um módulo como segue:

  1. Verifique os módulos do repositório.
  2. A partir da visualização Business Integration, clique com o botão direito no módulo e selecione Team > Lock...
Figura 38. Bloquear módulo
Bloquear módulo
  1. Insira um comentário opcional e assinale a opção Lock recursively. Clique em OK.
Figura 39. Bloquear recursivamente
Bloquear recursivamente
  1. O módulo agora está bloqueado para seu uso exclusivo. Você verá ícones de bloqueio na cor rosa em seu espaço de trabalho.
Figura 40. Módulos bloqueados
Módulos bloqueados
  1. Quando não mais precisar de acesso exclusivo, certifique-se de Unlock o módulo.
    • a. Clique com o botão direito no nome do módulo-raiz e selecione Team > Unlock.
    • Assinale a opção Recursively e clique em Yes. O módulo agora deve estar desbloqueado em seu espaço de trabalho.
Figura 41. Desbloquear os módulos
Desbloquear os módulos
Figura 42. Assinalar a opção Recursively
Assinalar a opção Recursively

Observações:

  • O bloqueio afeta somente o acesso de gravação a um artefato. Se um módulo é bloqueado por um usuário, outros usuários ainda podem verificar um módulo bloqueado, mas não poderão consolidar qualquer mudança até que o bloqueio seja liberado.
  • Múltiplos usuários podem conseguir acesso de gravação de um módulo bloqueado usando a opção de bloqueio Force. Essa prática é desaconselhável, no entanto, já que abre a possibilidade de conflitos de mesclagem.
Figura 43. Opção de bloqueio Force
Opção de bloqueio Force

Trabalhando com ramificações

Ramificações permitem criar uma nova linha de desenvolvimento a partir de um módulo existente. Elas são úteis quando você possui um fluxo de código único que é completamente baseado no módulo tronco. Esta seção descreve como criar e verificar ramificações do repositório.


Criar uma nova ramificação a partir da visualização Business Integration

É possível criar uma ramificação a partir de um módulo existente na visualização Business Integration. Para criar uma ramificação, o módulo deve existir no momento no Subversion, como tronco ou ramificação diferente, e deve ser verificado em sua cópia de trabalho local.

  1. Verifique se o seu espaço de trabalho contém o tronco ou uma ramificação para o módulo a partir do qual quer criar uma ramificação.
  2. Clique com o botão direito no nome do módulo e selecione Team > Branch... Uma nova janela aparecerá.
  3. Insira um nome para a ramificação e selecione a opção Start working in the branch. Também é fortemente recomendado inserir um comentário, já que ele fornecerá à sua equipe meios de identificar o propósito da ramificação. Clique em OK.
Figura 44. Inserir local da ramificação
Inserir local da ramificação
  1. A ramificação agora será criada no repositório remoto.
Figura 45. Ramificação criada no repositório remoto
Ramificação criada no repositório remoto

Se você selecionou a opção de começar a trabalhar na ramificação, então sua cópia de trabalho local refletirá o nome da ramificação recém-criada.

Figura 46. Novo diretório de ramificação
Novo diretório de ramificação

Também é possível criar ramificações diretamente no Subversion na visualização SVN Repository Exploring.

  1. Abra a visualização SVN Repository Exploring e navegue até o módulo desejado. Neste caso, faremos uma ramificação do tronco HelloWorldProcess. Clique com o botão direito no tronco e selecione New > Branch...
Figura 47. Nova ramificação
Nova ramificação
  1. Uma nova janela aparecerá. Insira um nome de ramificação e um comentário opcional e clique em OK.
Figura 48. Inserir um nome de ramificação e comentário opcional
Inserir um nome de ramificação e comentário opcional
  1. A ramificação aparecerá na visualização SVN Repositories, mas deve ser verificada antes de aparecer na sua cópia de trabalho local.
Figura 49. Lista de ramificações
Lista de ramificações

Verificar uma ramificação do repositório

  1. Localize o módulo e ramificação na visualização SVN Repositories que gostaria de verificar. Expanda as ramificações para obter uma lista das ramificações disponíveis para um módulo. Neste exemplo, verificaremos branch03.
  2. Clique com o botão direito no nome da ramificação e selecione Check Out.
Figura 50. Verificar ramificação
Verificar ramificação
  1. Já que o tronco e todas as ramificações de um módulo compartilham o mesmo nome de módulo no repositório, você pode ser notificado de que o módulo já existe na cópia de trabalho local. Selecione o nome do módulo para sobrescrever a cópia de trabalho local e clique em OK.
Figura 51. Projeto de substituição
Projeto de substituição
  1. A ramificação selecionada agora parece na cópia de trabalho local.

Tópicos avançados do Subversion

Esta seção descreve brevemente alguns dos recursos avançados encontrados no Subversion. Para obter informações detalhadas sobre esses tópicos, visite os arquivos de ajuda do Subversive ou a documentação do servidor Subversion.

Operações de substituição

há dois comandos de substituição disponíveis na visualização Synchronize: Override and Commit e Override and Update. Esses comandos substituirão qualquer mudança no repositório (na consolidação) ou cópia de trabalho local (na atualização) de um dado módulo ou artefato. Tome cuidado ao usar os comandos de substituição—você pode sobrescrever mudanças inadvertidamente no seu espaço de trabalho local ou repositório remoto.

Normalmente é melhor usar os comandos padrão Commit and Update em conjunto com Mark as Merged.

Clique com o botão direito no módulo ou artefato para acessar os seguintes comandos de substituição.

Figura 52. Operações de substituição de consolidação e atualização
Operações de substituição de consolidação e atualização

Reverter mudanças na cópia de trabalho local

Se fizer mudanças na sua cópia de trabalho local, mas decidir depois que essas mudanças são acidentais ou desnecessárias, você pode descartar as mudanças usando a opção Revert. Isso irá restaurar o artefato ao seu estado definido na revisão de repositório correspondente.

Para reverter um módulo no seu espaço de trabalho, clique com o botão direito no nome do módulo e selecione Team > Revert... Um menu pop-up aparecerá com uma lista de artefatos modificados. Escolha os artefatos que deseja reverter e clique em OK. Observe que o sinalizador "sujo" (>) é removido de tais artefatos.

Figura 53. Reverter mudanças feitas em uma cópia de trabalho local
Reverter mudanças feitas em uma cópia de trabalho local

Usando a visualização History

Você pode querer visualizar o histórico de revisão do controle de origem de um módulo ou artefato em particular. A visualização History localizada na perspectiva SVN Repository Exploring mostrará uma revisão do artefato. O número da revisão, tempo de consolidação, autor de artefato e qualquer comentário disponível são listados na visualização History.

Visualize o histórico do artefato como segue:

  1. Abra a perspectiva SVN Repository Exploring.
  2. Expanda o módulo e localize o artefato do qual deseja visualizar o histórico de revisão.
  3. Clique com o botão direito no artefato e selecione Show History.
Figura 54. Mostrar histórico
Mostrar histórico
  1. Uma lista de revisões disponíveis aparecerá na visualização History. Clique em uma revisão para ver o histórico de mudanças.
Figura 55. Visualização History
Visualização History

Selecionando uma revisão específica no repositório

Na maioria dos casos você verificará seus módulos da revisão HEAD do repositório, mas ocasionalmente você pode querer verificar uma revisão em particular. A visualização SVN Repositories permite visualizar qualquer revisão no repositório, assim como verificar o tronco ou ramificações do seu espaço de trabalho local.

É possível navegar e verificar uma revisão de módulo em particular como segue:

  1. Abra a perspectiva SVN Repository Exploring e refine a visualização SVN Repositories. Procure a árvore REVISIONS no local do repositório raiz.
Figura 56. Árvore de revisões
Árvore de revisões
  1. Clique com o botão direito em REVISIONS e clique em Select Revision...
  2. Uma janela pop-up aparecerá. É possível selecionar uma revisão existente por Data ou Número de revisão. Clique em Browse... para selecionar um número de revisão. Clique em OK depois de selecionar uma revisão.
Figura 57. Selecionar a revisão
Selecionar a revisão
  1. Para listar os módulos existentes na revisão mencionada acima, expanda a árvore REVISIONS até ver o tronco, ramificações e tags. Agora é possível verificar a revisão do módulo, do mesmo modo que a revisão HEAD.
Figura 58. Árvore de revisão
Árvore de revisão

Alternando de uma revisão de espaço de trabalho para outra

Na seção anterior você aprendeu como navegar e verificar revisões anteriores existentes no repositório. Essas práticas são úteis quando você está importando um módulo para seu espaço de trabalho, mas pode haver momentos em que você deseja verificar uma versão mais antiga de um módulo que já existe em seu espaço de trabalho. É quando a comutação é usada.

Alterne um módulo para uma revisão diferente como segue:

  1. Abra a perspectiva Business Integration e destaque o módulo que deseja alternar.
  2. Clique com o botão direito no nome do módulo e selecione Team > Switch...
  3. Uma nova janela aparecerá.
    • Clique em URL Browse... para selecionar um URL para o local do módulo. Selecione a ramificação ou tronco apropriado.
Figura 59. Navegar
Navegar
  • Na seção Revision, escolha uma revisão por Data ou número de Revisão . Escolhemos o número de Revisão para este caso. Clique no botão Browse... em Revision e selecione uma revisão.
  • Deixe Depth no valor de cópia Working padrão.
  • Suas configurações devem parecer algo assim. Clique em OK.
Figura 60. Navegação em Revision
Navegação em Revision
Figura 61. Selecionar URL e revisão do recurso de repositório
Selecionar URL e revisão do recurso de repositório
  1. A revisão do módulo selecionada será importada para o seu espaço de trabalho. Observe que o número da revisão mudou com base na sua seleção.
Figura 62. Número da revisão
Número da revisão

Observe que Select Revision e Switch são semelhantes já que permitem verificar uma revisão anterior no repositório. No entanto, a opção Select Revision só está disponível na perspectiva SVN Repository Exploring, enquanto que o comando Switch está disponível na perspectiva Business Integration através do menu Team. Se o módulo não existe em sua cópia de trabalho local, você deve usar Select Revision, enquanto Switch deve ser usado para módulos que já existem em sua cópia de trabalho local.

Substituindo a cópia de trabalho local por uma versão do SCM

Semelhante à comutação, é possível usar os recursos Replace With para alternar entre ramificações ou revisões disponíveis existentes no repositório. Não há vantagem em usar esse método em vez da comutação—ele simplesmente fornece uma outra forma de fazer a mesma coisa.

  1. A partir da visualização Business Integration, clique com o botão direito no módulo e selecione Replace With.
  2. Selecione a opção apropriada abaixo e siga os menus de contexto como faria com a comutação. Se selecionar Latest from Repository, a cópia de trabalho local será substituída pela última versão do módulo no repositório.
Figura 63. Usando Replace With para alternar ramificações
Usando Replace With para alternar ramificações

Quando substituir um módulo, tome cuidado para que nenhum artefato não salvo ou não consolidado seja removido do espaço de trabalho local. Portanto, você deve sincronizar antes de substituir a cópia de trabalho local.


Versão de módulo no WID

A versão de módulo é nova no WID v6.2 e permite fazer algumas coisas. Primeiro, você pode gerenciar de forma lógica módulos baseados em um conjunto de recursos definido e pode implementar facilmente uma versão específica para atingir um dado propósito, se desejado. Provavelmente o mais importante é que você pode instalar múltiplas versões simultaneamente no mesmo destino de tempo de execução. Os módulos só podem obter versões através do editor de dependência no WID.

Para criar um arquivo EAR sensível à versão, um módulo com versão deve ser implementado usando serviceDeploy. Módulos exportados como arquivos EAR do WID irão construir e instalar de forma apropriada, mas não serão sensíveis à versão. Do mesmo modo, aplicativos adicionados ao UTE através de projetos Add/Remove também não são sensíveis à versão.

O IBM Supplied Version Scheme usa um sistema de versão numérica de três dígitos no formato <MAJOR>.<MINOR>.<SERVICE>. Por exemplo, uma versão anterior de um módulo pode ter um número de versão 1.0.2. Os valores de MAJOR, MINOR e SERVICE são puramente subjetivos e devem ser modificados pelo usuário. O desenvolvedor deve decidir quando incrementar cada categoria, desde que o WID não mantenha rastro das versões do módulo incremental. Além disso, uma classificação numérica sucessiva é fortemente recomendada, mas não imposta. Em outras palavras, não há nada no WID que o impeça de criar uma versão de módulo, digamos 1.0.1, que tenha um conteúdo mais recente do que a versão 2.1.0. Projetos e bibliotecas dependentes de um módulo com versão não precisam ter versão, nem precisam usar o mesmo número de versão do módulo referido. As propriedades de versão de módulo podem ser configuradas nas configurações de dependência do módulo.

Figura 64. Configurações e número de versão de módulo
Configurações e número de versão de módulo

Atente-se para o fato de que quando módulos recebem versões, somente o nome do módulo é modificado de forma única. Isso permitirá instalar duas ou mais cópias do mesmo aplicativo em um tempo de execução WPS; no entanto, qualquer processo BPEL ou modelos de tarefa manual não serão modificados e, portanto, podem impedi-lo de instalar múltiplas versões de aplicativo no mesmo destino de tempo de execução. Os modelos de processo ou tarefa devem ser únicos para um dado contêiner de processo ou tarefa. Se você tentar instalar múltiplas versões de módulos simultaneamente no mesmo destino de tempo de execução sem fazer uma versão da tarefa manual ou processo BPEL, o aplicativo falhará ao fazer a instalação. Para resolver esse problema, você precisa fazer uma versão do seu processo BPEL no tempo de design, ou refatorar o nome do modelo de processo BPEL.

A versão de módulo é desativada por padrão, mas pode ser ativada para cada módulo através das preferências de Window > Preferences > Business Integration > Module And Library Versions.

Como um módulo com versão é construído

Há dois artefatos WID que são relevantes para a versão de módulo:

  • sca.module – O nome do módulo SCA é definido neste arquivo. Se a versão de módulo for usada, o nome do módulo será renomeado durante a implementação, de modo que o número da versão é anexado à cadeia do nome do módulo durante a implementação. Observe que isso só funciona para aplicativos implementados através de serviceDeploy, e não de projetos Add/Remove.
  • sca.module.attributes – Ele só é criado quando a versão de módulo é ativada. O número do módulo especificado para o usuário é configurado aqui. Como lembrete, entenda que o número da versão só é aplicado quando o módulo é implementado através de serviceDeploy.

O módulo tem de ser implementado através de serviceDeploy para que as propriedades da versão do módulo tenham efeito. Durante a implementação, o número da versão definido em sca.module.attributes será usado para construir o novo nome do módulo.

O módulo com versão é identificado usando o seguinte padrão:

ModuleName_vX_Y_ZApp.ear

em que X, Y e Z são números de revisão major, minor e service.

Por exemplo, suponha que você tem um módulo, HelloWorldProcess, em seu espaço de trabalho WID. Você ativa a versão e identifica o módulo como versão 1.0.1. Se o módulo for implementado através do WID, o EAR resultante seria nomeado como HelloWorldProcessApp.ear. No entanto, com a versão ativada o nome do módulo se torna HelloWorldProcess_v1_0_1App.ear através de serviceDeploy.

Como a versão de módulo se relaciona com o gerenciamento de controle de origem

A versão de módulo do WID é intimamente relacionada a como os módulos são gerenciados no controle de origem. De forma ideal, todas as versões de módulo deveriam ser gerenciadas no controle de origem, para serem facilmente recuperadas, modificadas ou instaladas no tempo de execução WPS.

Módulos com versão devem ser armazenados na mesma árvore de diretório do módulo-pai. Recomendamos que a versão inicial do módulo (digamos, 1.0.0) seja armazenada no tronco, e as versões subsequentes do módulo sejam armazenadas em ramificações do tronco.

Ou você pode manter a última ou mais estável versão no tronco e manter todas as versões anteriores do módulo em ramificações. Não há resposta certa ou errada aqui, desde que o padrão seja consistente. Para continuidade, recomendamos que a primeira versão seja armazenada no tronco, com todas as versões subsequentes armazenadas como ramificações. Se precisar fazer uma mudança em um artefato principal que irá afetar todas as versões, ela pode ser implementada no tronco e delegada às ramificações conforme necessário. Observe que troncos e ramificações são nativos para Subversions; outros produtos SCM podem usar convenções diferentes.


Apêndice 1 : Lista de artefatos WID gerenciado no controle de origem

Mapas de objeto de negócios:

  • .map, .xsl, .xsl.smap

Mapas de interface:

  • .ifm, <IFMapName>_ifm.mon

Artefatos WPS gerais:

  • .component, .module, .modulex, .import, .export, .mon, ibm-deploy.scaj2ee

Metadados do Eclipse:

  • .settings folder, MANIFEST.MF, .classpath, .project

Interfaces:

  • .wsdl

Tipos de dados (objetos de negócios):

  • .xsd

Mediações:

  • .medflow, .mfc, .mfcex

Processos de negócios:

  • .bpel, .bpelex, <ProcName>Artifacts.wsdl, <ProcName>_bpel.mon

Máquinas de estado de negócios: (Observe que o arquivo .bpel adjacente da máquina de estado agora é gerado durante a instalação do aplicativo e, portanto, não é gerenciado no SCM.)

  • .sacl, .saclex, <BSMName>_sacl.mon

Tarefas manuais:

  • .tel, .itel (somente tarefa sequencial), <HTName>_tel.mon

Regras de negócio:

  • .brg, .brgt, <BRGName>_brg.mon, .ruleset

Seletores:

  • .sel, .selt, <SelName>_sel.mon

Relacionamentos:

  • .rel, .rol

Módulos de solução de integração:

  • .project
  • projectSet.psf
  • solution.graphml

Apêndice 2 : Instalar o plug-in cliente Subversive

Para conectar-se a um servidor Subversion em WID ou Eclipse, é necessário instalar o plug-in cliente apropriado. Como discutimos neste documento, há dois plug-ins disponíveis que trabalham com Subversion—Subclipse e Subversive. Nos exemplos discutidos neste documento, usamos o Subversive, no entanto, o Subclipse também pode ser usado.

Para instalar o plug-in cliente Subversive, visite o guia de instalação do Subversive: http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/install.php

Recomendamos que evite instalar o Subclipse e o Subversive na mesma instância do WID. Como os dois plug-ins possuem sistemas de menu semelhantes e perspectivas SVN Repository Exploring, às vezes é difícil distinguir um plug-in do outro.

Instalar e configurar um servidor Subversion

Para usar o Subversion, você também precisará de um servidor de tempo de execução Subversion. Na maioria das vezes, ele será gerenciado por um administrador de sistema. Como este documento foca estritamente a programação cliente do WID, a configuração do tempo de execução do Subversion vai além do escopo deste documento. Usamos Collabnet distribution neste documento.

Para obter mais informações sobre a configuração do Subversion, consulte o excelente recurso gratuito Version Control with Subversion.

Independentemente de qual plug-in servidor ou cliente Subversion você usar, certifique-se de que o cliente e o servidor estejam no mesmo nível de versão.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=472271
ArticleTitle=Desenvolvimento de equipe e gerenciamento de artefato no WebSphere Integration Developer v6.2
publish-date=03052010