Conteúdo


Usando o IBM Rational Team Concert para o System z e a plataforma Jazz

Parte 4. Como o desenvolvimento entre sistemas com Rational Team Concert para System z funciona

Combinações de equipes de desenvolvedores de aplicativo da Web e mainframe

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Usando o IBM Rational Team Concert para o System z e a plataforma Jazz

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Usando o IBM Rational Team Concert para o System z e a plataforma Jazz

Fique ligado em conteúdos adicionais dessa série.

Este é o quarto artigo de uma série sobre o IBM® Rational Team Concert™ para System z® (chamado simplesmente de Rational Team Concert de agora em diante). Neste artigo, enfocaremos a configuração de componentes e fluxos no Rational Team Concert para otimizar o desenvolvimento entre sistemas.

Este artigo usa o mesmo aplicativo entre plataformas que usamos como exemplo no segundo artigo desta série (consulte "Também nesta série") para mostrar como o IBM® Rational® Developer para System z® (às vezes conhecido apenas como Rational Developer) e o Rational Team Concert funcionam juntos.

Observação: Algumas das capturas de tela deste artigo foram editadas para tornar a sua leitura mais fácil.

Contexto

O cenário deste artigo tem como base uma equipe de desenvolvimento responsável por manter um aplicativo de pagamento de hipotecas entre plataformas. A lógica de negócios do aplicativo está em um conjunto de módulos de programa IBM® CICS®. A persistência do aplicativo é gerenciada nos arquivos de Virtual Storage Access Method (VSAM) e em um banco de dados IBM® DB2®. Este aplicativo tem uma interface de usuário da Web baseada em Java™ funcionando no software IBM® WebSphere® Application Server que invoca a transação CICS através de uma chamada de serviço da Web. Todos os membros fonte do aplicativo são gerenciados no repositório de controle de fonte do Rational Team Concert para System z. A equipe de desenvolvimento tem as subequipes de mainframe e distribuídas, que são responsáveis, respectivamente, pelo mainframe e pelas partes distribuídas.

A equipe de desenvolvimento forneceu um release principal do aplicativo. Agora, a equipe está pronta para iniciar o desenvolvimento do novo release e precisa manter o mainframe e as partes distribuídas (aplicativos da Web) sincronizados. Nas seções seguintes, descrevemos como a equipe pode organizar suas áreas e artefatos de equipe e configurar o processo para o alcance de seus objetivos.

Configurar componentes e fluxos

Nesta seção, você verá como configurar tudo o que cada equipe precisa para trabalhar separadamente e integrar com êxito o trabalho.

Lógica da configuração

As tarefas de desenvolvimento das equipes de mainframe e distribuídas são diferentes. Embora elas usem a mesma área de projeto para gerenciar seus artefatos, definir seus planos e trocar itens de trabalho, cada equipe quer um lugar onde possa desenvolver novas funções sem interferir na outra equipe até o código ficar estável. Depois que ele estiver estável, as equipes deverão integrar a solução.

Por isso, as equipes terão um fluxo dedicado, em que poderão compartilhar e construir os artefatos em desenvolvimento. Sabe-se que a construção pode falhar neste nível; entretanto, os membros da equipe tentarão fornecer e compartilhar artefatos que possam ser construídos com segurança.

As equipes de mainframe e distribuídas estão interligadas porque cada equipe está trabalhando em um aspecto do mesmo aplicativo. A conexão entre as equipes é representada pela definição de um serviço da Web.

As duas equipes concordaram em integrar código estável toda semana. Para essa finalidade, um fluxo de integração foi criado contendo os artefatos distribuídos e de mainframe, e eles executam uma construção semanal relacionada a esses artefatos nesse fluxo de integração. Isso não significa que todos os desenvolvimentos de cada equipe precisam estar congelados e estáveis toda semana. Para a integração semanal, as equipes se comprometeram a compartilhar artefatos estáveis e que devem ser construídos com segurança com os artefatos da outra equipe.

