Orientação sobre termos e conceitos neste artigo

No desenvolvimento em um ambiente de equipe colaborativo, muitas vezes é necessário segregar as atividades de desenvolvimento em fluxos de trabalho diferentes. Isso pode ser baseado em recursos (por exemplo, um conjunto de melhorias de segurança isoladas das mudanças interface gráfica com o usuário) ou pode ser um conjunto de defeitos que precisam ser isolados de novos trabalhos de desenvolvimento de modo que um lançamento de correção de defeito possa ser rapidamente entregue aos clientes. Há muitas razões para a criação essa separação de trabalho, e em muitos sistemas de gerenciamento de versão, isso é entregue por meio de uma série de ramificações paralelas.

No IBM® Rational Team Concert™ o desenvolvimento paralelo é suportado pelo uso de vários fluxos. O trabalho realizado por desenvolvedores flui para um fluxo específico e é integrado ao trabalho de outros desenvolvedores que estão trabalhando no mesmo fluxo. Usando diversos fluxos, os esforços de diferentes subequipes de desenvolvedores são separados até que uma atividade específica seja executada para integrar o trabalho de diversos fluxos.

Para simplificar, os fluxos permitem que a equipe integre automaticamente o trabalho de quem está trabalhando de uma maneira altamente colaborativa com o trabalho de outros no momento certo.

O propósito deste artigo é definir um processo de desenvolvimento paralelo usando os recursos do Rational Team Concert pela descrição de um cenário e das etapas para a criação de tal cenário. O padrão mostrado inclui muitos aspectos do desenvolvimento que em geral são necessários para as equipes, mas o processo pode ser modificado para oferecer suporte aos requisitos específicos de qualquer organização ou processo de desenvolvimento.

É "agile"?

Um dos principais princípios do desenvolvimento agile é a integração frequente de mudanças produzidas por cada desenvolvedor e a criação continuada de código de aplicativo recém-integrado. Em resultado disso, alguns puristas do agile talvez considerem que um processo formalmente segregado está fora do escopo do desenvolvimento agile. Contudo, a escala de alguns esforços de desenvolvimento significa que uma única equipe colocalizada talvez não seja possível. Além disso, a escala e a complexidade da mudança podem ser verdadeiramente assustadoras, resultando na necessidade de segregação. Os princípios de IBM® agility@scale™ incentivam o particionamento da equipe e, portanto, a designação do trabalho a equipes diferentes.

Em resultado da segregação física das equipes ou da enorme complexidade do empreendimento, talvez faça sentido apresentar um grau de separação e integração controlada em uma equipe de desenvolvimento agile. Isso pode se manifestar em um fluxo de acordo com a localização ou em um fluxo de release específico. O Rational Team Concert pode oferecer suporte a equipes agile à medida que elas dividem o trabalho a ser feito em, por exemplo, uma série de fluxos de recurso integrados um fluxo de integração compartilhado.

É verdade que muitas equipes agile usam ferramentas de desenvolvimento freeware ou de baixo custo, que oferecem suporte limitado ao desenvolvimento segregado. Essas ferramentas muitas vezes levam os desenvolvedores a uma abordagem segregada devido a limitações funcionais e ao gasto adicional elevado de integração dentro de tais ferramentas. O Rational Team Concert é um mecanismo por meio do qual muitas equipes agile elevam seus padrões e levam sua capacidade de desenvolvimento para um nível superior em termos de eficiência, flexibilidade e criatividade que podem ser incluídos em seus processos de desenvolvimento.

O Rational Team Concert pode oferecer suporte a esforços de desenvolvimento de pequenas equipes agile colocalizadas até grandes equipes distribuídas compostas de muitas subunidades menores de atividade o desenvolvimento agile. Algumas das principais características das equipes agile e a abordagem de Entrega Agile Disciplinada são descritos por Scott Ambler em seu post de blog (consulte a seção Recursos ).

Evolutivo

"As estratégias agile são de natureza iterativa e incremental", diz Ambler. A estrutura de fluxo deve ter permissão de evoluir para suportar as necessidades atuais do projeto. Ter uma equipe que entenda processos de fluxos, integração e desenvolvimento garantirá que a ferramenta de gerenciamento de configuração de software ofereça suporte às atividades da equipe, a qualquer momento. Toda a estrutura de desenvolvimento paralelo do projeto não tem necessariamente de ser projetada antes de o projeto começar a escrever código, mas alguns princípios devem ser entendidos por todos. Eles devem incluir o gerenciamento de integração entre fluxos, o controle de fluxos de release e a segurança e o gerenciamento de trabalho não concluído durante um sprint e deixado "pendente" em um fluxo ou área de trabalho.
 

Altamente colaborativo

Os mecanismos utilizados para compartilhar o trabalho e manter a visibilidade da atividade do desenvolvedor podem transformar uma equipe agile média em uma equipe agile de alta eficiência. Ensinar aos usuários os mecanismos de compartilhamento de conteúdo e entender o que outros desenvolvedores estão fazendo é fundamental para evitar desperdício de tempo e desenvolvimento ineficaz.
 

Auto-organização dentro de uma estrutura de governança adequada

