Integração Contínua com o IBM Rational ClearCase Remote Client

Práticas de desenvolvimento ágil com o CruiseControl

Comments

IBM® Rational® ClearCase® é o software de gerenciamento de configuração de software (SCM) que suporta a maioria dos modos de desenvolvimento atuais. Atualmente, o desenvolvimento ágil se tornou cada vez mais popular. Porém, o software SCM é uma parte inseparável do desenvolvimento de software, e seu impacto sobre a eficiência é significante. O ClearCase Remote Client é um cliente leve para o ClearCase. A versão 7.1 introduz recursos que suportam o desenvolvimento ágil.

A integração contínua (CI) é uma das boas práticas do desenvolvimento ágil. É muito crítico aplicar ferramentas de suporte efetivas para implementar a CI com êxito no ciclo de vida de desenvolvimento do seu software. Este processo inclui uma ferramenta SCM (neste caso, ClearCase Remote Client), e uma ferramenta para executar automaticamente a sua construção e relatar seus resultados (neste caso, CruiseControl). Este artigo mostra como implementar a CI com o CruiseControl e o ClearCase Remote Client.

Existem mútiplas versões do ClearCase Remote Client; os exemplos neste artigo usam o ClearCase Remote Client V7.1. Para conveniência, este produto é referido simplesmente como ClearCase Remote Client.

Pré-requisitos

Os autores deste artigo supõem que você tem um conhecimento básico do CruiseControl e do Apache Ant. Se você não tem, consulte Recursos para obter os links para os sites da Web nos quais você pode obter mais informações.

Desenvolvimento ágil

O desenvolvimento de software ágil representa um grupo de boas práticas de desenvolvimento de software. Como o nome diz, ele significa codificação de alta velocidade, rápida reação às mudanças de requisitos, iterações curtas, e rápido fornecimento de software de alta qualidade. Todas essas características se baseiam nesses princípios. Favorecimentos do desenvolvimento ágil:

  • Indivíduos e interações sobre processos e ferramentas
  • Software de trabalho sobre documentação abrangente
  • Colaboração customizada sobre negociação de contrato
  • Resposta à mudança sobre acompanhamento de um plano

A maioria dos modelos de desenvolvimento iterativos e incrementais são projetados para possibilitar às equipes oferecer software de alta qualidade o mais rapidamente possível. Porém, normalmente leva muito mais tempo para as equipes que usam os modelos de desenvolvimento tradicionais lançarem software. Isso porque os modelos predefinem todas as etapas, e você deve passar por cada uma delas. Portanto, os modelos não são tão flexíveis. Em contraste, o desenvolvimento ágil é mais adaptativo: ele fornece software com a menor funcionalidade trabalhável e aumenta gradativamente.

Seções posteriores deste artigo contêm informações detalhadas sobre como o ClearCase Remote Client suporta o desenvolvimento ágil. A próxima seção fornece uma breve introdução à CI.

Integração contínua

No desenvolvimento ágil, os desenvolvedores frequentemente enviam seu trabalho para um espaço de trabalho de integração. O grande número de construções torna a integração não apenas complexa, mas também custosa. A CI ajuda com isso.

Ao considerar as vantagens do uso da CI, primeiro, considere o trabalho diário dos desenvolvedores. No início, os desenvolvedores obtêm o código de origem consistente e mais recente do repositório, e depois desenvolvem por um determinado período de tempo antes de entregar sua versão a partir do espaço de trabalho local para o repositório de integração. Diferentes entregas de diferentes de desenvolvedores causam conflitos e inconsistência. Como resultado, a construção de integração se torna muito complexa e cara.

Felizmente, existe software que executa uma construção de integração e até testes rápidos após cada entrega, automaticamente. A CI é uma prática que ajuda a alcançar este objetivo. Martin Fowler definiu CI desta maneira no prefácio de seu artigo intitulado "Integração Contínua:"

Integração contínua é uma prática de desenvolvimento de software na qual os membros de uma equipe integram seu trabalho frequentemente. Geralmente, cada pessoa integra pelos menos diariamente, levando à múltiplas integrações por dia. Cada integração é verificada por uma construção automatizada (incluindo teste) para detectar erros de integração o mais rapidamente possível.

O artigo de Kevin Lee no The Rational Edge, intitulado "Realizando integração contínua," também fornece uma boa introdução. Para os propósitos deste artigo, a CI é uma prática de desenvolvimento de software na qual a integração, construção e teste rápido da construção ocorrem continuamente.