O processo geral requer o gerenciamento claro do código em cada nível do processo de desenvolvimento: código de desenvolvimento, código de teste e código de produção. Por esse motivo, um fluxo que contém o código do teste e um fluxo que tem o código de QA (garantia de qualidade) foram configurados com construções dedicadas.

Um usuário administrativo deve configurar as equipes e os fluxos. Veja a barra lateral para ver como a área do projeto é configurada.

Figura 1. Fluxos usados neste exemplo
Streams within the Source Control folder
Streams within the Source Control folder

Áreas de equipe

Duas áreas de equipe de desenvolvimento são necessárias porque a Equipe de desenvolvimento de mainframe é responsável por manter os módulos do programa CICS de backend, e a Equipe de desenvolvimento distribuída é responsável por manter o front-end da Web. Uma área de equipe é também criada para o Comitê de gerenciamento de projetos, que é a equipe responsável pelo gerenciamento de todo o projeto. Essa equipe aprova determinados itens de trabalho.

Figura 2. Permissões para membros de PMC incluírem uma opção de aprovação
Permissions configuration view
Permissions configuration view

Visualização maior da Figura 2.

Posto que o shell do Rational Team Concert pode ser compartilhado com outros produtos Rational, os desenvolvedores de mainframe podem usar o Rational Developer para System z e o Rational Team Concert para System z para desenvolver e compartilhar COBOL e outros tipos de código de origem que eles usam no mainframe. Da mesma forma, os desenvolvedores da Web podem usar o IBM® Rational® Application Developer e o Rational Team Concert para desenvolver e compartilhar origens de serviço Java™ e da Web. Um desenvolvedor pode também usar os três produtos em um único ambiente de desenvolvimento para desenvolver os aplicativos de mainframe e os serviços da Web.

Componentes

O código de origem e os outros artefatos necessários para este artigo estão agrupados nestes quatro componentes:

  • O componente de aplicativo de mainframe é de propriedade da Equipe de desenvolvimento de mainframe e tem os arquivos de origem COBOL do aplicativo CICS em vários projetos do Rational Team Concert zComponent.
  • O componente de arquivos comuns de mainframe é de propriedade da Equipe de desenvolvimento de mainframe e tem os copybooks comuns, que são solicitados pelo aplicativo CICS.
  • O componente de arquivos de serviço da Web é de propriedade da Equipe de desenvolvimento de mainframe e tem os arquivos Web Services Description Language (WSDL) e WSBind para o serviço da Web CICS. Esse componente é também solicitado pela Equipe de desenvolvimento distribuída para desenvolver os aplicativos front-end da Web.
  • O componente de aplicativo da Web é de propriedade da Equipe de desenvolvimento distribuída e tem os projetos da Web que consistem em projetos da Web e EAR para o front-end da Web.

Fluxos

Conforme discutido anteriormente, haverá cinco fluxos, mais o fluxo de produção. Eles estão organizados na estrutura de biblioteca hierárquica, que é geralmente usada para desenvolvimento de aplicativo de mainframe.

  • Fluxo de desenvolvimento de mainframe é de propriedade da Equipe de desenvolvimento de mainframe, portanto, os desenvolvedores de mainframe fornecem seus conjuntos de mudanças para esse fluxo. Esse fluxo contém estes componentes:
    • Aplicativo de mainframe
    • Arquivos comuns de mainframe
    • Arquivos de serviço da Web
  • Fluxo de desenvolvimento distribuído é de propriedade da Equipe de desenvolvimento distribuída. Esse fluxo tem os componentes de arquivos de serviço da Web e aplicativo da Web.
    Observação: O componente de arquivos de serviço da Web está presente nos dois fluxos de desenvolvimento, mas é de propriedade da Equipe de desenvolvimento de mainframe. Os desenvolvedores distribuídos fornecem seus conjuntos de mudanças a esse fluxo.
  • O Fluxo de integração de desenvolvimento é usado para que os aplicativos de mainframe e distribuídos criem um aplicativo de pagamento de hipotecas completo entre plataformas. Esse fluxo é de propriedade da área de projeto a que os membros de ambas as equipes pertencem. Esse fluxo tem componentes existentes no Fluxo de desenvolvimento de mainframe e no fluxo de desenvolvimento distribuído.
  • O Fluxo de teste é usado para promoção. É o fluxo de destino das mudanças promovidas a partir do Fluxo de integração de desenvolvimento. A promoção é feita pela substituição dos componentes desse fluxo com as linhas de base no Fluxo de integração de desenvolvimento. Esse fluxo está disponível na área do projeto de cada equipe.
  • Fluxo de QA é também um fluxo promocional, mas usado para fins de garantia de qualidade. Os componentes do Fluxo de teste são promovidos para esse fluxo. A promoção é feita também pela substituição dos componentes desse fluxo com as linhas de base do Fluxo de teste.