O gerenciamento da configuração é uma área sobre a qual muitos documentos de processo foram escritos (incluindo por este autor), mas poucos foram lidos. Ter o nível certo de estrutura de governança é fundamental para fazer os desenvolvedores ver o valor das coisas que pedimos que eles façam especificamente em relação à área de gerenciamento de configuração. Configurar uma estrutura de processo que permita às equipes entender o que precisam fornecer a fim de liberar um aplicativo para a produção, mas deixá-las desenvolver seu próprio processo de como chegar lá, é uma ótima maneira de permitir que as equipes sejam organizadas e autocriativas. Essas equipes auto-organizadas muitas vezes se aproximam da abordagem mais adequada para elas com base no tipo de desenvolvimento que estão fazendo, nas qualificações da equipe e na tecnologia de automação disponível. Consulte o link em Recursos para obter mais informações sobre modelos de processo e estruturas de automação.
 

Introdução ao Rational Team Concert

Supõe-se que o leitor tenha entendimento básico do Rational Team Concert e dos princípios gerais de gerenciamento de configuração de software. Mais informações sobre o Rational Team Concert e outros produtos associados podem ser encontradas no Web site Jazz.net. Para ajudar o leitor deste artigo, vários conceitos e termos de produtos principais para desenvolvimento paralelo estão incluídos nesta seção.

Fluxo

O fluxo é similar em conceito a uma ramificação na maioria dos outros sistemas de controle de versão. Mas há algumas diferenças significativas que permitem operações específicas ao usar o Rational Team Concert. Os fluxos servem de ponto de coleta de mudanças que podem ser entregues a outros fluxos. Nos cenários apresentados aqui, os fluxos são usados para coletar as mudanças em uma unidade lógica que é, então, entregue a outro fluxo para gerenciar a release. Muitas estruturas de desenvolvimento paralelo dentro de outros sistemas de gerenciamento de versão se tornam muito difíceis de usar depois de um tempo, devido ao número de ramificações existentes. Após o trabalho em um fluxo do Rational Team Concert ser concluído, o fluxo pode ser removidos, porque todo o conteúdo será movido para outro local. Dessa maneira, os fluxos podem ser considerados uma estrutura temporária para trabalho ou uma estrutura mais permanente para a preservação e gravação de trabalho.
 

Conjunto de mudanças

Quando são feitas mudanças nos arquivos sob controle de versão no Rational Team Concert, elas precisam ser gerenciadas e acompanhadas. Alguns sistemas de controle de versão fazem isso arquivo por arquivo, e o conteúdo é mesclado de ramificação para ramificação, arquivo por arquivo. Isso muitas vezes resulta em erros, conteúdo esquecido ou arquivos com mesclagem errada que podem resultar em compilações quebradas ou em trabalho parcialmente concluído. Os desenvolvedores têm um processo natural de agrupar as mudanças de arquivos em conjuntos que, logicamente, formam uma unidade completa de trabalho. Essa tarefa de agrupamento é executada como parte do processo de entrada do Rational Team Concert, no qual um conjunto de mudanças é criado e gerenciado. Na maioria dos cenários, um conjunto de mudanças é então associado a um item de trabalho, como tarefa, defeito ou história. Isso permite que o contexto do conjunto de mudanças fique visível, e que os membros da equipe visualizem as mudanças executadas para atender os requisitos do item de trabalho.
 

Linha de base

Em intervalos específicos durante um projeto de desenvolvimento, é necessário metaforicamente desenhar uma linha na areia e identificar o conteúdo do arquivo que, coletivamente, forma uma unidade estável e liberável de software (ou outra unidade de trabalho útil mantida dentro do sistema de gerenciamento de versão). O ponto de identificação usado dentro do Rational Team Concert é a linha de base. Aplicar uma linha de base identifica os arquivos presentes, bem como seu conteúdo com versão específico, no momento em que a linha de base é aplicada. As linhas de base podem ser usadas como ponto de referência mais adiante para obter acesso a uma configuração específica de arquivos. As linhas de base podem ser comparadas para mostrar as diferenças que existem e, assim, a atividade do desenvolvedor, entre dois pontos marcados no tempo.

Em muitos sistemas de controle de versão, a comparação de linha de base mostrará as diferenças como uma lista de arquivos que mudaram entre os dois pontos. O Rational Team Concert pode apresentar as informações dessa maneira, e esse método tem certo valor. Mas muitas pessoas que trabalham em um projeto de desenvolvimento precisam ver que mudanças reais ocorreram em um nível maior de abstração. Se os conjuntos de mudanças são associados a itens de trabalho, como descrito anteriormente, uma lista de itens de trabalho concluídos pode ser usada para representar as diferenças entre duas linhas de base. Os detalhes de, por exemplo, 35 defeitos e 12 histórias concluídos durante a última iteração muitas vezes podem comunicar muito mais sobre o que aconteceu do que uma lista de 728 arquivos alterados no mesmo intervalo.
 

Entrega

