terça-feira, 24 de março de 2009

Build de aplicações Java (Parte 1)

Esta semana estarei compartilhando em meu blog, um trabalho que tenho realizado com relação a construção (build) de aplicações Java. Serão vários posts, seguindo uma ordem que penso ser cronológica em termos de ferramentas que podem utilizadas para a realização de builds. Irei demonstrar a construção de aplicações que utilizam dependências (bibliotecas java) partindo de um exemplo simples até a construção de aplicações mais complexas envolvendo o uso do Spring Framework e do JBoss Seam.

Para começar, a aplicação que será construída é muito simples e com poucas dependências. Ela é uma aplicação didática, que apresento em seminários e treinamentos aonde falo sobre Test Driven Development (TDD) e sobre práticas de Extreme Programming (XP). Para saber mais sobre TDD, leia este artigo que escrevi.

Builds podem ser realizados com várias ferramentas. Meu intuito nos próximos posts é explicar exemplos de uso e os diversos prós e contras na adoção de uma ou de outra. Começarei falando sobre um assunto pouco explorado, talvez pela sua "complexidade" que é o build de aplicações utilizando simplesmente scripts como, por exemplo, os escritos em Bash. Em seguida, falarei sobre o uso e a criação de scripts para o Make, Ant, Maven, Ivy (+ Ant), Groovy (+ Ivy), Gant (+ Ivy) e por fim, Gradle.

Esta será uma semana repleta de conhecimento acerca de builds e eu espero que, ao final dela, você tenha embasamento para passar pelo mesmo problema que estou vivenciando neste momento, que é a escolha da melhor alternativa para a migração do processo de construção de diversas aplicações Java (com vários scripts de build já desenvolvidos no Ant), só que, cada uma escrita a sua própria maneira, o que dificulta a manutenção e a evolução num ambiente corportativo.

Neste ambiente, os desenvolvedores são conservadores e procuram trabalhar geralmente adotando as ferramentas, APIs e frameworks padrão de mercado e/ou já consolidadas. Eles pensam na estabilidade e na confiabilidade de suas aplicações. Imagine que eles estão muito mais preocupados com a lógica de seu negócio e, para eles, o processo de build de uma aplicação envolvendo a obtenção dos fontes a partir de um repositório, a compilação, o empacotamento, a distribuição para as máquinas de diversos ambientes (local, desenvolvimento, homologação, produção) e a implantação dos pacotes nos servidores de aplicações destes ambientes seja um assunto que deveria ser resolvido por uma ferramenta que integrasse tais processos. Imagine também que estes desenvolvedores gostariam de ter um ambiente de desenvolvimento capacitado a gerar um build de maneira automática (se possível) e que houvesse também uma gerência de dependências e de releases da aplicação, também de forma automática. Imagine que você está responsável por implantar um processo para uma equipe como esta. O que você faria?

Parece-me que este ainda é um problema comum e freqüente em várias empresas, mesmo em algumas presentes no mercado com características mais dinâmicas em termos de agilidade na produção de software e que utilizam uma grande variação de ferramentas, linguagens e frameworks para a solução de seus problemas.

Nos próximos posts eu estarei repassando o meu ponto de vista para a solução do problema que estou apresentando, num ambiente com tais características. Será um post por dia, durante esta semana e ao final desta, apresentarei minhas conclusões. Agradeço o teu acompanhamento e feedback.

Um comentário:

  1. Adivinha quem esta acompanhando ;-)

    Otimo post PJ, um grande abraço.

    ResponderExcluir