Por fim, um fluxo de produção acompanha a origem implementada na produção (não mostrado no diagrama).

O diagrama da Figura 3 mostra os fluxos e os fluxos usados neste exemplo.

Figura 3. Fluxos e fluxos usados neste exemplo.
Flow diagram of the streams
Flow diagram of the streams

Definições de conjunto de dados, Conversores e Definições de idioma

Definições de conjunto de dados, Conversores e Definições de idioma são objetos de modelo do IBM® Jazz™ usados para Rational Team Concert Ant com extensões para a construção z/OS build (também conhecida como Antz), que é um tipo de construção suportado pelo Rational Team Concert para a construção de aplicativos de mainframe. Para realizar uma construção Antz com êxito, eles precisam ser configurados corretamente.

Neste exemplo, nomes/concatenações DD precisam ser definidos de maneira diferente em Conversores, dependendo dos fluxos.

Por exemplo, o Fluxo de teste está usando CICS Versão 4.1, enquanto o fluxo de integração de desenvolvimento está usando CICS Versão 3.2. Uma concatenação DD diferente precisa ser especificada para SYSLIB. Para lidar com essas situações, o Rational Team Concert permite que os administradores de construção incluam propriedades de construção em nomes/concatenações DD. Essas propriedades de construção recebem valores referentes a Definições de conjunto de dados, em Definições de construção.

Figura 4. Use de uma propriedade de construção na concatenação SYSLIB
Edit DD concatenation page
Edit DD concatenation page

Outro requisito neste exemplo é que os arquivos de host precisam estar em conjuntos de dados diferentes, dependendo dos fluxos no momento da construção.

O Rational Team Concert define um tipo de projeto Eclipse especial denominado projeto zComponent para aplicativos de mainframe. zComponent pode conter uma ou mais pastas denominadas zFolders. Uma zFolder é associada a uma Definição de conjunto de dados a fim de fazer referência a um conjunto de dados PDSE no sistema z/OS. Uma zFolder pode conter um ou mais arquivos denominados zFiles. Quando um zFile precisa ser criado por uma construção Antz, ele é associado a uma Definição de idioma.

Figura 5. zProject, zFolder e zFile
Structure of a zProject
Structure of a zProject

Em um exemplo mostrado na Figura 5, o zProject MortgageApplication-EPSCMORT tem uma zFolder BMS, que tem um zFile EPSMORT.bms. Quando esse projeto é carregado a partir do Jazz SCM, um membro cujo nome EPSMORT é criado em um conjunto de dados, que tem as características definidas na Definição de conjunto de dados, que está associada à zFolder BMS.

Como o zProject MortgageApplication-EPSCMORT está contido em fluxos diferentes, o zFile EPSMORT.bms precisa ser carregado em conjuntos de dados diferentes, dependendo do fluxo. Isso é feito com o uso da propriedade de construção do prefixo do conjunto de dados definida nas definições de construção criadas pelo modelo de definição de construção Antz.

Figura 6. Prefixo do conjunto de dados na definição de construção Antz
Data set prefix field shows HLQ.INTG
Data set prefix field shows HLQ.INTG

Modo de exibição ampliado da Figura 6.