O termo entrega se refere à transferência de mudanças de arquivos de uma área de trabalho isolado de desenvolvedor para o fluxo atualmente associado à área de trabalho. O resultado de uma operação de entrega é que os novos arquivos ou versões de arquivos serão armazenados dentro do fluxo e ficarão disponíveis para outros desenvolvedores associados ao fluxo. Esses outros desenvolvedores serão informados pelo Rational Team Concert da presença de conteúdo novo e poderão escolher o momento adequado para aceitar as mudanças. Os usuários podem alternar os fluxos para os quais querem entregar o código (conforme descrito mais adiante), e os administradores do projeto podem controlar quem tem permissão para entregar conteúdo para fluxos específicos.
O processo de entrega é semelhante a uma fusão de uma ramificação com outra dentro de outros sistemas de gerenciamento de versão. Uma das principais vantagens do Rational Team Concert é que ele permite que os desenvolvedores entreguem itens de trabalho que incluem conjuntos de mudanças associados aos itens de trabalho. Portanto, embora as comparações de linha de base mencionadas antes possam gerar relatórios em nível de item de trabalho, as operações reais de entrega ao desenvolvedor também podem.
 

Áreas de trabalho do usuário

Cada usuário tem uma área de trabalho do repositório conectada ao fluxo no qual entregarão seus trabalhos. Quando um usuário faz uma mudança em um arquivo, a cópia editada é mantida em um ambiente de simulação do lado do cliente associado à área de trabalho do repositório. Quando o usuário conclui as alterações, o arquivo é registrado e copiado do cliente para uma área baseada em servidor do repositório. O arquivo é coletado em um conjunto de mudanças entre outros arquivos que o usuário também alterou. Quando o conjunto de mudanças está concluído, o usuário o entrega no fluxo.
 

Voltar para parte superior

Fluxos de desenvolvimento paralelos

Mesmo quando os usuários estão trabalhando no mesmo fluxo (como Fluxo de Recurso 1, mostrado na Figura 1), ainda há um grau de separação entre os usuários e uma integração controlada de mudanças à medida que entregam e aceitam mudanças, como mostrado na Figura 3.

Fluxos de recurso

O ponto de partida deste cenário é uma equipe que quer dividir o trabalho que fazem em dois fluxos adicionais para fins de isolamento de suas atividades. Isso é ilustrado na Figura 2.

A Figura 2 mostra o fluxo de desenvolvimento principal para o qual diversos conjuntos de mudanças foram entregues pelos desenvolvedores. Por exemplo, um conjunto de mudanças foi entregue antes do N.° 1 e outro, entre o N.° 1 e o N.° 2 no diagrama. Se não forem criados outros fluxos dentro do projeto, todos os conjuntos de mudanças entregues pela equipe são integrados no fluxo compartilhado único. No entanto, a equipe de desenvolvimento que trabalha nesse projeto decidiu que algumas mudanças precisam ser feitas isoladamente por vários desenvolvedores na equipe. O fluxo de recurso 1 foi criado após um período de trabalho no projeto. Após passar mais algum tempo, foi criado o fluxo de recurso 2.

Parte do trabalho é então feita no fluxo de desenvolvimento principal e parte, nos fluxos de recurso. Para simplificar, apenas um pequeno número de conjuntos de mudanças são mostradas nos diagramas, mas na realidade, muitos conjuntos de mudanças provavelmente serão entregues a cada um dos fluxos à medida que vários desenvolvedores executam seu trabalho. Depois de o trabalho ser feito no fluxo de recurso 1, a equipe decide que ele deve ser integrado ao fluxo de desenvolvimento principal no ponto N.º 2. O processo específico para essa integração do trabalho de um fluxo a outro é descrito mais adiante neste artigo. A partir do ponto de entrega, o fluxo de recurso 2 é criado e o trabalho continua em três fluxos paralelos e separados. Quando são alcançados os pontos N.° 3 e N.° 4, o trabalho realizado em ambos os fluxos de recurso é entregue ao fluxo de desenvolvimento principal e uma linha de base é criada no N.° 5 para uma release. Após as entregas finais dos fluxos de recurso, os fluxos são removidos.

Incluindo um fluxo de integração e release compartilhado

Com base no cenário da seção anterior, como mostrado na Figura 2, um fluxo adicional é incluído ao cenário para fornecer fluxos separados de integração e release. A Figura 3 mostra o novo cenário, que é explicado no texto a seguir.

O cenário de criação de conjunto de mudanças, criação de linha de base e integração do trabalho de um fluxo em outro segue o padrão descrito na seção sobre Fluxos de recurso, com várias pequenas mudanças. O fluxo de integração e release será usado para integrar formalmente e testar o sistema do aplicativo antes de uma release.

1. Uma linha de base é mostrada no N.° 3 do fluxo de desenvolvimento principal, e é entregue para o fluxo de integração no N.° 4.
2. O aplicativo integrado pode então ser testado antes de uma release da linha de base N.° 5 no fluxo de integração e release.
3. Mais trabalho de desenvolvimento ocorre então nos fluxos de recurso até os pontos N.° 6 e N.°7, que depois são entregues para o fluxo de desenvolvimento principal no N.° 8.
4. O fluxo de recurso 2 é então fechado e removido.
5. Ocorre mais trabalho no fluxo de desenvolvimento principal até o ponto N.° 9, onde uma nova linha de base é criada e entregue ao fluxo de integração e release.
6. A nova linha de base é então criada no fluxo de integração e release compartilhado no N.° 10 para gerenciar a release para a produção.

