Pangea – rede social sobre arquitetura de software

Bruno Braga on October 24th, 2008

Agora em outubro meu amigo Adriano Tavares da Squadra aqui de Belo Horizonte, junto com outros amigos da Squadra criaram o Pangea.
Segundo descrição do próprio grupo:

“Pangea é uma rede formada por profissionais e acadêmicos interessados no crescimento e evolução da arquitetura de software”.

http://pangeanet.ning.com

Se você trabalha com desenvolvimento de software, gosta de arquitetura, quer discutir, colaborar e aprender mais sobre o tema, não deixe de se cadastrar. Podemos aprender muito com as experiência e idéias de outras pessoas.

Alguns grupos dos quais participo:

- Monstros da Arquitetura de Software
- Domain-Driven Design
- O lugar certo para você aprender e praticar SOA

A rede hoje tem 93 membros e quanto mais gente participando melhor.

Exibir minha página em Pangea

Uma rede social com esse objetivo é muito melhor do que o orkut, né não? :P
Colabore!

Subscribe to this blog's RSS feed

Rational Team Concert – de olho também no legado

Bruno Braga on October 20th, 2008

O Rational Team Concert (RTC) foi o primeiro produto do projeto Jazz da IBM, que tem o foco em criar um ambiente mais colaborativo para o desenvolvimento de software – “People building great software, together” (slogan do projeto).
A primeira versão do RTC foi liberada dia 30 de junho e as primeiras impressões sobre ele são muito boas e podem ser encontradas facilmente em vários blogs.

Para quem nunca usou o RTC, ele possui fácil instalação (ao contrário de muitos softwares IBM), já trás embutido um controlador de versão e um controle de atividades similar ao JIRA (que é excelente). E além do foco colaborativo ele tem recursos fortes de Web 2.0.

Então o RTC está sendo uma boa resposta da IBM há algumas limitações do ClearCase (CC) / ClearQuest (CQ), que são softwares com mais de 10 anos. Apesar deu ter mostrado o lado bom do CC e CQ aqui no blog (post1, post2), muitas pessoas sabem que configurar e trabalhar com o CQ e principalmente o CC não é algo tão simples =)… é preciso alguém com um bom conhecimento sobre essas ferramentas.

Com o lançamento do RTC criou-se a dúvida: quem tem ClearCase, deve migrar para o RTC? E quanto a quem pretende usar o RTC e possui outros SCMs (Software Configuration Management) como o SVN e CVS?
A resposta sobre realizar a migração é depende.
Se estiver usando o CVS, certamente será necessaria a migração. Em compensação o RTC veio com suporte ao “legado” (se é que podemos falar assim) do SVN e ClearCase e eles ainda podem ser utilizados como o controlador de versão principal.
O único problema hoje é que o conector do RTC para o ClearCase / ClearQuest é apenas um “replicador” de dados. Ou seja: os arquivos criados no ClearCase são replicados para o controlador de versão do RTC. Então na prática os arquivos estão nos dois lugares.

Isso não é algo muito legal, e eu mesmo abri uma solicitação de melhoria em Agosto para o RTC delegar a responsabilidade de controlador de versão para o ClearCase em vez de replicar os dados, seria uma ponte real entre os dois softwares. A solicitação foi aprovada e acredito que será lançada nas próximas versões (existe uma discussão para ver se entra na versão 1.1 do RTC).

Mas qual a vantagem desse “bridge” ou conector entre o RTC e o CC, se o RTC já tem um controlador de versão?
Pelo que pude perceber da equipe dos projetos é que o ClearCase, ClearQuest e outros softwares da Rational vão receber influencias do Jazz e estarão cada vez mais alinhados com esse projeto. Então o controlador de versão do RTC continuará sendo distribuído como uma solução de fácil instalação e com recursos para a maior parte das equipes de desenvolvimento, e a integração com o ClearCase será uma opção mais robusta e com recursos não disponíveis no RTC como multisite e outros. Então o plano de migrar do ClearCase para o RTC hoje pode parecer fazer algum sentido por causa das limitações do conector disponível no RTC 1.0 (um replicador) e por aparentemente os softwares serem concorrentes, mas para o futuro talvez não seja a escolha correta dependendo do tamanho da equipe e dos recursos necessários. Manter o investimento no ClearCase e utilizar o conector ou bridge é a melhor no momento. A maior complexidade é justificável.