Por exemplo, se a definição de construção de Fluxo de teste definir a propriedade de construção do prefixo do conjunto de dados como HLQ.TEST e a do Fluxo de integração de desenvolvimento definir a propriedade de construção do prefixo do conjunto de dados como HLQ.INTG, o zFile EPSMORT.bms será carregado como o membro EPSMORT no conjunto de dados HLQ.TEST.BMS do Fluxo de teste e no conjunto de dados HLQ.INTG.BMS do fluxo de integração de desenvolvimento, respectivamente, quando a construção ocorrer.

Definições de construção

Cada fluxo tem uma área de trabalho de repositório definida especificamente para uso durante a construção do fluxo.

A construção do Fluxo de desenvolvimento de mainframe é definida com o uso do modelo de definição de construção "Antz – Rational Build Agent".

Quando um projeto zComponent é criado no cliente Rational Team Concert Eclipse, um script de construção Antz padrão (build.xml) é criado automaticamente. Para esse exemplo, o script de construção usado para a construção do Fluxo de desenvolvimento de mainframe é modificado a partir do padrão para a inclusão de mais tarefas e destinos, para o fornecimento de informações adicionais de ordem de construção para o código de tempo de execução de Antz. O exemplo no código da Listagem 1 especifica que os mapas de BMS devem ser processados antes da compilação de COBOL.

Listagem 1. Script de construção para a construção do Fluxo de desenvolvimento de mainframe
<antz:compile>
    <restrict>
        <antz:buildableset 
            buildableList="${teamz.scm.fetchDestination}/buildableFiles.xml"/>
        <antz:langdefselector name="BMS"/>
    </restrict>
</antz:compile>
<antz:compile>
    <restrict>
        <antz:buildableset 
            buildableList="${teamz.scm.fetchDestination}/buildableFiles.xml"/>
        <rsel:or>
            <antz:langdefselector name="COBOL*"/>
        </rsel:or>
    </restrict>
</antz:compile>

Como o script de construção usado para a construção de Antz é um arquivo de construção Ant, os tipos de dados e as tarefas de Ant padrão podem ser usados além das extensões de construção fornecidas por Antz.

Por exemplo, no aplicativo de hipoteca, algumas instruções SQL estão integradas ao código de origem de COBOL, que requer que o comando DB2 BIND PACKAGE seja executado. Isso pode ser feito por uma tarefa de execução Apache Ant padrão ou, como mostra a Listagem 2, com um script REXX sendo chamado a partir do script de construção de Antz por meio do uso do comando de shell TSO z/OS UNIX®.

Listagem 2. Comando de pacote de união de DB2
<!-- Macro definition for DB2 BIND PACKAGE command -->
<macrodef name="db2BindPackage">
    <attribute name="system"/>
    <attribute name="package"/>
    <attribute name="library"/>
    <attribute name="member"/>
    <attribute name="owner"/>
    <attribute name="qualifier"/>
    <attribute name="action"/>
    <attribute name="isolation"/>
    <sequential>
        <exec executable="tso" failonerror="true">
            <arg line="&quot;EXEC 'TAMI.JAZZ.EXEC(PACKBIND)' 
                '@{system} @{package} @{library} @{member} @{owner} @{qualifier} 
                   @{action} @{isolation}'&quot;"/>
        </exec>
    </sequential>
</macrodef>


<db2BindPackage
           system="DSN9"
           package="DEV2"
           library="${teamz.scm.dataset.prefix}.DBRM"
           member="EPSCMORT"
           owner="DEVDBA"
           qualifier="DEVDBA"
           action="REPLACE"
           isolation="CS"/>

A construção do Fluxo de desenvolvimento distribuído usa o IBM® Rational® Application Developer para o Build Utility (BU) do software WebSphere®. É possível usar o BU para criar projetos do Rational Application Developer sem usar o ambiente Eclipse IDE. Há versões do BU para as plataformas Microsoft® Windows®, Linux® e IBM® z/OS®. Neste exemplo, usamos uma versão z/OS.