Dividindo o fluxo de integração e release

Ao longo do tempo, as equipes muitas vezes acham útil dividir o fluxo de integração e release em entidades separadas por estas razões:

• A divisão do fluxo de release para longe do desenvolvimento permite à equipe aumentar a segurança desse fluxo, controlando as funções autorizadas a entregar nele. Consulte a seção sobre segurança mais adiante neste artigo (Controlando entregas para os fluxos).
• As modificações necessárias para o código integrar podem ser feitas no fluxo de integração sem comprometer a integridade do fluxo de release separado.
• As mudanças necessárias para suporte a sistema de produção podem ser isoladas do desenvolvimento principal, permitindo assim que tais mudanças (geralmente em arquivos de configuração) para sejam feitas sem impacto no desenvolvimento principal. No entanto, deve haver uma rota para capturar essas mudanças e alimentá-las de volta para o fluxo de desenvolvimento principal. Se o fluxo de release não for isolado, essas mudanças talvez precisem ser feitas juntamente com código parcialmente integrado, que ainda não está completo ou pronto para produção. Isso pode causar complicações na produção ou atrasar a correção emergencial necessária no sistema de produção.

A Figura 4 mostra a apresentação de um fluxo de release e de um fluxo de correção emergencial separado para capturar mudanças no sistema de produção. O processo de captura dessas mudanças de emergência e de alimentá-las de volta para o desenvolvimento é descrito na seção que se segue.

O código do aplicativo na linha de base N.º 5 foi selecionado para ser liberado para produção. Assim, uma nova hierarquia de fluxo de release foi criada para gerenciar a release e qualquer trabalho de correção emergencial, conforme descrito abaixo

1. Uma nova linha de base de release foi criada no N.° 6 e, a partir disso, um fluxo de correção emergencial foi criado (que pode ou não ser usado).
2. No ponto N.° 7, foi executada uma mudança emergencial que é entregue ao fluxo de release no N.° 8. A maioria das organizações tem regras rígidas sobre o tipo e o volume de mudanças que podem ser realizadas com base em uma "correção emergencial". Muitas organizações que permitem correções emergenciais também têm problemas para garantir que tais mudanças fluam de volta para a equipe de desenvolvimento.
3. A entrega do código é feita a partir do fluxo de correção emergencial para o fluxo de desenvolvimento principal, no N.° 11, para garantir que os desenvolvedores tenham essa mudança para incorporar no próximo release formal do aplicativo. A partir do fluxo de desenvolvimento principal, também pode ser necessário entregar o conteúdo de correção emergencial para o fluxo de recurso 1 ou 2 (ou para ambos), mas isso não foi mostrado no diagrama.
4. Enquanto o processo de release estava ocorrendo, o trabalho realizado nos fluxos de recurso foi entregue para o fluxo de desenvolvimento principal no N.° 9 e N.° 10.
5. Mais trabalho ocorre no fluxo de desenvolvimento principal até a linha de base temporária N.° 12, que é então entregue ao fluxo de integração onde é criada uma linha de base de fluxo de integração no N.° 13 pronta para a próxima release.
6. A criação de um fluxo de release e de um fluxo de correção emergencial para gerenciar essa release é mostrada na Figura 5.

Na Figura 5, ocorreu um novo ciclo de criação de fluxo de release, de criação de fluxo de correção emergencial e de trabalho de correção emergencial, envolvendo várias correções. A atividade final mostrada no diagrama é a entrega das correções emergenciais de volta para o fluxo de desenvolvimento principal.

Um novo fluxo de release e correção emergencial é criado para cada release principal, porque pode ser necessário continuar o processo de correção e release no primeiro fluxo de release para fornecer uma segunda linha de base de correção-release após aquela identificada como N.° 7. Quando uma release já não precisa mais ser mantida, os fluxos de release de correção emergencial talvez possam ser excluídos.

O diagrama de relacionamento de fluxo final desta seção mostra como os fluxos podem ir e vir durante o desenvolvimento. A Figura 6 mostra que o processo de desenvolvimento continuou, os fluxos de recurso 1 e 2 foram concluídos, todo o trabalho foi entregue e os fluxos foram excluídos. O fluxo de recurso 3 foi criado para mais atividades de desenvolvimento. A release associada à linha de base N.° 8 também foi concluída e, embora o fluxo de release tenha sido preservado, o fluxo de correção emergencial pode ser removido com segurança.

A ordem de criação e remoção dos fluxos indica o estilo de desenvolvimento das equipes. Como mostra a Figura 7, o projeto começa com um único fluxo para o desenvolvimento e, progressivamente, se torna mais complexo à medida que o projeto progride por meio de iterações. Removendo fluxos que não sejam mais necessários, a estrutura pode ser mantida o mais simples possível. Imagens de tela mais adiante neste documento mostram como o Rational Team Concert pode gerar uma representação pictórica dos fluxos, áreas de trabalho do repositório e seus relacionamentos.

