Que nada!
Você pode montar o seu rapidinho!!!
Só vai demorar um pouco pra baixar as ferramentas.
Nesse post vou passar a lista das ferramentas que você vai precisar baixar e nos posts seguinte mostro como instalar e configurar cada uma delas.
Quando estiver instalado e configurado vamos aos exemplos práticos.
A justificativa de montar um servidor de integração contínua é produtividade!
Toda mudança vem dos casos de insucesso e o building continuum não fica atrás. O fato é que ninguém se dá ao trabalho de baixar, instalar, configurar e manter um building continuum funcionando se não há problemas que justifique esse esforço. Building continuum não é um caminhão sem rodas, mas o simples fato de entender como funciona essas ferramentas já é um esforço. Esforço que está muito além do que a maioria dos analistas de teste estão dispostos a entender.
Leve em consideração que building continuum é a automatização da automatização. O building continuum é uma máquina dedicada para testes automáticos que roda a suíte de teste periodicamente. Logo, se você não tem testes automatizados ou não está pensando em ter então um building continuum não te agregará em muita coisa. Entende-se por testes automatizados: unitário, funcional e desempenho, que podem ser executados em um building continuum.
Saindo do blablabla, imagine que você possua uma suíte de testes automatizados e toda vez que haja uma necessidade você os execute. Se a metodologia em que você trabalha (RUP) as entregas acontecem em mais de um mês, dificilmente você terá problemas, mas se sua entrega acontece com intervalo de tempo menor como no Scrum (2-4 semanas) ou XP - Extreme programming (1 semana) certamente você terá problemas!
A primeira hipótese são as suas férias:
- Você precisa sair de férias e não tem quem roda os testes. Neste caso building continuum é indicado, pois você configura para rodar periodicamente. Você só lembra que ele existe quando os testes falham e o Hudson envia e-mails para os interessados com o erro. Ele passar a funcionar independente de quem o construiu. É uma beleza!!!
A segunda hipótese é a refatoração ou alteração de código:
- No Manifesto Ágil isso acontece constantemente devido ao conceito de "débito técnico" que são os "Go Horse" colocados durante o sprint, mas que em algum momento devem ser corrigidos, prática comum quando trabalhamos orientados a resultados. É comum refatorar, pois uma aplicação com muitos débitos técnicos pode ir a falência, termo usado quando o custo de correção da aplicação é superior a nova implementação da mesma. Se o código altera bastante então testamos bastante e um building continuum é fortemente indicado.
Com os exemplos práticos veremos mais justificativas...
Para começar, faça o download das ferramentas abaixo:
Hudson
http://migre.me/8ljfx
Subversion (Server)
32-bit O
http://migre.me/8ljpY
64-bit OS
http://migre.me/8ljsY
TortoiseSVN (Client)
32-bit OS http://migre.me/8ljdV
64-bit OS
http://migre.me/8ljhM
Maven
http://migre.me/8ljBn
Apache Tomcat
http://migre.me/8ljUj
Java SE 6
http://migre.me/8rorqEclipse Indigo
http://migre.me/8llde
64-bit OS
http://migre.me/8llel
Vamos instalar e configurar cada uma destas ferramentas.
No próximo post vamos instalar e configurar o Java Standard Editio.
Começaremos pelo JavaSE 6 (Eu acho o Java SE 7 instável.
Esta ferramenta será fundamental para rodar quase todas as demais ferramentas acima.
O post se chama "Instalação e Configuração do Java SE (Standard Edition)".
.