O utilitário de construção fornece outro conjunto de extensões Apache Ant. Neste exemplo, a construção do Fluxo de desenvolvimento distribuído é definida pelo uso de uma definição de construção de Antz e usa dois scripts de construção de Ant. Um é para Antz e outro é para BU. O primeiro é especificado na definição de construção e invoca o script de shell runAnt_zos.sh, especificando o segundo script de construção em um argumento de comando para realizar a construção usando o BU.

Listagem 3. Construção do aplicativo J2EE
<exec executable="${bu.installDir}/eclipse/bin/runAnt_zos.sh" 
    failonerror="true">
    <arg value="-buildfile"/>
    <arg value="${basedir}/build.xml"/>
    <arg value="all"/>
    <env key="workspace" value="${teamz.scm.fetchDestination}"/>
</exec>

A construção do Fluxo de integração de desenvolvimento simplesmente combina a construção do Fluxo de desenvolvimento de mainframe e a construção do Fluxo de desenvolvimento distribuído (consulte a Listagem 3). Defina-a usando o modelo de definição de construção de Antz. Essa definição constrói o aplicativo de mainframe primeiro e invoca o script de construção do BU.

Listagem 4. Código da construção do Fluxo de integração de desenvolvimento
<!-- Invoke distributed build -->
<target name="distributed" description="Distributed build">
    <ant antfile="${teamz.scm.fetchDestination}/Automation/automation.xml"/>
</target>

As construções do Fluxo de teste e do Fluxo de QA são definidas da mesma forma que a construção do Fluxo de integração de desenvolvimento, com destinos diferentes de implementação.

Cenário

A equipe acabou de liberar uma versão principal do aplicativo. Os requisitos do próximo release do aplicativo estão sendo revisados. Para esse cenário, será enfocado apenas um requisito específico:

Um campo de pagamento de entrada deve ser adicionado a um copybook e considerado no cálculo da hipoteca.

Para preservar a compatibilidade com a versão atual do novo serviço, será criada uma nova operação e adicionado o campo de pagamento de entrada à mensagem de entrada.

Essa mudança afeta a lógica do aplicativo de mainframe: é preciso implementar um novo método de cálculo do pagamento mensal para responder por esse novo campo. Isso também requer uma mudança na estrutura de dados exposta nos serviços da Web e usada pelo Web client.

Vamos ver como a equipe lida com essa mudança que implementa um novo contrato entre os aplicativos cliente e servidor e que requer que a sincronização entre as duas equipes seja levada em consideração.

Formas de se trabalhar com o item Adoção

A equipe do PMC cria um item de trabalho Adoção na área do projeto. Os itens Adoção são usados para documentar o impacto das mudanças, discutir o impacto entre equipes e programar a adoção. O novo item Adoção fica visível no painel (Figura 7); por isso, os membros da equipe podem cuidar do item de trabalho e fazer comentários sobre ele.

Figura 7. O painel do aplicativo de hipoteca destaca o item Adoção
Open Adoption list highlighted in the dashboard
Open Adoption list highlighted in the dashboard

Agora, o item de trabalho está no estado Proposto. Quando os líderes do projeto decidirem que o item precisa ser incluído no próximo release, o status será alterado para Aprovado (consulte a Figura 8).

Figura 8. O item de trabalho Adoção aparece aprovado pelo PMC
Screen capture of Adoption Item 18 work item
Screen capture of Adoption Item 18 work item

Visualização maior da Figura 8.

Novos itens de trabalho são criados para a Equipe de desenvolvimento de mainframe e a equipe de desenvolvimento distribuída para que cuidem da adoção da mudança. Os registros de aprovação são atualizados no item de trabalho para controlar a adoção da nova função pelas equipes afetadas.

Iniciar a implementação da nova função

Como parte da manutenção do código de liberação, uma captura instantânea dos componentes no fluxo de integração foi feita. A captura instantânea é o processo de criação de uma linha de base de vários componentes sincronizados em um fluxo.

O conteúdo do fluxo de integração foi também promovido para os fluxos de teste e QA. Assim, os componentes nesses três fluxos agora têm os mesmos conteúdos e as mesmas linhas de base.