Voltar para parte superior

Criando a estrutura do fluxo

Projeto novo

Quando um projeto é criado no Rational Team Concert ele tem um único fluxo que contém o componente padrão. Componentes adicionais podem ser criados conforme necessário, mas para os fins do presente documento um único componente será utilizado. A Figura 8 mostra o fluxo e a estrutura de repositório do usuário para um novo projeto que tem apenas uma área de trabalho do repositório do desenvolvedor.

É possível visualizar o fluxo e qualquer área de trabalho conectada usando um fluxograma,como mostrado à direita na Figura 8. Os usuários podem ver a natureza hierárquica dos fluxos e das áreas de trabalho do repositório do usuário, e é possível mostrar fluxos conectados a outros fluxos. Deve-se lembrar de que o Rational Team Concert tem uma estrutura inerentemente simples e qualquer área de trabalho pode ser entregue em qualquer fluxo, desde que as permissões baseadas em funções o permitam. (As permissões são abrangidas na última seção deste artigo.)

Para comunicar o fluxo de mudanças necessário, as equipes de projeto devem utilizar a documentação, como os diagramas nas Figuras 2 a 6. Isso ajudará os desenvolvedores individuais a entender para onde suas mudanças devem fluir e quem é responsável pela entrega do trabalho aos fluxos específicos. Essa documentação deve ser atualizada com frequência para que os membros da equipe entendam bem suas responsabilidades à medida que a estrutura dos fluxos evolui.

Mais usuários se juntam ao projeto

Novos usuários que se juntam ao projeto podem obter acesso aos arquivos sob controle de origem, criando outra área de trabalho do repositório. Basta selecionar o item My Repository Workspaces mostrado na Figura 8 e depois selecionar Newe, a seguir, Repository Workspace fará isso. Uma janela de caixa de diálogo de seleção é exibida, como mostrado na Figura 9, de modo que é possível selecionar o fluxo para o qual as mudanças serão entregues ("fluirão"). O número total de fluxos de um projeto costuma ser pequeno, de modo que, se eles receberem nomes razoavelmente descritivos, será fácil selecionar o fluxo certo a usar.

O fluxograma após a criação do segundo fluxo é mostrado na Figura 10. Note que os fluxogramas podem ser criados a partir de um item de menu exibido ao clicar com o botão direito no fluxo ou na área de trabalho do repositório à esquerda da tela, como mostrado na Figura 8.

Voltar para parte superior

Criando fluxos

Há várias maneiras de criar fluxos. Uma das mais fáceis é usar um fluxograma para exibir pictoricamente o relacionamento entre fluxos e as áreas de trabalho do repositório.

Dar um clique com o botão direito do mouse em um fluxo exibe um menu com várias funções e opções:

• Criar uma área de trabalho do repositório
• Criar um fluxo
• Atualizar o diagrama com as informações mantidas no banco de dados do repositório
• Comparar o estado do fluxo com o estado atual de qualquer destes:
  • Outro fluxo
  • Uma área de trabalho específica
  • Uma captura instantânea específica do fluxo

Quando a opção de criar um fluxo é selecionada, solicita-se o fornecimento de um nome para o fluxo e uma área da equipe dentro do projeto para ser proprietária do fluxo. Se não existirem áreas da equipe no projeto, o nome do projeto será exibido.

Na rede inteligente da Figura 2, o primeiro fluxo a ser criado será "Fluxo de recurso 1". Imediatamente após o fluxo ser criado, ele tem o mesmo conteúdo que o fluxo a partir do qual foi criado. Além disso, o novo fluxo não tem relacionamento de fluxo com nenhum outro fluxo, nem áreas de trabalho associadas.

Visualização maior da Figura 11.

A caixa de diálogo de informações para o fluxo permite a execução destas funções:

• Criação de componentes
• Inclusão ou atualização de componentes de referência a partir de outros projetos (em linhas de base específicas)
• Inclusão e remoção de destinos de fluxo

Um novo destino de fluxo é incluído no fluxo de recurso 1 para indicar o fluxo de mudanças para o fluxo de desenvolvimento principal. Isso é mostrado na Figura 12 para a configuração do fluxo.

O fluxograma atualizado é mostrado na Figura 13, que também mostra três desenvolvedores trabalham atualmente no fluxo de desenvolvimento principal.

A inclusão do fluxo de recurso 2 no cenário, como mostrado na Figura 14, completa o cenário indicado pelo diagrama da Figura 2.

Conclusão da criação do fluxo

Para concluir a estrutura de fluxo mostrada na Figura 4, que inclui uma integração realista, estrutura de fluxo de hot-fix de integração, release e produção, são criados fluxos e estabelecidos relacionamentos de destino de fluxo utilizando o mecanismo descrito anteriormente. Os resultados são mostrados na Figura 15.

