Controladores de versão - ClearCase Base vs ClearCase UCM

Independente do processo de desenvolvimento de software adotado (RUP, desenvolvimento ágil, etc..), sua empresa certamente utiliza um software para fazer as gestão dos fontes de projetos. Entre os controladores de versão mais populares estão o CVS e SVN (gratuitos).  Atualmente eles são os softwares mais utilizados nesta categoria - certamente isso é impulsionados por projetos de software livre.
Talvez por este motivo, a maior parte das pessoas pouco sabe sobre outros softwares similares como o Rational ClearCase da IBM. Antes de mais nada, com certeza o objetivo deste post não é fazer propaganda, mas explicar (para quem quer conhecer) um pouco do ClearCase e a diferenças entre seus dois modos de projetos: Base e UCM. Para facilitar o entendimento, em alguns pontos do post, vou tentar fazer um paralelo com ferramentas mais populares - CVS, SVN.

Atualmente no trabalho divido minhas tarefas de Arquitetura de Software Java com suporte a instalação, configuração e utilização de ferramentas IBM Rational. Entre elas o ClearCase. Então vou dedicar uma parte dos meus posts a ferramentas IBM e o que elas podem agregar de valor em projetos.

Olhando do ponto de vista administrativo, o ClearCase possui N features e ferramentas que facilitam o gerenciamento de um projeto. Mas não vamos entrar nestes detalhes neste post. A idéia neste momento é olhar do ponto de vista de um usuário final (um desenvolvedor por exemplo).

Então, mãos a obra: conforme comentei o ClearCase permite criar dois tipos de projetos: Base e UCM.
Um projeto do ClearCase Base possui recursos similares ao SVN e CVS. Para esse “similar” entenda a presença dos conceitos e recursos básicos: check-in, check-out, branch, labels, etc…

Já no ClearCase UCM as coisas são um pouco diferentes. Além das funcionalidades do ClearCase Base, existem novos recursos e conceitos desconhecidos para muitas pessoas por estarem acostumadas somente ao mundo SVN / CVS, que são dois softwares excelentes e eu mesmo utilizo o SVN em meu projeto de Software Livre.

No ClearCase UCM (Unified Change Management) exitem três palavrinhas chave que fazem muita diferença: Stream, Rebase e Delivery. Elas vão nos forçar a trabalhar de uma outra maneira com o código fonte do produto.

Para explicar essas diferenças no momento de utilização da ferramenta vou fazer um paralelo entre dois termos: Branch e Stream.

Um branch a maioria de nós conhecemos. É uma ramificação no controlador de versão do fonte do nosso projeto (main). Essa ramificação é muito utilizada para realizar manutenções evolutivas e correções no software.
Vejamos a figura abaixo:

Como o branch força o trabalho da equipe em área separadas, ele pode evitar que o código parcial de uma manutenção evolutiva (que está sendo implementada a algumas semanas) vá por engano para homologação/ produção junto com a correção de um bug simples aberto e corrigido nas últimas horas.

Mas o branch não evita um problema comum do desenvolvimento de software empresarial (que geralmente não tem a figura de commiters): a quebra do build ou funcionamento interno (em desenvolvimento) do aplicativo. Se uma pessoa fizer algo errado e realizar o check-in, essa pessoa pode impactar o trabalho de outras pessoas, mesmo em projetos com testes unitários. Um software de integração continua não evita esse problema porque geralmente ele realiza o build do que já está no controlador de versão, e mesmo assim ele não consegue validar todos os tipos de problemas (como em XMLs). Então sempre há um jeito de atrapalhar o trabalho de outro desenvolvedor com um check-in equivocado =P

Para evitar isso o ClearCase UCM existe a opção de utilizar o que é chamado de desenvolvimento em paralelo que é um pouco diferente do conceito do CVS / SVN ou mesmo ClearCase Base.
No ClearCase UCM o cenário de qualquer projeto em equipe teria essas características:

• cada desenvolvedor que conectar ao projeto, terá automaticamente um “branch” exclusivo para trabalhar - no UCM esse “branch” é chamado de stream;
• o check-in de um desenvolvedor não causa impacto em outro desenvolvedor porque cada desenvolvedor trabalha na sua stream;
• todo check-in é relacionado uma atividade então é possível relacionar o código com atividades do projeto;
• entre outros…

Estes são apenas algumas características do ClearCase UCM, mas a partir delas já podemos entender como é diferente a maneira de utilizar. Vantagens? Vejamos:
Com streams separadas para os desenvolvedores um desenvolvedor não impacta no trabalho de outro. Após um desenvolvedor realizar vários check-ins de “código parcial” para a mesma atividade. Ao acabar de implentar uma determinada funcionalidade, ele fará um Delivery (entrega) da atividade. Nesse momento todos vão poder ver a implementação deste desenvolvedor através do que é chamado de Stream de Integração.
Mas calma, ainda não é possível baixar para a sua Stream a implementação de outro desenvolvedor. Isso acontece porque ainda sim, mesmo dizendo que terminou a atividade o desenvolvedor pode ter feito algo errado, e isso poderia quebrar o seu build. Então o fluxo da ferramenta agora é a validação da Stream de Integração (seja com ferramentas de integração continua ou testes funcionais) e depois a promoção de atividades liberadas pelo desenvolvedor na stream de integração para uma baseline. A partir desse momento qualquer pessoa pode baixar a última versão do código para sua stream (operação chamada de Rebase), afinal o que está na baseline é o fonte correto.