Em relação ao SVN depende da estratégia de cada equipe. O SVN é free. Não haveria perda de nenhum investimento ao migrar para o controlador de versão do RTC. O que pode ser feito é utilizar os dois juntos por um período de avaliação e depois realizar a migração dos dados para o RTC se for o caso, já que dificilmente o SVN terá mais features do que o controlador de versão do RTC e quanto mais softwares para “a mesma coisa”, maior a complexidade.

Nos próximos posts eu vou comentar algo sobre o Rational Quality Manager e Rational Requirements Composer que estão sendo desenvolvidos utilizando o Jazz.

Algumas imagens do RTC:

Rational Team Concert Rational Team Concert

Antes de mais nada, as pessoas costumam confundir os nomes ClearCase e ClearQuest (ferramentas IBM Rational), afinal são nomes bem parecidos. Mas apesar destas ferramentas trabalharem de forma integrada (opcional), uma tem o papel totalmente diferente da outra.

Meu post anterior foi sobre o ClearCase (CC): Controladores de versão – ClearCase Base vs ClearCase UCM.

E aqui vamos introduzir o ClearQuest (CQ) e comentar o objetivo de integrar essas duas ferramentas.

Primeiramente para resolvermos o problema dos nomes parecidos, vamos imaginar que a sigla do ClearCase – CC é um C de Código – ela armazena código / arquivos, já que é um controlador de versão. E para o ClearQUEST, podemos dar atenção ao Quest que é “busca / investigação” – essa ferramenta entre outras coisas pode gerenciar bugs e um dos processos para resolver bugs é investigar, correto?

O ClearQuest é uma ferramenta que possui muita flexibilidade para automatizar workflows e seu maior uso é no controle de mudanças de software. Nele podemos cadastrar e acompanhar bugs, atividades, e controlar qualquer outro tipo de trabalho a ser realizado pela equipe.

Mas o que isso tem a ver com o ClearCase? Bom, já vimos anteriormente que o ClearCase UCM solicita uma atividade em cada check-in. Isso cria uma ligação do código do check-in com a atividade que o desenvolvedor está trabalhando.
A desvantagem nesta afirmação é que o controle de atividades do ClearCase é muito simples, já que esse não é o foco da ferramenta. No ClearCase uma atividade é composta apenas pelo título, não tem descrição, status do andamento, relatórios ou nada poderoso para gerenciamento. Bom, ai é que entra o ClearQuest: ele tem todos esses controles e mais um pouco. E caso sua equipe não esteja satisfeita, ela pode customizar os formulários, acrescentar campos, mudar status, alterar ações, estados e o workflow da solicitação. Isso faz do ClearQuest uma ferramenta excelente ferramenta mesmo sendo utilizada sem a integração com o ClearCase, e é uma das minhas preferidas do portfolio IBM.

Mas voltando ao assunto principal do tópico, associando uma atividade do ClearQuest em cada checkin de arquivos (resultado da integração das ferramentas) é possível ter um controle maior do projeto e do que e foi desenvolvido.
Exemplo:

  • é possível manter a rastreabilidade de atividades do projeto para código, ou até ir mais além: usar a customização para criar um cadastro de caso de uso no CQ, relacionar o caso de uso com uma atividade do CQ e podemos extrair como informação todos os arquivos que foram alterados ou criados ao implementar determinado caso de uso. Esse é um dado importante para analise de impacto;
  • algumas vezes não queremos buscar a última versão do código do controlador de versão porque ele contém partes de aplicativos que estão pela metade. Precisamos fazer um pacote com o produto, mas no ponto que queremos não existe nenhum label (marco importante). Então com essa integração uma opção é contruir esse pacote baseado nas atividades que queremos que esteja no pacote (ex: Implementação Caso de Uso 1, Implementação Caso de Uso 2, etc..).
  • o GP tem maior controle de cada atividade do projeto. Sabe quais já foram iniciadas, em que o desenvolvedor está realmente trabalhando (são as atividades “alteradas” por último com os arquivos), e pode até fazer um script de métrica que calcule quantas linhas de código foram alteradas em cada atividade, para “sugerir” um esforço / custo por atividade.
  • etc…

Então ligando o nosso produto de trabalho (documentos, diagramas, códigos) as atividades que realizamos no dia a dia, ganhamos um leque a mais de opções e dados que podem ser utilizados para melhorar o gerenciamento e qualidade do projeto.
Partes desses controles também são importantes em certificações com o CMMi.