Eu já trabalhei em projetos com vários tipos de sistemas de build. Uns usam um build completamente automático, uns usam um build interativo (um jeito carinhoso para se referi à porcaria do build em que você tem que apertar ‘enter’ constantemente). Uns demoram 1 minuto ou menos, outros 59 minutos. E alguns nem sistema de build criam! Acham que usar a função ‘Export as JAR’ da IDE é algo aceitável (dica: não é).
A maioria dos projetos tinha ma coisa em comum: não levavam o build a sério. O build de uma hora que mencionei começou com segundos e passou para minutos em algum tempo. Lembro numa reunião onde um grupo de desenvolvedores levantou a questão de que estávamos chegando em 30 minutos, todos na empresa ficaram preocupados. Aí a coisa esfriou e ninguém fez nada, nem ninguém reparou quando esse build chegou em uma hora.
A primeira medida aplicável é tratar o build como parte do seu software, como seu código. Praticamente todos os grandes projetos que participei tinham builds desnecessariamente complexos. Já vi casos onde arquivos build.xml eram gerados on-the-fly através de transformações XSTL, já vi empresas com frameworks de build, onde seu build.xml tem que importar um build.xml criado pela sempre infame ‘equipe de arquitetura’, já vi builds que usam Mavem como se fosse ant e até mesmo um build.xml que usava AWK para fazer a maioria das coisas. Tudo isso é mau sinal.
Seu build deve ser simples. Rake, ant, maven, make não importa: simples. Arquitete-o como faria com sua aplicação: divida em módulos e crie um arquivo de build para cada módulo. Idealmente deve ser possível fazer o build de um módulo em isolamento. No topo, crie um arquivo que faz o build de toda a sua aplicação apenas chamando os builds de cada módulo. Pense na interface dos seus builds, nos parâmetros de entrada e de saída. Encapsule seus módulos.
Testes unitários devem ser executados imediatamente após a compilação (se existente). Se o build falhar porque o teste unitário não passou é melhor que isso seja rápido e não após gerar o pacote de instalação. Testes de integração rodam após esse e os de aceitação na sequência.
Cuidado com testes de aceitação e integração. Pense no que você está testando, já vi casos onde a maioria dos testes de aceitação apenas repetia o que os testes de integração já faziam. Não esqueça que o papel dos testes de desenvolvedor não é substituir a homologação, você como desenvolvedor testa em caixa-branca e sabe quando um teste substitui o outro
Mantenha os artefatos gerados em diretórios temporários até que sejam copiados para seu destino final. Não misture artefatos temporários (arquivos .class soltos, por exemplo) com artefatos versionados (código-fonte). Use os .cvsignore da vida com sabedoria.
Pense sempre no desenvolvedor novato. Quanto tempo o novato precisa para ter um build funcionando na máquina dele? Se a resposta for mais que uma hora você precisa refatorar o build. Convencer os analistas de negócio e clientes que o build deve ser refatorado é duro. Provavelmente é a parte do código onde eles menos vêm valor. Antes de usar a força (ou a clandestinidade) para fazer suas mudanças tente ter uma conversa séria, tente msotrar o valor preto-no-branco.
O build de 60 minutos citado era um problema real. Enquanto o CruiseControl executava o bichinho o desenvolvedor tinha que ficar de braços cruzados porque poderia haver um problema n o commit dele e ia ser bem ruim identiicar o que houve se ele continuasse alterando o fonte. Também, após 60 minutos já haviam vários outros commits na fila, o próximo build levaria mudanças de muitas pessoas diferentes. O assunto era levantado requentemente para o ciente, que ignorava.
A solução que nosso time deu foi interessante. Começamos a escrever em um mural tempo que perdíamos com o build. Em algumas semanas descobrimos que pelo menos 8 horas de deenvolvimento por dia eram perdidas no processo. Fizemos uma estimativa de quanto de código poderia ser entregue usando essas horas desperdiçadas e fomos conversar novamente com o cliente. A postura foi outra, vendo os números as pessoas começam a dar valor. Conseguimos 8 horas por semana para trabalhar no build, o que ez com que ele reduzisse para 30 minutos. Não é o ideal, pelo contrario, mas 30 minutos a menos já foi suficiente para entregarmos mais valor e, principalmente, levantar a moral das pessoas.
Tá ai um assunto que nunca gastei a seriedade que o mesmo requer… ótimo post.
Olá Phillip, mais um excelente texto. Parabéns!
Concordo com você no sentido de que para garantir um processo mais eficiente num ambiente de integração contínua é necessário fazer um planejamento do software separando-o em partes menores. Essa etapa inicial de planejamento nos garante não apenas um build mais rápido como também maior coesão e controle dos artefatos gerados para os componentes do software.
Alguns servidores de integração já incorporam esta etapa de modelagem dos componentes como parte do processo de definição da infra-estrutura de desenvolvimento. Ex.: Component Model do Netweaver Development Infrastructure.
Segue link para um post em meu blog com algumas dicas e outros links para estudo do NWDI:
http://laercioqueiroz.wordpress.com/2008/01/11/continuous-integration-environment-com-o-sap-nwdi/
Abraço.
Oi, Laércio,
Posso estar errado mas ao que me parece o que a plataforma da SAP traz já é uma arquitetura, não? Se for fica difícil avaliar as qualidades desta contra uma arquitetura ad-hoc.
[]s
Oi Phillip, porque você acha difícil avaliar as características do NWDI atuando como um “servidor de integração”?
Você levantou uma questão interessante, a simplicidade. Aquele mesmo mal que faz o pessoal se entupirem de frameworks antes de iniciar um projeto, acontece com o build.
As “arquitetura de referencia” nos órgãos públicos que o digam… :)
Eu sempre usava um script simples do ant, feito com segurança, mas o pessoal queria porque queria meter um maven ou outra ferramenta só porque achavma que um ant não era o suficiente, quando eu questionava ninguem respondia, mas achava que não era.
Realmente essa parte de Build é complicado. Na empresa que trabalho já aconteceu de um build levar 95 minutos. Algo impensável, e um colega de trabalho conseguiu levar 96 minutos de build. Seria ótimo se esse tempo fosse reduzido, mas tanto o patrão quanto o cliente não ligam para isso(Infelizmente). Então essa máteria é muito boa e informa as pessoas que desconhecem desse problema diário.