Os fluxos de desenvolvimento também estão provavelmente sincronizados com o fluxo de integração. Mas eles podem conter um novo código que ainda não estava pronto para ser incluído no release anterior, portanto, ele ainda não foi colocado no fluxo de integração. Os fluxos de desenvolvimento estão sincronizados com as linhas de base do componente do fluxo de integração ou contêm alguns conjuntos de mudanças adicionados a essas linhas de base.

O WSDL está localizado no componente de arquivos de serviços da Web. Este componente é de propriedade da Equipe de desenvolvimento de mainframe e é usado pela Equipe de desenvolvimento distribuída.

A Figura 9 mostra que o Fluxo de desenvolvimento distribuído tem a Linha de base 5 do componente de arquivos de serviços da Web. Essa é a mesma linha de base do Fluxo de Integração de desenvolvimento.

Figura 9. Linhas de base de componente em fluxos de desenvolvimento
Web Services Files components highlighted in each
Web Services Files components highlighted in each

O Fluxo de desenvolvimento distribuído está completamente sincronizado com o fluxo de integração. Observe que o Fluxo de desenvolvimento de mainframe tem uma linha de base diferente do componente dos arquivos de serviço da Web e do componente de aplicativo de mainframe. Por isso, o conteúdo do Fluxo de desenvolvimento de mainframe pode estar à frente do que foi tem sido compartilhado no fluxo de integração.

Como desenvolver a nova função

Os itens de plano da iteração atual (Figura 10) refletem o trabalho do mainframe a ser feito para implementar o novo requisito.

Figura 10. Itens de plano do novo requisito
Story and sub-tasks viewed in the Plan item
Story and sub-tasks viewed in the Plan item

A equipe de mainframe é a primeira a implementar a nova função. Eles atualizam o copybook e, usando as ferramentas do serviço da Web do Rational Developer, atualizam os arquivos do serviço da Web. Essas mudanças criam dois conjuntos de mudança anexados ao item de trabalho relevante e entregues ao Fluxo de desenvolvimento de mainframe.

A equipe de mainframe verifica se a sua construção foi executada com êxito. Como resultado da construção, novas linhas de base são criadas para os componentes que tinham mudanças.

O desenvolvimento da nova função envolve as duas equipes. A equipe de mainframe é responsável por fornecer o trabalho inicial na atualização do copybook e dos arquivos de serviço da Web.

Nesse estágio, a equipe de mainframe concluiu a sua parte do trabalho. O Fluxo de desenvolvimento de mainframe tem os novos arquivos de serviço da Web. O Fluxo de desenvolvimento distribuído não os tem e também não tem o fluxo de integração.

A Figura 11 mostra que o Fluxo de desenvolvimento de mainframe tem a Linha de base 7 do componente de arquivos de serviços da Web, com os novos desenvolvimentos. O Fluxo de desenvolvimento distribuído e o Fluxo de integração de desenvolvimento ainda têm a linha de base 5 do componente de arquivos de serviços da Web.

Figura 11. Linhas de base de componente atualizadas nos fluxos de desenvolvimento
Mainframe Web Services Files entry shows a change
Mainframe Web Services Files entry shows a change

A equipe de mainframe resolve seu item de trabalho para notificar a equipe distribuída de que as alterações estão prontas para adoção. Eles também marcam, no registro de aprovação do item de adoção, que a mudança foi adotada pela sua equipe.

Figura 12. Aprovações de item de trabalho
Screen segment shows Approver and State
Screen segment shows Approver and State

A equipe de mainframe poderá agora fornecer os novos arquivos de serviço da Web ao fluxo de integração. Entretanto, se eles tiverem feito isso, a construção no nível de integração falhará porque a equipe distribuída ainda não efetuou as alterações necessárias para levar em consideração os novos arquivos de serviço da Web. Por isso, eles aguardarão até o item Adoção seja adotado pelas duas equipes antes da entrega dos arquivos atualizados ao fluxo de integração.