A esquerda da Figura 15 mostra as atividades de desenvolvimento da equipe, nas quais dois desenvolvedores (Mark e Simon) trabalham no fluxo de desenvolvimento principal e Adrian, no fluxo de recurso 1 (anteriormente configurado para trabalhar no fluxo de desenvolvimento principal, Adrian agora trabalha em recursos específico no fluxo separado). Mark e Simon integram seu trabalho por meio da entrega de conjuntos de mudanças para o fluxo de desenvolvimento principal e aceitando posteriormente os conjuntos de mudanças a partir do fluxo de desenvolvimento principal. O diagrama foi simplificado em termos do número de usuários trabalhando em cada fluxo. Espera-se que Adrian e outros desenvolvedores colaborem no fluxo de recurso 1 e outros desenvolvedores colaborem no fluxo de recurso 2.

À direita do fluxo de desenvolvimento principal está a estrutura de fluxo para apoiar o processo de release e correção emergencial. O fluxo de integração é utilizado para a integração gradual (e controlada) de mudanças de desenvolvimento. Depois de uma linha de base adequada ser criada no fluxo de integração, o estado atual deste (conjuntos de mudanças e linhas de base) é entregue ao fluxo de release 1.0. O fluxo de release específico da versão é criado, como mostrado esquematicamente na Figura 4 e mostrado também no fluxograma da Figura 15. Isso permite que diversos fluxos de release sejam mantidos para suportar o cenário no qual diversas liberações estão em uso em produção ao mesmo tempo. Essas liberações talvez precisem de correções emergenciais aplicadas a elas. No exemplo da Figura 16, a primeira versão a ser criada tem um conjunto de mudanças de emergência aplicados na linha de base N.° 8. É possível que os clientes com essa versão do aplicativo precisem de correções de emergenciais adicionais depois da linha de base N.° 8, mas talvez não estejam em posição de assumir a versão principal mais recente do aplicativo mostrada no segundo fluxo de release. Em resultado disso, é importante manter a capacidade de aplicar correções à release criada na linha de base N.° 6.

O fluxo de correção emergencial, mostrado em "Release Stream 1.0 – E-Fix" na Figura 15, deve ser usado para mudanças emergenciais que devam ser aplicadas a uso em produção assim que possível. Não se espera que essas mudanças envolvam código de origem e recompilação, mas em muitos casos se aplicam a arquivos de configuração e a configurações que precisam de atualização imediata. Elas ainda são capturadas em um fluxo isolado, garantindo que os fluxos de release não sejam utilizados para qualquer atividade de desenvolvimento. As mudanças de correção emergencial também serão provavelmente necessárias para o fluxo de desenvolvimento, de modo que as mudanças fluam naturalmente para a próxima release. A Figura 4 mostra o conjunto de mudanças identificado como N.° 7 sendo entregue para o fluxo de release e o fluxo de desenvolvimento principal no N.° 11.

Voltar para parte superior

Conectando usuários a fluxos

Em um cenário de desenvolvimento paralelo os usuários precisam executar duas tarefas principais como parte dos aspectos de gerenciamento de configuração de suas atividades de desenvolvimento:

• Criar áreas de trabalho que fornecem um grau de isolamento de outros usuários e que estão conectadas a fluxos específicos do trabalho de desenvolvimento paralelo.
• Entregar suas mudanças a fluxos apropriados. Às vezes, durante o desenvolvimento será necessário para o desenvolvedor mudar o destino de fluxo da sua área de trabalho à medida que as atividades mudam durante o processo de desenvolvimento.

A criação de áreas de trabalho foi descrita em uma seção anterior. A conexão da área de trabalho a diferentes fluxos para a entrega de trabalho é descrita na seção a seguir.

Alterando o fluxo de destino para a entrega

No cenário mostrado na Figura 2, um desenvolvedor fez uma mudança no fluxo de recurso 1. Esse conjunto de mudanças pode conter diversos arquivos e, de acordo com o processo de políticas de projeto do Rational Team Concert, terá uma descrição associado ao conjunto de mudanças ou um item de trabalho associado ao conjunto de mudanças. As mudanças no conteúdo do arquivo foram realizadas em um disco rígido local do desenvolvedor em questão, foram registradas na área de trabalho do repositório do lado do servidor e coletadas no conjunto de mudanças, como mostrado na Figura 3. As mudanças são então entregues em um fluxo específico. No cenário mostrado na Figura 15, os usuários Mark e Simon entregam suas mudanças para o fluxo de desenvolvimento principal, mas Adrian entrega as suas para o fluxo de recurso 1. O fluxo de destino para uma operação de entrega é uma característica da área de trabalho do repositório dos desenvolvedores, como mostrado na Figura 17 no caso do usuário Mark.

A seção de informações da área de trabalho do repositório exibe uma série de itens de informações úteis. Relevante para o tópico atual, ela inclui o destino de fluxo para o repositório que indica para qual fluxo as entregas de conjuntos de mudanças serão enviadas. Para mudar o destino de fluxo, selecione Add (na seção de destino de fluxo da tela) e depois selecione o fluxo necessário. Se o usuário Mark quiser entregar conjuntos de mudanças para o fluxo de recurso 2 em vez de para o fluxo de desenvolvimento principal, a seção de destino de fluxo deve exibir o que se vê na Figura 18.