Considerada como uma prática, a CI é um processo cíclico que consiste em três etapas principais:

  1. A atualização do repositório de integração
  2. A construção de integração
  3. Feedback

A Figura 1 mostra o relacionamento entre essas três etapas.

Figura 1. Infraestrutura da CI
Infraestrutura da CI
Infraestrutura da CI

A primeira etapa (atualização do repositório de integração) é realizada pelo software SCM. A segunda etapa (a construção da integração) é alcançada através de uma ferramenta de construção. A última etapa é realizada por um tipo de ferramenta que foi desenvolvida de acordo com os princípios da CI para ativar essas etapas automaticamente (por exemplo, CruiseControl, um estrutura de software livre para um processo de construção contínuo). Nos exemplos neste artigo, a CI será implementada usando as ferramentas de software do ClearCase Remote Client e do CruiseControl.

A seção a seguir descreve os novos recursos de ClearCase Remote Client em detalhes e explica como esta ferramenta satisfaz os requisitos para o software SCM bem-sucedido.

Recursos do ClearCase Remote Client V7.1

Para suportar o desenvolvimento de software ágil, a equipe da IBM para o desenvolvimento de software Rational desenvolveu um cliente remoto para o ClearCase e o chama, logicamente, de ClearCase Remote Client. Ele suporta a maioria da funcionalidade do Rational ClearCase, com uma interface com o usuário (UI) fácil de usar).

Existem dois tipos de ClearCase Remote Client.

  • Um é o plug-in do Eclipse do ClearCase Remote Client
  • O outro é a versão independente do ClearCase Remote Client

Neste artigo, a menos que declarado de outra forma, "ClearCase Remote Client" refere-se ao plug-in do Eclipse.

A seguir, você verá como o ClearCase Remote Client suporta o desenvolvimento ágil.

Visualização Navegador Compactado

Todo o conteúdo no ClearCase Remote Client é compactado na visualização ClearCase Navigator e organizado numa hierarquia. É possível localizar e editar qualquer um desses conteúdos fácil e rapidamente. Para torná-lo mais intuitivo, a UI usa ilustrações.

Na Figura 2, é possível ver que existem duas partes principais: a primeira são as visualizações locais e contém todas as visualizações de captura instantânea local, e a segunda são as informações do servidor.

Figura 2. ClearCase Navigator
ClearCase Navigator
ClearCase Navigator

Na segunda parte, também existem duas subpartes. Uma é ClearCase, e a outra é ClearQuest (IBM® Rational® ClearQuest®), como mostrado na Figura 3.

Figura 3. ClearCase Navigator: informações do servidor
ClearCase Navigator: informações do servidor
ClearCase Navigator: informações do servidor

Sob ClearCase”, ambos Component VOBs (Versioned Object Bases) e Project VOBs são listados. É possível modificar dois tipos de metadados sob Component VOBs: Tipos de Ramificação e Tipos de Rótulo.

Sob Project VOBs, todos os VOBs do projeto são listados. E sob cada VOB de projeto, projetos, fluxo de integração, fluxos de desenvolvimento e linhas de base são todos exibidos, como mostrado na Figura 4.

Como você pode ver, a hierarquia e combinação de todos os elementos tornam aparência do ClearCase Remote Client conciso e fácil. Esta é uma importante característica que o desenvolvimento de software ágil necessita.

Figura 4. ClearCase Navigator: informações do projeto
ClearCase Navigator: informações do projeto
ClearCase Navigator: informações do projeto

Recursos de Destaque

Geralmente, as funcionalidades do ClearCase Remote Client podem ser colocadas em duas categorias: desenvolvimento e gerenciamento. Como exemplos, é possível usar as funcionalidades do desenvolvimento para:

  • Criar uma visualização ou juntar-se a um projeto (que gerará visualizações)
  • Editar especificações de configuração
  • Incluir elementos no controle de origem
  • Modificar elementos através de registro de entrada ou de saída, ou interceptação

Se a visualização é uma visualização de desenvolvimento para um projeto, então ambos, entrega e criação de nova base, são suportados. Exceto por essas funcionalidades para desenvolvimento, algumas funções de gerenciamento também estão disponíveis. É possível executar as seguintes tarefas, por exemplo:

  • Modificar, incluir ou excluir dois tipos de metadados listados para VOBs do componente
  • Criar e recomendar linhas de base para fluxos de projeto

Essas funcionalidades são muito comuns, assim, você pode esperar que qualquer ferramenta SCM as suporte. Entretanto, existem três recursos principais que tornam o ClearCase Remote Client mais útil, e as seções a seguir os abordam uma a uma.

