Integração Contínua com Hudson - Track #1 - "Since I've been Integrating you.." 1
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
Conheci o Sr. Hudson no início do ano passado com o pessoal
da Zilics.
Por motivos óbvios me amarrei logo de cara. Ele
tem pelo menos duas das qualidades mais “nobres” que uma ferramenta de
“apoio ao desenvolvimento de softwares” deve ter: é simples
e útil!
Segundo um tal de Martin
Fowler :
Faz Sentido. Integrar
sempre não diminui a quantidade de
bugs que irão aparecer. Além disso,
não reduz o tempo/esforço de refactorings e
não melhora a qualidade do código do seu
software. Entretanto, reduz drasticamente os riscos inerentes
à esses fatores ao mostrar, na hora e “na lata”, quais bugs
apareceram (onde, como e quando. Geralmente o “quando” é
agora!), o que quebrou ou vai quebrar com o seu refactoring, quais
trechos de códigos tornaram a sua build instável
e assim por diante.
Mas ainda estou falando da prática. E não da
ferramenta. Quero dizer que, infelizmente, o Hudson não faz
mágica. Antes de colocar uma ferramenta de
integração contínua para funcionar no
projeto, sua equipe já pode e deve estar integrando continuamente.
Este vídeo roubado na cara de pau do blog do Chapiewski
é uma história verídica sobre como uma
Grande Figurão se deu mal por não “Integrar
Contínuamente”:
Único repositório de fontes?
Independente de SVN, GIT, CVS, ClearCase, SourceSafe, StarTeam ou seja
lá qual SCM seja, TUDO (menos dependências, VIVA O
MAVEN !) deveria estar no repositório. A idéia
é que qualquer um a qualquer momento, inclusive o Hudson,
possa montar um ambiente de desenvolvimento ou gerar um
“instalável” a partir do repositório. Claro que
existem exceções, mas nada que o nebuloso “bom
senso” não resolva.
Build Automatizado, testes executados no processo de build?
Mais uma vez viva o Maven! Se não for o caso, pelo menos um
Ant, .sh, .bat, ou qualquer outra coisa que resolva o problema.
Até pouco tempo eu via muita gente rodando testes dentro do
main de uma classe e fazendo control+C e control+V de arquivos, zipando
pasta e renomeando pra .war. Assim não dá, assim
não pode…
Todo mundo comita todo dia?
Se não comitou é porque ficou o dia todo no
Orkut, ou porque “não quer comitar algo que possa quebrar a
build antes de avaliar direito e blá blá
blá…”. Mas ora bolas, a idéia é
justamente essa! Se chegar a comitar e quebrar, pelo menos todos
verão ao mesmo tempo o porquê de tudo isso. Ficar
uma semana para comitar um componente de 300 classes para depois ficar
mais três semanas fazendo merge e tentando descobrir o que
quebrou, na minha opinião, é algo um pouco pior.
Além disso, é capaz de lascar com a vida do seu
parceiro que estava comitando todo dia, código que usava
aquele componente antigo. Todos os testes passavam lindamente e de
repente: WTF!?
Comitou, gerou build?
Este está diretamente relacionado ao tópico
anterior. A idéia é gerar uma build
estável executando todos os testes logo após o
commit. Eu acredito que o ideal seja trabalhar rodando os testes que
cobrem o que você está fazendo. Rodar TODOS os
testes a cada mudança individual pode ser um processo lento
e chato. Mas, isso deve ser feito pelo menos a cada commit. Dessa forma
você garante que a build que estava estável
continue estável. Automatizar esse processo é o
ideal, mas isso é um trabalho para o Hudson!
O processo de build é rápido o suficiente, testes
em ambiente de produção?
Alguns projetos (como o que vou citar mais a frente, para exemplificar
o uso do Hudson) podem ser um pouco mais xaropes de serem instalados em
ambiente de produção. Bancos com massas de dados
muito complexas, webservices não disponíveis
através de servidores de testes e dependências com
hardware, em geral, dificultam a execução dos
testes em ambientes ao menos similares aos da
produção. Mesmo quando possível, a
reprodução do ambiente de
produção pode tornar a
geração da build consideravelmente mais lenta.
Uma prática (boa ou não) é manter uma
suíte de testes com mocks
para estas interfaces mais
“complexas”. Esta suíte de testes é executada
frequentemente pelos desenvolvedores e pela ferramenta de
integração em cada commit. Uma outra
suíte que reproduza o ambiente de
produção também pode ser executada em
nightly builds, por exemplo. Mas ambas são executadas
sempre, a partir da última versão do MESMO
repositório.
Tá fácil de pegar a última
versão estável?
As pessoas, em geral, tendem a achar pequenos erros ou
correções em uma funcionalidade já
testada e usada com muito mais facilidade, do que assimilar novas
funcionalidades agregadas. Uma boa dica é tirar proveito
disso tanto nas apresentações como no dia a dia.
Fica bem mais fácil quando se sabe exatamente como e onde
buscar versões da aplicação. Seja para
testar e apresentar correções e
evoluções ou simplesmente para ver o que rolou ao
longo da última semana. Todos deveriam ter “direito”
à isso, principalmente quem está bancando o
projeto.
Todo mundo vê o que está acontecendo?
09:52: Martin Fowler - I Love Continuous Integration says:
Integração
Contínua tem tudo a ver com
comunicação, de modo que você quer
garantir que todos podem ver o estado do sistema e as
mudanças que foram feitas a ele. :)
As pessoas envolvidas no projeto só vão “tomar
ações” quando souberem que existe uma
ação à ser tomada. Nada melhor do que
uma luz vermelha gigante, piscando ao lado do número e data
da última build que quebrou. Até mesmo
saber se existe uma build em andamento e quais testes estão
quebrados ou foram consertados. Tudo de fácil acesso.
No próximo post vamos trocar umas idéias sobre
como o Hudson pode ajudar em todas estas tarefas citadas acima!
To be continued…