No ponto de inclusão do novo destino de fluxo, realmente não há nenhuma mudança em como os conjuntos de mudanças serão entregues. Para mudar o destino de entrega real, o novo fluxo de destino deve ser definido como o destino atual usando os botões à direita para resultar no estado da área de trabalho, como mostrado na Figura 19.

A posição mostrada na Figura 19 indica que o destino de fluxo padrão para a área de trabalho do repositório específica é o fluxo de desenvolvimento principal, mas no momento o destino de entrega atual é selecionado para ser o fluxo de recurso 2.

Essa posição se reflete no fluxograma mostrado na Figura 20. O destino de fluxo atual é mostrado com uma linha sólida e o destino de fluxo padrão, com uma linha pontilhada.

A visualização Pending Changes também mostra informações úteis sobre os destinos de fluxo. Qualquer destino não padrão é mostrado em itálico na linha superior de informações de Pending Changes, como mostrado na Figura 21.

À medida que começa uma nova entrega, o usuário é avisado de que está entregando a um destino não padrão por meio do aviso mostrado na Figura 22, para que ele possa verificar se a entrega está indo para o lugar certo.

O aviso acima pode ser removido se o usuário tiver mudado completamente para o fluxo para o qual deseja entregar conjuntos de mudanças mudando dos destinos de fluxo atual e padrão para o novo fluxo. Nesse caso, o fluxo de destino não será mais exibido em itálico como mostrado na Figura 21.

Alterando o destino de fluxo a partir da visualização Pending Changes

Também é possível alterar o destino de fluxo de uma área de trabalho do repositório usando a visualização Pending Changes. Clicando com o botão direito do mouse no nome da área de trabalho do repositório e, em seguida, selecionando Change Flow Target é possível selecionar um novo fluxo de destino de fluxo.

Voltar para parte superior

A função do integrador

Como já mencionado, as setas que conectam os fluxos entre si nos fluxogramas das Figuras 13, 14, 15 e 20 estão presentes exclusivamente para indicar que o trabalho fluirá de um fluxo para outro. Há trabalho a ser executado pela pessoa que age como "Integrator" para fazer a transição de mudanças específicas de um fluxo para outro. Isso é descrito na seção a seguir. Como indicado na Figura 4, as mudanças fluem de um fluxo para outro na seguinte ordem (por exemplo):

Fluxo de recurso 1 > Fluxo de desenvolvimento principal > Fluxo de integração > Fluxo de release

Na realidade, os conjuntos de mudanças devem fluir de um fluxo para outro através de uma área de trabalho do repositório. A função de Integrador costuma ser usada para permitir isso. As etapas necessárias para fluir conjuntos de mudanças de um fluxo para outro envolvem as seguintes operações:

1. Configurar o destino de fluxo atual de uma área de trabalho do repositório para o fluxo de origem.
2. Aceitar as mudanças recebidas do fluxo de origem para a área de trabalho do repositório.
3. Mudar o destino de fluxo da área de trabalho do repositório para o fluxo de destino.
4. Entregar as mudanças de saída.

Dicas:
É muito útil executar essas etapas em uma área de trabalho de integração limpa. Caso contrário, a operação de entrega na etapa 4 poderia incluir mudanças feitas localmente pelo desenvolvedor que está executando a operação de integração, em vez de apenas o conjunto de mudanças coletadas no fluxo de origem. Também, assegure de que não haja mudanças de saída listadas na visualização Pending Changes da área de trabalho do repositório antes de executar a operação Accept na etapa 2.

O exemplo a seguir mostra as etapas para fluir as mudanças do fluxo de recurso 1 para o fluxo de desenvolvimento principal via área de trabalho de propriedade do usuário chamado Mark.

Coletar mudanças do fluxo de recurso 1

Configure o destino do fluxo atual da área de trabalho do repositório (área de trabalho de Mark) para o fluxo de recurso 1, como mostrado na Figura 23. A visualização Pending Changes da área de trabalho do repositório mostra então as mudanças recebidas para o trabalho executado no fluxo de recurso 1 pelo usuário Adrian, como mostrado na Figura 24. As mudanças precisam ser aceitas na área de trabalho do repositório pelo Integrador (Mark).

Entregar mudanças ao fluxo de desenvolvimento principal

Configure o destino do fluxo atual da área de trabalho do repositório para o fluxo de desenvolvimento principal, como mostrado na Figura 25. A visualização Pending Changes da área de trabalho do repositório mostra então as mudanças de saída para o trabalho que agora está na área de trabalho do repositório, como mostrado na Figura 26. As mudanças precisam ser entregues a partir da área de trabalho do repositório pelo Integrador, Mark.

Pode-se usar esse processo descrito para coletar mudanças a partir de qualquer fluxo e daí fazer essas mudanças fluir para qualquer outro fluxo. Contudo, um grau de controle é necessário para gerenciar quem tem permissão de entregar mudanças a fluxos específicos (como o fluxo de release). A seção a seguir descreve como controlar o acesso aos fluxos.

Voltar para parte superior

Controlando entregas para os fluxos

Pode-se usar a área de configuração do processo do projeto para especificar que funções de projeto terão permissão de entregar mudanças para fluxos específicos para um componente específico. Pode-se localizar a área de configuração apropriada seguindo estas instruções na interface Eclipse do Rational Team Concert:

1. Selecione a informação Project Area .
2. Selecione a guia Process Configuration .
3. Selecione Team Configuration > Operational Behavior.
4. Selecione Source control (Deliver Server).
5. Selecione o título de coluna Everyone (default) .
6. Marque a caixa "Preconditions and follow up actions are configured for this operation."
7. Selecione Add e escolha a condição prévia chamada "Restrict Change set delivery to components in a particular stream".

A Figura 27 mostra o resultado.

Dica:
Pode-se fazer isso usando a interface da Web, em vez de a interface do Eclipse, se preferir.

Visualização maior da Figura 27.

Fluxo por fluxo, é possível controlar que funções têm permissão para entregar conjuntos de mudanças, como mostrado na Figura 28 (que, na realidade, é a parte inferior da Figura 27, ampliada um pouco para facilitar a leitura).

8. Ao selecionar um fluxo específico, como fluxo de release 1.0, é possível clicar em Edit permissions para controlar que funções têm permissão de entregar no fluxo.

Na Figura 28, a nova função chamada "Release Stream Integrators" foi criada, e apenas membros com acesso a esse fluxo podem entregar para o fluxo de release.

Voltar para parte superior

Resumo

O Rational Team Concert oferece um ambiente altamente colaborativo para a realidade dos projetos atuais de desenvolvimento de software. A maioria das equipes precisa oferecer suporte a diversas linhas de desenvolvimento e compartilhar mudanças com outros que trabalham no projeto. A estrutura do fluxo e os relacionamentos com as áreas de trabalho do usuário não só tornam esses processos possíveis, mas também um modo muito eficiente de segmentar e isolar os esforços de trabalho de modo a maximizar a eficiência da equipe de desenvolvimento de software.

Recursos

Aprender

• Leia o post de blog de Scott Ambler para obter mais detalhes sobre entrega agile disciplinada.
  
  
• Para obter mais informações sobre modelos de processo e estruturas de automação, consulte a página Process awareness and customizability na seção Rational Team Concert Features em Jazz.net.
  
  
• Encontre artigos e links do Rational Team Concert para muitos outros recursos na página do IBM developerWorks. Também é possível assistir o webcast Utilizando o Rational Team Concert em uma equipe distribuída globalmente , ou uma demonstração de Painéis e relatórios, ou ouvir um podcast sobre o IBM Rational Team Concert e Jazz.
  
  
• Visite a área do software Rational no developerWorks para ver recursos técnicos e boas práticas para produtos da Rational Software Delivery Platform.
  • Fique por dentro dos eventos técnicos e webcasts do developerWorks com foco em uma variedade de produtos IBM e tópicos do segmento de mercado de TI.
  • Participe de um briefing ao vivo e gratuito do developerWorks para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
  • Acompanhe Demos on demand do developerWorks, variando de demos de instalação e configuração de produtos para iniciantes a funcionalidades avançadas para desenvolvedores experientes.
  
  
• Melhore suas qualificações. Consulte o catálogo Catálogo de treinamento e certificação do Rational que inclui muitos tipos de cursos em uma ampla variedade de tópicos. É possível realizar alguns deles em qualquer local, a qualquer momento, e muitos dos cursos para iniciantes são gratuitos.
  
  

Obter produtos e tecnologias

• Downloads de avaliação do Rational Team Concert (gratuitos):
  • Enterprise Edition
  • Express Edition
  • Standard Edition
  
  
• Avalie o software IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-o on-line, use-o em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.
  
  

Discutir

• Participe das discussões do Rational Team Concert ou faça perguntas nos fóruns Jazz.net.
  
  
• Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo para o developerWorks. Você terá um público mundial, organização RSS, reconhecimento de autoria e uma biografia, e o benefício da edição e produção profissional no Web site do Rational no developerWorks. Descubra quais são as características de um bom artigo do developerWorks e como realizá-lo.
  
  
• Siga o software Rational no Facebook e no Twitter (@ibmrational), e inclua seus comentários e solicitações.
  
  
• Faça e responda perguntas, e aumente seus conhecimentos participando dos fóruns do Rational, cafésée a wikis.
  
  
• Entre em contato com outras pessoas que compartilham seus interesses fazendo parte da comunidade do developerWorks , e respondendo aos blogs de desenvolvedores.
  
  

Sobre o autor

Mark tem mais de 20 anos de experiência em desenvolvimento e gerenciamento de software em sistemas de TI e ambientes de gerenciamento da configuração. Ele já escreveu software em Fortran, C, assembler, Java e PERL e tem muita experiência na implementação de IBM Rational ClearCase, Rational ClearQuest e Rational Team Concert. Atualmente, Mark é membro da equipe UK Technical Professionals que se concentra em ajudar os clientes a melhorar os aspectos de configuração e gerenciamento de mudanças do seu processo de desenvolvimento.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Orientação sobre termos e conceitos neste artigo
• Fluxos de desenvolvimento paralelos
• Criando a estrutura do fluxo
• Criando fluxos
• Conectando usuários a fluxos
• A função do integrador
• Controlando entregas para os fluxos
• Resumo
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais