Automação de build
Sou a favor de eliminar o trabalho manual e repetitivo sempre que possível.
Estas tarefas tendem a ser tediosas, propensas a erro, demoradas, desestimulantes, etc.
Em especial, neste post quero falar sobre a automação do processo de build de software.
Quando me refiro a build, estou falando do processo de pegar um conjunto de arquivos fonte e transforma-los no produto final, pronto para ser instalado e executado. Isso inclui compilar os fontes, arquivos de ajuda, executar testes automatizados, gerar instalador, etc. Idealmente, este processo deve ser facil de ser iniciado, deve ser automatico, e deve ser reproduzível.
Por exemplo, este processo pode consistir em:
Compilar arquivos fonte
Compilar testes de unidade
Executar testes de unidade
Compilar arquivos de ajuda
Empacotar a aplicação
Subir o servidor de aplicações
Efetuar o deploy da aplicação
Executar testes de aceitação
Submeter para Q.A.
Sendo que a qualquer erro em um destes passos, o restante do processo é abortado.
O build deve ser facil para encorajar as pessoas a utiliza-lo, caso contrario o processo será abandonado e as pessoas voltarão a querer fazer tudo manualmente (o que é demorado, sujeito a erros, etc).
Deve ser automatico para que seja menos propenso a erros e para liberar os desenvolvedores para realizar outras tarefas.
E ser reproduzível significa que para cada build, deve ser possível reproduzi-lo (isto é, produzir um outro produto final equivalente) a qualquer momento. Isto é útil por exemplo caso você precise reproduzir o ambiente de produção de algum cliente para analisar algum bug.
Existem ferramentas dedicadas a isso, desde o clássico Make até ferramentas mais modernas como Maven, Gradle, Ant, etc.
Além de invocar compiladores, a tendencia agora é que tais ferramentas tenham recursos de gerenciamento de dependencias. Isto é, em algum arquivo do projeto você informa que o projeto precisa do Hibernate 3.6.5, e com isso a própria ferramenta de build vai se encarregar de baixar os arquivos necessarios caso eles não estejam presentes na máquina, isso vai garantir que todos os desenvolvedores estejam utilizando as mesmas versões de bibliotecas, ao mesmo tempo que evita ter que armazenar bibliotecas de terceiros no seu repositório de código fonte.
Em resumo, esta é uma das práticas que eu particularmente acho essenciais para qualquer projeto sério de software.
Falou bonito nerd! Parabéns pelo post.
Só um detalhe: Você citou algumas ferramentas (Maven, Gradle, Ant…). Alguma de sua preferência?
Esses scripts de automação eram parte das minhas atividades quando sobrava um tempo entre um projeto e outro. Automatizar tarefas repetitivas é bem divertido!
)
PS: demorou para voltar a blogar, hein!
[]‘s
Há um tempo atras eu era usuário fiel do Maven, até já conversamos a respeito dele. Só que com o tempo eu fui me sentindo muito desconfortavel com o fato de os scripts serem em XML e tambem para qualquer coisa que você quer fazer é necessário um plugin, o que acaba sendo chato às vezes.
Ultimamente tenho usado Gradle, os scritps são escritos em Groovy, que é uma linguagem de programação de verdade e que tem total interoperabilidade com a JVM, então você tem uma flexibilidade enorme para definir o seu processo de build e tudo de uma forma bem concisa e legível.
Dirlei, e que tal inverter este processo: Ao invés de automatizar quando sobrar tempo, automatizar para sobrar tempo depois?
Na verdade, havia automatização no início sim. O que mudava ao longo do tempo era o grau de sofisticação dela. Mas sobrar tempo é secundário, o importante é ser divertido!