Visualização Mudanças Pendentes

No ClearCase Remote Client, como em outras ferramentas SCM, os desenvolvedores trabalham em espaços de trabalho separados para que possam desenvolver em paralelo. Eventualmente, porém, eles precisam integrar seus trabalhos. No ClearCase Remote Client, as funções de entrega e criação de nova base realizam esse trabalho.

Em outro software SCM, não é possível verificar as diferenças entre espaços de trabalho diferentes até depois da conclusão da fusão. Porém, na Visualização Mudanças Pendentes do ClearCase Remote Client, mostrada na Figura 5, é possível verificar todas as diferenças entre o espaço de trabalho local e o espaço de trabalho de destino (que geralmente é o espaço de trabalho de integração) antes que a fusão comece.

Figura 5. Visualização Mudanças Pendentes
Visualização Mudanças Pendentes
Visualização Mudanças Pendentes

As mudanças pendentes são categorizadas em três tipos:

  • Mudanças de entrada, que significa que não existem mudanças no espaço de trabalho local, mas existem mudanças no espaço de trabalho de destino
  • Mudanças de saída, que é o oposto das mudanças de entrada
  • Mudanças conflitantes, que significa que mudanças existem em ambos os espaços de trabalho, local e de destino.

    Na visualização do ClearCase de base, as mudanças pendentes são agrupadas de acordo com elementos hierarquicamente. Na visão de desenvolvimento do seu projeto, elas estão agrupadas por atividades.

Na visualização Mudanças Pendentes, é possível ver as diferenças de elemento do elemento usando a ferramentas de comparação, e então sincronizar o espaço de trabalho.

Além disso, o ClearCase Remote Client uma programação de mudanças pendentes é fornecida. Com esta funcionalidade, é possível programar a visualização Mudanças Pendentes para que as mudanças pendentes possam ser coletadas e exibidas automaticamente em horários predefinidos ou em intervalos regulares.

Esses mecanismos facilitam o processo de integração consideravelmente. Como resultado, é possível economizar muito tempo. Este é um recurso de destaque importante do ClearCase Remote Client, e torna-o adequado para o desenvolvimento de software ágil.

Ação agregada

Durante o desenvolvimento, as seguintes situações quase sempre surgem:

  • Múltiplas necessidades de código de origem a serem incluídas no controle de origem ao inicializar o espaço de trabalho
  • Registro de entrada e de saída, interceptação e a opção de desfazer o registro de saída ou interceptação, para ambos, uma pasta e seus sub-elementos.
  • Localizar o registro de saída ou interceptação sob uma pasta.

    Isso consumiria muito tempo dos desenvolvedores se todas essas ações tivessem de ser feitas uma a uma.Felizmente, o ClearCase Remote Client fornece ações agregadas.Para os primeiros dois casos, é possível selecionar para conter sub-elementos.E para o último caso, as decorações de mudança agregadas são propagadas para o nível superior de uma hierarquia se as mudanças existirem em qualquer nível dessa hierarquia.

    Além disso, é possível executar operações como registrar a entrada, desfazer o registro e desfazer a interceptação agregadamente, em qualquer nó com essa decoração.Este recurso faz com que o andamento do processo de desenvolvimento seja muito mais facilitado.

Integração do ClearQuest

Como mostrado na Figura 3 anteriormente, o ClearQuest é integrado no ClearCase Remote Client. O ClearQuest é o software de gerenciamento de pedido de mudança, e o Unified Change Management (UCM) é uma solução para o gerenciamento de mudança no ciclo de vida do desenvolvimento.A integração cria o UCM de suporte do ClearCase Remote Client.

A integração com o ClearQuest significa que as atividades são gerenciadas de forma centralizada pelo ClearQuest. Isso possibilita aos desenvolvedores focar 100% de sua energia no desenvolvimento. Como resultado, o seu projeto crescerá mais rápido.

Integração contínua de implementação

As seções anteriores introduziram o desenvolvimento de software ágil, a CI, oClearCase Remote Client e o CruiseControl. Você também viu algumas das maneiras como o ClearCase Remote Client suporta o desenvolvimento ágil. Nesta seção, você aprenderá como implementar a CI com o CruiseControl e o ClearCase Remote Client sob a plataforma do Microsoft® Windows® . Primeiro, uma infraestrutura típica para a CI será fornecida, e depois um exemplo de CI sob esta infraestrutura será implementada.

Infraestrutura típica para CI

Para alcançar a CI, você precisa de algumas ferramentas, incluindo o software SCM (ClearCase), uma ferramenta de construção, e uma ferramenta que execute e relata a construção automaticamente (CruiseControl). A Figura 6 mostra uma infraestrutura típica para CI. Como você pode ver na Figura 6, existem três partes:

  • Desenvolvimento
  • Construção de integração
  • Feedback

A primeira parte é desenvolvimento: os desenvolvedores desenvolvem o software editando o código de origem sob o controle de software SCM. A segunda parte é a construção de integração: as pessoas à frente dessa parte são responsáveis pela implementação da CI, como discutido neste artigo.Dentro da CI, uma ferramenta automatizada como a CruiseControl configura e programa a construção de integração.

Após o início de um novo processo de construção, o CruiseControl chama uma ferramenta de construção como a Ant para realizar tarefas predefinidas, incluindo:

  • Atualização do código de origem
  • Compilação
  • Se necessário, teste de™ unidade Java (JUnit)

Após a construção, vem a última parte da infraestrutura de CI, o feedback. Após a construção de integração, o CruiseControl envia resultados aos desenvolvedores através de vários tipos de métodos (por exemplo, e-mail, notificações da Web, e assim por diante). Um resumo do fluxo de trabalho da CI será fornecido na seção Fluxo de Trabalho do CruiseControl .

Figura 6. Infraestrutura da CI
Infraestrutura da CI
Infraestrutura da CI

Teoricamente, se a única funcionalidade suportada são transações de código de origem entre ferramentas de software SCM, seus integradores podem usar um software SCM diferente do de seus desenvolvedores. Porém, para conveniência e clareza, este artigo assume que ambos, os desenvolvedores e os integradores, usam o ClearCase Remote Client como seu software SCM. Como resultado, o código de origem pode se recuperado ou atualizado diretamente durante a cosntrução de integração.

A Figura 6 mostra que um Rational ClearCase Server é necessário. Você deve ter um entendimento básico desse Servidor. Se não tiver, consulte a seção Recursos para obter informações adicionais.

As seções a seguir descreverão a implementação da CI passo a passo:

  1. Inicialize o ambiente
  2. Configure o CruiseControl
  3. Atualize o código de origem usando um programa Java

Na seção Initialize a visualização , você aprenderá como inicializar o ambiente do ClearCase Remote Client. A seção Configure o CruiseControl descreve como configurar o CruiseControl. A seção Configurar o CruiseControl discute a configuração do CruiseControl e fornece um exemplo dos arquivos relevantes.

Antes de construir o código de origem, uma atualização é necessária. Esta funcionalidade é alcançada usando um programa Java com uma interface de programação de aplicativo do Gerenciamento de Configuração (CM API), cujo processo é discutido na seção Fluxo de Trabalho do CruiseControl .

Na última seção deste capítulo, você desenhará um fluxo de trabalho do CruiseControl.

Inicialize o ambiente

Como você sabe, somente é possível acessar o repositório no ClearCase através de visualizações. Portanto, você deve primeiro inicializar a visualização que será usada pelo construtor de integração para acessar o código de origem. Depois disso, você configurará o CruiseControl.

Inicialize a visualização

Suponha que o servidor do ClearCase V7.1 já foi configurado com êxito.Suas próximas etapas serão:

  1. Configurar o Eclipse V3.3.x
  2. Instalar o ClearCase Remote Client V7.1 como um plug-in em relação ao Eclipse
  3. Criar, visualizar e modificar a especificação de configuração, e depois carregar os VOBs

Configurar o CruiseControl

Existem duas partes na configuração desta ferramenta: CruiseControl e Tomcat. Tomcat é usado como um servidor da Web para implementar feedback sobre a construção de integração através da Web.

  1. Instalar o CruiseControl.
  2. Instalar o Tomcat.
  3. Implementar o CruiseControl no Tomcat de acordo com as seguintes etapas.
  1. Parar o Tomcat
  2. Copiar install_path_cruisecontrol\webapps\cruisecontrol para install_path_tomcat\webapps (em que install_path_cruisecontrol representa o local no qual CruiseControl está instalado, e install_path_tomcat significa o caminho no qual Tomcat está localizado).
  3. Iniciar o Tomcat.
  4. Verificar o resultado. Para fazer isso, insira a seguinte URL no seu navegador: http://localhost:port/cruisecontrol. “Port” é a porta que você especificou para o Tomcat. O valor-padrão é 8080.

Configure o CruiseControl

Existem dois arquivos principais para o CruiseControl: um arquivo de configuração e um arquivo de construção. Esta seção os introduz, e depois mostra como criá-los.Ela também descreve em detalhes um programa Java que você usará para atualizar o código de origem automaticamente.

Arquivo de configuração

Você utiliza o arquivo de configuração, config.xml, para configurar o CruiseControl. Ele deve ser colocado diretamente sob o caminho de instalação do CruiseControl. Por exemplo, o caminho completo e o nome para o arquivo de configuração neste exemplo é C:\Program Files\CruiseControl\config.xml.

Geralmente, neste arquivo, você deve especificar o seguinte:

  • O status do CruiseControl
  • O local do Ant
  • O software SCM sob o controle do qual o código de origem está
  • O diretório no qual o código de origem é colocado
  • O local do arquivo de construção
  • O diretório de logs para os resultados da construção

Este artigo não fornece uma descrição detalhada de como o arquivo de configuração deve ser escrito, porque você pode localizar um tutorial sobre como fazer isso em install_path_cruisecontrol\docs\main\configxml.html (em que install_path_cruisecontrol” representa o caminho de instalação do CruiseControl).

Como ele está definido, os sub-elementos sob o elementomodificationset indicam ao CruiseControl o tipo de SCM sob o controle do qual o código de origem está, e o local do código de origem. O sub-elementoclearcase significa que o código de origem está sob controle do Rational ClearCase, enquanto que o sub-elementosistema de arquivos indica que o código de origem não está sob o controle de qualquer software SCM. Numa visão rápida, parece óbvio que você deve usar o sub-elemento clearcase , porque o código de origem que você está usando neste exemplo está sob o controle do ClearCase.

Porém, se você usar o sub-elemento clearcase , e apontar o local para a área de cópia da visualização de captura instantânea, um erro ocorrerá e informará que a origem não está sob controle. Isso é fácil de entender. Da perspectiva do sistema operacional, o código de origem sob a área de cópia da visualização de captura instantânea somente arquivos e diretórios típicos.O motivo pelo qual eles são considerados sob controle da origem é que o arquivo .copyarea.dat está sob o diretório-raiz da visualização de captura instantânea. Porém, CruiseControl não reconhece este arquivo, assim, você deve usar o sub-elemento sistema de arquivos .

Outro problema que pode ocorrer: como você pode atualizar e construir o código de origem? É possível realizar essas ações usando uma ferramenta de construção como a Ant. O local do arquivo de construção deve ser fornecido no arquivo de configuração. O arquivo de construção será discutido em mais detalhes na próxima seção.

A Lista 1 mostra um exemplo de um arquivo de configuração.

Lista 1. Arquivo de configuração
<cruisecontrol>
  <project name=”helloworld”>
<bootstrappers>
  <currentbuildstatusbootstrapper file=”currentbuild.txt” />
</bootstrappers>
<modificationset quietperiod=”300”>
  <filesystem folder=”D:\views\View_CI\VOB_CI\helloworld” />
</modificationset>
<schedule interval=”10”>
  <ant antscript=”apache-ant-1.7.0\bin\ant.bat” 
	buildfile=”D:\ views\View_CI\VOB_CI\build.xml”
	target=”masterbuild” multiple=”1” />
</schedule>
<log dir=”logs\${project.name}”>
  <merge dir=”test-results”/>
</log>
<publishers>
  <currentbuildstatuspublisher file=”currentbuild.txt” />
  <onsuccess>
  <artifactspublisher dir=”C:\Program Files\CruiseControl\logs\${project.name}” 
dest=” C:\Program Files\CruiseControl\Tomcat4.1\webapps\cruisecontrol\artifacts”>
</onsuccess>
<onFailure>
  <artifactspublisher dir=”C:\Program Files\CruiseControl\logs\${project.name}” 
dest=” C:\Program Files\CruiseControl\Tomcat4.1\webapps\cruisecontrol\artifacts”>
</onFailure>
</publishers>
  </project>
</cruisecontrol>

Arquivo de construção

O arquivo de construção lista todas as tarefas que a ferramenta de construção deve executar.O nome do arquivo de construção é build.xml, e você pode colocá-lo em qualquer lugar. O arquivo de configuração deve apontar para o caminho completo ou relativo. Neste exemplo, você usa o Ant como a ferramenta de construção.

Geralmente, existem quatro partes em um arquivo de construção:

  • Preparar o ambiente
  • Atualizar o código de origem
  • Compilar o código de origem
  • Limpar o ambiente

Este artigo somente discutirá a atualização do código de origem.Existem comandos integrados para atualizar o código de origem para sub-elementos como clearcase, cvs, ou outros sob o elemento modificationset no arquivo de configuração. A seção anterior explicou, porém, porque você precisa usar o sub-elemento do sistema de arquivos. Assim, você precisa atualizar a visualização da captura instantânea automaticamente usando a ferramenta de construção.

Felizmente, o ClearCase fornece uma API do CM com a qual você pode escrever um programa em Java para atualizar sua visualização de captura instantânea automaticamente. O método para fazer isso é o seguinte:

  1. Escrever um programa Java usando a API do CM do ClearCase para atualizar a visualização de captura instantânea
  2. Chamar este programa no arquivo de construção CruiseControl.

Informações detalhadas sobre este programa são descritas na próxima seção.

A Lista 2 fornece um exemplo de um arquivo de construção.

Lista 2. Arquivo de construção
  <project name="helloworld" basedir="." default="all">
  <!--property name="build.compiler" value="javac"/-->
  <!--property name="build.compiler.emacs" value="true"/-->
  <property name="build.dir" value="classes"/>
  <property name="dist.dir" value="dist"/>
  <property name="source.dir" value="D:\views\View_CI\Vob_CI\helloworld"/>
  <property name="ccdir" value="C:\Program Files\CruiseControl"/>
  <path id="Update_View.classpath">
    <pathelement location="D:\java workspace\Update_View\bin"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-codec-1.3.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-httpclient-3.0.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/
        commons-logging-1.0.4.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/remote_core.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpcc.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpcmmn.jar"/>
    <pathelement location="D:\java workspace\Update_View\teamapi-jar/stpwvcm.jar"/>
  </path>
  <target name="init" description="Prepare for build">
    <mkdir dir="${build.dir}"/>
    <mkdir dir="${dist.dir}"/>
  </target>
  <target name="clean" description="Clean all build products">
    <delete dir="${build.dir}"/>
    <delete dir="${dist.dir}"/>
    <mkdir dir="${build.dir}"/>
    <mkdir dir="${dist.dir}"/>
  </target>
  <target name="Update_View">
    <java classname="update_view.Update_View" failonerror="true" fork="yes">
       <classpath refid="Update_View.classpath"/>
    </java>
  </target>
  <target name="compile" depends="init,Update_View" description="Compile app">
    <javac srcdir="${source.dir}" destdir="{build.dir}" 
       includes="**/*.java" debug="on" deprecation="true"/> 
  </target>
  <target name="all" depends="init,clean,Update_View,compile" description="Build app"/>
  <target name="masterbuild" depends="compile" description="Master build"/>
  <target name="cleanbuild" depends="clean, masterbuild" description="Clean build"/>
</project>

Programar para atualizar o código de origem

Esta seção discute em detalhes o programa para atualizar o código de origem.

Falando de modo geral, o programa Java que atualiza automaticamente o código de origem é um aplicativo cliente que usa parte da API do CM para varrer elementos que estão sob o controle de origem em um determinado local, e então atualizá-los.

Primeiro, olhe como o servidor do CM lida com pedidos do aplicativo cliente. A Figura 7 mostra a arquitetura relevante.

Figura 7. Arquitetura da API do CM
Arquitetura da API do CM
Arquitetura da API do CM

A Figura 7 mostra que o provedor da API do CM despacha pedidos de um aplicativo cliente para sub-provedores específicos de produto.

Agora, examine como essas APIs do CM são organizadas. As APIs do CM são integrados em quatro pacotes, javax.wvcm, com.ibm.rational.wvcm.stp, com.ibm.rational.wvcm.stp.cq e com.ibm.rational.wvcm.stp.cc.

Como você instala a API do CM? É muito simples. A partir da infraestrutura da API do CM, você sabe que cada instalação de produto individual inclui o componente comum e o sub-provedor da API do Rational CM do produto. Assim, dependendo da combinação de produtos instalados, os sistemas podem ter todos ou um subconjunto dos seguintes arquivos Java archive (JAR):

  • Arquivos JAR da infraestrutura do componente da API do Rational CM
  • Arquivos JAR do sub-provedor da API do Rational CM para ClearCase
  • Arquivos JAR do sub-provedor da API do Rational CM para ClearQuest

Onde estes arquivos estão localizados? Por padrão, os arquivos JAR da API do Rational CM (e outros arquivos JAR necessários) são instalados sob o caminho de instalação comum para os produtos Rational.

Agora, você tem um conhecimento básico da arquitetura da API do CM. A seguir, você construirá o programa Java passo a passo.

  1. Crie um programa Java. A Figura 8 mostra uma captura de tela do programa, Update.java.
Figura 8. Programa Java
Programa Java
Programa Java
  1. Copie os arquivos JAR da API do CM para a área de trabalho do programa. A Figura 9 mostra o local dos arquivos JAR do ClearCase, e a Figura 10 mostra o local dos arquivos JAR do componente comum do Rational.
Figura 9. Arquivos JAR do ClearCase
Arquivos JAR do ClearCase
Arquivos JAR do ClearCase
Figura 10. Arquivos JAR dos componentes comuns do Rational
Arquivos JAR dos componentes comuns do Rational
Arquivos JAR dos componentes comuns do Rational
  1. Importe os arquivos JAR para o programa. A Figura 11 mostra quatro etapas para fazer isso.
    1. Dê um clique com o botão direito do mouse no nome do projeto e selecione Propriedades.
    2. À esquerda, navegue para a página Caminho de Construção Java.
    3. À direita, selecione a guiaBibliotecas .
    4. Clique no botãoIncluir JARs Externos e selecione os arquivos que deseja incluir.
Figura 11. Importar arquivos JAR externos
Importar arquivos JAR externos
Importar arquivos JAR externos
  1. Edite Update.java. Primeiro, você deve importar pacotes para o programa. A Figura 12 mostra o local correspondente no programa.
Figura 12. Importar pacotes
Importar pacotes
Importar pacotes
  1. Segundo, dada a arquitetura da API do CM, você sabe que precisa obter os provedores da API do CM antes de acessar qualquer recurso. A Lista 3 fornece os comandos para obter um provedor.

A classe MyAuthCallback , que implementa a interface Callback no pacote javax.wvcm.ProviderFactory , é usada para obter a autenticação. Os parâmetros CMServerUrl, delogin e senha representam a URL do Servidor do CM, o nome de login, e a senha de login, respectivamente. Todos eles precisam ser pré-designados.

O formato de CMServerUrl é o seguinte: http://ip:port/TeamWeb/services/Team, em que “ip” é o endereço de IP do Servidor do CM, e "port" é 12080 por padrão.

Lista 3. Obtenha o provedor da API do CM
//new an instance of class MyAuthCallback
Callback callback = new MyAuthCallback(serverUrl, login, password);
//get provider with instance of callback
CcProvider provider = (CcProvider)
      Providerfactory.createProvider(CcProvider, .PROVIDER_CLASS, callback);
  1. Agora que você tem um provedor, a próxima etapa é obter a visualização que foi criada durante a inicialização. Como você sabe, o diretório-raiz da visualização de captura instantânea é um diretório comum. Dois arquivos especiais (.copyarea.dat e .copyarea.db) que estão sob o diretório fazem dele o diretório-raiz de uma visualização.

Para obter os recursos de uma visualização, você precisa verificar se esses dois arquivos existem. Se eles existirem, a visualização é obtida. Se não, um erro é retornado. A Lista 4 mostra os comandos que você pode usar para obter uma visualização. Entre os comandos, os comentários iniciam com uma barra e dois asteriscos (“/**”). Substitua-os pelos comandos para verificar os dois arquivos.

O parâmetro loc é o caminho da área de cópia da visualização de captura instantânea.

Lista 4. Obter visualização
//new object of file with the root directory.
File file = new File(loc);
//the directory is a copy area for a certain snapshot view.
StpLocation stplocation = (StpLocation)
 provider.filePathLocation(StpLocation.Domain.CLEAR_CASE, file);
  1. Após obter uma visualização, você deve coletar os recursos carregados nessa visualização para atualização. A Lista 5 mostra os comandos principais para coletar recursos.
Lista 5. Coletar recursos
//get proxy for resource
ControllableResource res = getProxy(loc, provider);
//get properties for resource.
PropertyRequest prop = new PropertyRequest
(new PropertyRequestItem[] (ControllableResource.IS_VERSION_CONTROLLED));
Res = (ControllableResource) res.doReadProperties(prop);
//if the resource is under source control, add it into resource list. It will be updated
if ( res.getIsVersionControlled()) resourcelist.add(res);
  1. Agora você chega à última etapa, que é atualizar os recursos. A Lista 6 mostra o comando que você pode usar para fazer isso. Neste comando, "visualização" é o objeto de visualização que você criou na Lista 4, e o parâmetro resourcelist contém todos os recursos que você coletou através dos comandos na Lista 5.
Lista 6. Atualizar recursos
//atualizar recursos
View.doUpdate(resourcelist, PropertyRequest.EMPTY);

Até aqui, este artigo discutiu todas as ações necessárias para implementar a CI. Além disso, você configurou o ambiente da CI. A construção de integração ocorrerá quando ela estiver planejada no arquivo de configuração. Na próxima seção, você examinará o fluxo de trabalho da CI.

Fluxo de trabalho CruiseControl

Você definiu e configurou o ambiente. Agora você aprenderá como este ambiente funciona.

A Figura 13 descreve o fluxo de trabalho geral da CI com CruiseControl e ClearCase Remote Client.

Figura 13. O fluxo de trabalho da CI em CruiseControl
O fluxo de trabalho da CI em CruiseControl
O fluxo de trabalho da CI em CruiseControl

Como a Figura 13 mostra, CruiseControl primeiro lê o arquivo de configuração (config.xml) para obter as informações de configuração como as seguintes:

  • Edição de Ant
  • Local do código de origem
  • Estilo do código de origem
  • E assim por diante

Então, o controle de processo é passado para Ant. Ele lê o arquivo de construção primeiro, e depois executa uma classe Java que é usada para atualizar o código de origem. Depois, ele constrói o código de origem que está sob o controle ClearCase. A última etapa é enviar o feedback.

Existem vários tipos de métodos de feedback, incluindo Web, e-mail, e assim por diante. Para obter informações adicionais, consulte o site da Web do CruiseControl na seçãoRecursos .

O que você aprendeu

ClearCase Remote Client, um cliente para Rational ClearCase, contém muitos recursos e características que suportam o desenvolvimento ágil, incluindo:

  • Navegador compactado. Todos os artefatos suportados pelo ClearCase Remote Client são exibidos neste nevegador. Os desenvolvedores podem facilmente criar, editar e excluir elementos dele.
  • Visualização Mudanças Pendentes. As mudanças pendentes representam mudanças entre áreas de trabalho paralelas. A visualização Mudanças Pendentes lista todas as mudanças pendentes. Nela, os desenvolvedores podem convenientemente revisar, entregar e aceitar todas as mudanças.
  • Ação agregada. O processamento em lote sempre é necessário, especialmente durante a inicialização. O ClearCase Remote Client suporta vários tipos de processamento em lote através da ação agregada, incluindo funcionalidade agregada para incluir no controle de origem, registro de entrada, registro de saída e interceptação. Este recurso reduz ou elimina um grande número de etapas e economiza muito tempo como resultado.
  • Integração com o ClearQuest. O ClearCase foca no controle de origem, enquanto o ClearQuest é o software de gerenciamento de pedido de mudança. O Unified Change Management (UCM), que é uma metodologia que integra o ClearCase e o ClearQuest, fornece uma solução para o desenvolvimento de software. O ClearCase Remote Client suporta o UCM, o que o torna uma ferramenta poderosa que é leve ao mesmo tempo.
  • Leve. O ClearCase Remote Client necessita de muito poucos recursos, somente um pequeno espaço par arquivos de instalação, apenas pouca porcentagem de tempo de processador e um pouco de memória. Todas essas características facilitam colocar o ClearCase Remote Client para uso prático.

Todas esses recursos e características significam que o ClearCase Remote Client suporta muito bem o modo de desenvolvimento ágil. A CI é uma das boas práticas de desenvolvimento de software ágil, e como resultado de seu suporte para entrega frequente a partir de áreas de trabalho separadas para uma área de trabalho de integração, ele está se tornando amplamente adotado.

Seu processo de desenvolvimento será muito mais suavizador se você usar o mesmo software SCM em ambos as áreas de trabalho, de desenvolvimento e de integração. Isto porque como mesmo software, nenhuma transação separada é necessária.

A CI também requer que o código de origem controlado possa ser atualizado automaticamente. A API do CM dos produtos Rational possibilita ao ClearCase Remote Client fazer isso. A ferramenta de construção pode chamar um programa candidato simples usando a API do CM. Este aplicativo atualiza o código de origem na visualização de captura instantânea que foi criado no ClearCase Remote Client.

Este artigo mostrou como você pode usar o ClearCase Remote Client, juntamente com o CruiseControl e uma ferramenta de construção como a Ant, para suportar CI e desenvolvimento ágil.


Recursos para download


Temas relacionados

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=457671
ArticleTitle=Integração Contínua com o IBM Rational ClearCase Remote Client
publish-date=12182009