Quebra de build devido ao mau uso do Subversion
Saber pilotar o Subversion além do commit e update é importante, mas só isso não basta. A falta de um processo adequado de Gerência de Configuração de Software pode levar a resultados indesejáveis devido ao uso inadequado da ferramenta. Um exemplo disto é o mau uso do repositório como backup, que pode levar à situação conhecida como “quebrar a build”.
Imagine uma equipe com 10 desenvolvedores que usam a política de sempre fazer o commit das alterações feitas durante o dia antes de ir embora da empresa.
Em princípio, parece ser uma boa idéia pois aproveita o backup noturno que é feito automaticamente no servidor, evitando o risco de perder alguma coisa caso haja problema na máquina de um desenvolvedor.
Por outro lado, gera o problema de quebrar a build: um desenvolvedor “A” publica (faz o commit) de algo no repositório que não compila. Quando outra pessoa (desenvolvedor “B”) fizer uma atualização (update), sua cópia de trabalho passa a não compilar mais.
O que já é ruim, pode piorar ainda mais: o desenvolvedor “B” resolve consertar a o sistema para que volte a compilar. Paralelamente, o desenvolvedor “A” faz o mesmo, produzindo uma solução parecida mas diferente. Ao publicarem no repositório, vão acabar gerando conflitos.
Não está ruim o suficiente ainda? Troque o desenvolvedor “B” por desenvolvedor “B”, “C”, “D”, “E” etc. e terá o caos instalado com a equipe inteira parada enquanto o problema é resolvido.
Pra fechar com chave de ouro, só falta dizer que a culpa é do controle de versão! Como se fosse responsabilidade do controle de versão verificar o conteúdo do que é publicado no repositório!
Como evitar que esse tipo de problema aconteça?
Uma solução seria o uso de ramos privativos para cada desenvolvedor trabalhar na sua tarefa, de forma que a integração com o trunk é feita só ao final. Vou tratar deste assunto com mais detalhes em outra oportunidade mas já adianto que resolve este problema mas cria outro, que é a necessidade constante de realização de operações de merge. Basta lembrar que merge é a operação mais complicada do controle de versão (seja ele qual for).
A outra solução é bem mais simples. Basta estabelecer a política de nunca publicar no repositório sem antes compilar e testar. Esta solução ainda pode evoluir para um política mais abrangente, que aceita apenas tarefas completadas, compiladas e verificadas.
Necessidade de Um Processo de Gerência de Configuração
Não há nada no Subversion que verifique se o código a ser publicado no repositório não irá quebrar a build. Afinal, não é responsabilidade do controle de versão isso. Quem define quando e que isto deve ser feito é o processo de Gerência de Configuração ajustado para suas necessidades específicas da equipe de desenvolvimento.
Isso é uma realidade. Aqui no trabalho nós dividimos as tarefas e cada programador fica com uma parte do código, se ele precisa de alguma alteração na parte do outro ele faz uma solicitação para o outro implementar, uma linguagem orientada a objetos ajuda nestes casos visto que vc não precisa saber o que foi feito pelo outro programador, vc somente precisa da função funcionando redondinho.
Dessa forma todos sabem quem fez o que e se uma classe do repositório não compila todos vão em cima do programador que fez a caca e dá um supapo que é pro cara se ligar e corrigir.
Hehe.
Organizar o projeto e os programadores eu acho que é a melhor solução para esse problema.
Minha opinião, não sei a dos outros. Se alguém tiver uma solução melhor posta aí.
Aqui na empresa tentamos minimizar isso com ferramentar de integração contínua como Bamboo (proprietário) e o Apache Continnum. O que ele faz é de tempo em tempo estabelecido em configuração, um update do projeto do svn e tenta gerar um novo build. Quando há algum problema, ele notifica por e-mail falha no build e manda o usuário que comitou o trecho de código que ocasionou o problema.
Edson,
Com controle de versões, não é necessário que tudo seja tão amarrado. É responsabilidade de cada um “mesclar” suas modificações ao fazer o “commit”. O que o artigo diz, é que o programador deve conhecer o paradigma para não atrapalhar os outros. Fazer “commit” só pra fazer backup atrapalha todos os outros.
A solução é: (eu acho)
* Modifica-se o código.
* Testa-se.
* Update.
* Resolução de conflitos.
* Commit.
Os commits devem ser os menores possíveis que não “quebrem o build”. Claro que “quebrar o build” por acidente não é um problema tão grave. O time pode simplesmente voltar para uma versão anterior enquanto alguém arruma o problema. Assim a equipe não precisa parar.
Um efeito colateral indesejado de se fazer “commits de backup” é que os desenvolvedores não irão fazer “updates” com tanta freqüência. Para evitar “updates” vão evitar “commits”. Assim, os problemas serão detectados mais tardiamente. Só haverão “commits de backup”.
Se você tiver “ramos” (branches) no controle de versões é ainda pior. Se, com tantos “commits de backup” já é difícil fazer update no tronco principal, imagine mesclar diferenças entre os “ramos” e o tronco principal? E se der conflito, como você vai decidir qual é o código correto se o “commit” está incompleto?
André Caldas.
Hi, I applaud your blog for informing people.