A Equipe de desenvolvimento distribuída agora precisa levar em consideração os novos arquivos de serviço da Web. Eles têm duas opções:

  • Eles poderão encontrar os itens de trabalho que foram resolvidos pela equipe de mainframe e aceitar os conjuntos de mudança anexos em suas áreas de trabalho. Essa solução funciona bem para pequenas mudanças que precisam ser trocadas rapidamente entre os membros da equipe.
  • Ou eles poderão substituir a linha de base atual do componente de arquivos de serviço da Web no Fluxo de desenvolvimento distribuído por uma que esteja presente no Fluxo de desenvolvimento de mainframe. Essa solução funciona melhor nesse caso porque a equipe pode obter um componente consistente disponível no seu fluxo.

O líder de equipe da equipe distribuída substitui a linha de base do componente de arquivos de serviço da Web em seu fluxo editando o fluxo e usa a função "Substituir por…" para selecionar a nova linha de base do fluxo de desenvolvimento de mainframe. A Figura 13 mostra as ações executadas pelo líder da equipe.

Figura 13. Substituindo uma linha de base de componente por outra
Replace component dialog in the Stream editor
Replace component dialog in the Stream editor

Agora, o fluxo de desenvolvimento distribuído tem os novos arquivos de serviço da Web que foram produzidos pela equipe de mainframe. A equipe distribuída efetua as alterações necessárias em seu aplicativo da Web para adotar o novo campo de pagamento de entrada. Após elas terem sido integradas e testadas com êxito no código, eles farão uma nova captura instantânea do seu fluxo. Eles também marcam, no registro de aprovação, que a mudança foi adotada.

O item Adoção agora foi aceito pelas duas equipes, portanto, o PMC altera o estado do item para Concluído. As duas equipes podem agora fornecer suas mudanças ao fluxo de integração.

Figura 14. Item Adoção concluído
Checkmark beside 'Completed'
Checkmark beside 'Completed'

Neste ponto, o fluxo de integração deverá ter as mudanças das duas equipes. A construção semanal programada para validar a integração das mudanças das duas equipes será executada com êxito.

Promoção

Como parte do ciclo de vida de desenvolvimento do software, o código é promovido através de vários estágios de desenvolvimento do produto. Após a integração com êxito das mudanças na construção semanal, as equipes poderão verificar as saídas.

Quando estiverem satisfeitos com a nova função no fluxo de integração de desenvolvimento, eles notificarão o líder da equipe de teste. O líder de teste substitui todos os componentes da Equipe de teste pelas linhas de base do fluxo da equipe de desenvolvimento. Nesse nível, os testadores podem iniciar o teste do release mais recente do produto. Se descobrirem um defeito, eles criarão um novo item de trabalho para controlar a correção do defeito e atribuir a ele a equipe apropriada.

As equipes precisam seguir o mesmo processo para colaborar com a correção e fornecê-la ao Fluxo de integração de desenvolvimento. Por fim, uma nova captura instantânea contendo a correção é criada e promovida para o Fluxo de teste.

Em seguida, os testadores refazem o teste. Quando estiverem satisfeitos com o release, eles seguirão o mesmo processo para promover o código do fluxo de teste para o fluxo de QA. Nesse estágio, o produto está pronto para ser verificado, para garantir que os requisitos sejam atendidos.

Resumo

Este artigo mostrou como o IBM Rational Team Concert para System z pode atender às necessidades de desenvolvimento de aplicativos entre plataformas, o que inclui mainframe e as partes distribuídas. Por meio do exemplo de uma mudança no contrato para implementar uma nova função, você viu como duas subequipes podem planejar, colaborar e implementar a nova função ao compartilhar o novo contrato no nível de subequipe primeiro e depois ao integrá-lo quando as duas subequipes tiverem concluído os seus trabalhos.

Revise a seção Recursos na sequência para mais informações sobre estes e outros recursos não abordados neste artigo.


Recursos para download


Temas relacionados


Comentários

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=479441
ArticleTitle=Usando o IBM Rational Team Concert para o System z e a plataforma Jazz: Parte 4. Como o desenvolvimento entre sistemas com Rational Team Concert para System z funciona
publish-date=03312010