Alguns desses conceitos como baseline são conceitos de Configuration Management (CM) ou Gerência de Configuração, e é dai que vem o nome UCM do ClearCase - Unified Configuration Management. É uma ferramenta construída e baseada nas melhores práticas de CM. Não é atoa que muitas vezes é citada por consultores de CMMi ou MPS.br.

Para completar, segue alguns conceitos de termos novos (considerando o SVN / CVS) que vimos neste post:

• Stream: em poucas palavras pode ser entendido como um branch integrado a atividades, e geralmente as stream são separadas por desenvolvedores e existe uma de integração - o que não acontece em branchs do SVN, CVS ou ClearCase Base;
• Delivery: é a entrega do código de uma atividade para a stream de integração;
• Rebase: representa a atualização da sua stream de desenvolvimento a partir de uma baseline;

Até a próxima!

Foi lançado hoje um buscador chamado cuil - http://www.cuil.com.
A qualidade da busca, velocidade e ranking das páginas ainda está pior do que o Google, além de estar indexando praticamente só termos em inglês por enquanto. Mas algo que eu queria que existisse a muito tempo no google está presente no cuil: a opção de refinar [...]

Continue Reading...

Eu estava viajando, então estive ausente do PC por alguns dias
De volta agora é hora de colocar o assunto em dia.
Em dois posts anteriores eu falei algo sobre JMS. Um que tratava da integração do Oracle com Java e outro da comunicação do Websphere MQ via JMS. Então para completar o assunto vou mostrar [...]

Continue Reading...

Existem várias formas de realizar comunicação entre aplicações. Entre elas estão: troca de arquivos,  compartilhamento de banco de dados, chamada de métodos remotos (RMI, SOAP) e mensageria.
O MQ (Message Queue) é um padrão para mensageria adotado por várias empresas, entre elas a IBM que possui o produto Websphere MQ (antigamente chamado de MQSeries).
Um dos pontos [...]

Continue Reading...

Atualmente estou atuando em um projeto onde é necessário a integração do Oracle com Java. Ou seja: é necessário executar código Java dentro do Oracle para uma determinada funcionalidade.
Esse projeto faz parte de um treinamento/consultoria sobre Websphere MQ (antigamente chamado de MQSeries) para um cliente, e vai ser o primeiro tema / “puxão de orelha” [...]

Continue Reading...

Não sei exatamente quem costuma ler este site / blog, mas a partir de hoje quero tentar dar novos rumos para ele. Uma sacudida mesmo =)
Até o momento eu estava um pouco ausente e postando somente uma ou outra notícia (lançamentos do spider, palestras, etc…). Nunca postei muitas coisas técnicas…, um pouco por falta de [...]

Continue Reading...

Bom o projeto está indo bem, a cada dia novas melhorias. Está dando muiiito trabalho, mas está ficando bacana.
O curioso é que o país onde as pessoas mais interagem e sugerem as coisas é a Índia =) O pessoal lá parece ser muito ligado na área de desenvolvimento mesmo.
Fora um ou outro bug a versão [...]

Continue Reading...

Parece estranho mas sábado dia 26 vou pegar carona em um evento do pessoal de .Net (Microsoft) e fechá-lo com uma palestra Java sobre o projeto J2EE Spider.
Como o povo do MG-JUG está um pouco parado em relação a palestras, vai ser uma oportunidade de ter algo sobre Java por aqui.
O evento vai ser [...]

Continue Reading...

Ontem lancei a versão 1.0.0-M1 do J2EE Spider.
Temos muitas novidades. Agora já está disponível a criação de projetos com CRUD, o layout do plugin foi revisto, tem funcionalidades novas como mapeamento e muitas outras coisas…
Deu muito trabalho, mas está ficando bacana. Para ver você mesmo assista o vídeo abaixo:
- versão windows (auto-executável)
- versão multiplataforma [...]

Continue Reading...

Em agosto foi publicado no Jornal da Universidade FUMEC (na qual fiz graduação) a seguinte notícia:

fonte: http://www.fumec.br/jornal/?p=306
Além disso fui convidado e estarei realizando uma palestra sobre o projeto amanhã dia 24 a noite e dia 25 de manhã na FUMEC.
E aproveitando o embalo, dia 26 estarei na UFOP apresentando uma palestra sobre o mesmo assunto [...]

Continue Reading...