Processo de Desenvolvimento - Eclipse + Maven + SVN + Hudson

Assuntos Gerais
#1

Oi pessoal,

Estamos definindo aqui um processo de desenvolvimento de software e agora entramos mais no nível desenvolvimento mesmo, codificação e testes. Aqui é setor público então terceiriza-se a maioria do desenvolvimento (infelizmente) de software, ficando pra nós a tarefa de arquitetura, review e definição dos processos (o que também é bacana). Queremos padronizar as ferramentas para que os desenvolvedores não saiam criando e fazendo o que bem entendem, já que temos farto histórico de problemas associados a essa liberdade, que ao meu ver só funciona bem em equipes maduras.

Como IDE, escolhemos o eclipse, maven como ferramenta de build e Tomcat 7 como servlet container (pelo menos a princípio). A idéia inicial é apenas commitar no SVN projetos na estrutura do maven. Segue o que seria o processo:

  1. NOVO PROJETO
    1.1)Gerar archetype do projeto pelo maven (projeto java simples ou projeto web)
    1.2) Limpar classes dummy geradas pelo maven
    1.3) Commit inicial

  2. Desenvolvimento dia-a-dia
    2.1) Programador baixa o projeto no SVN

2.2) Aqui entra o primeiro porém. Para desenvolver e testar com velocidade (principalmente WEB), ter o projeto como ‘projeto eclipse’ ajuda muito, já que ele faz hot deploy no container, dentre todas as facilidades do eclipse - não queria perder isso. A idéia inicial é orientar o desenvovledor a fazer o >mvn eclipse:eclipse e importar o projeto, pra programar usando todos os benefícios da IDE. No SVN, todos os arquivos do eclipse (.classpath, .project e pasta .settings) já estariam no ignore, impossibilitando o programador de jogar no svn os metadados do eclipse. O que me incomoda é fazer o programador dar esse comando, mas não vejo outro jeito - não gostei do M2Eclipse, quando utilizei ele pra importar o projeto ele cospe erros e ainda altera a versão do compilador do projeto, fazendo o eclipse reclamar de problemas nesse sentido.

2.3) programa, testa e commita (bom senso necessário, a princípio apenas commitar funcionalidades fechadas mas sabemos que no dia-a-dia é inevitável acontecerem commits parciais - a regra de ouro é nunca commitar algo sabidamente "quebrado", visto que no svn sempre deve haver uma versão que rode sem problemas)

2.4) Adição de dependências ao projeto - outro problema. Posso usar o M2Eclipse pra adicionar certinho ao pom.xml, mas com o projeto sendo eclipse será preciso rodar NOVAMENTE, a cada dependência adicionada/removida um > mvn eclipse:eclipse pro maven ler o pom e adicionar no classpath do projeto.

Sinceramente, não estou gostando dos passos 2.2 e 2.4. Em suma gostaria de juntar os benefícios do eclipse a um ambiente maven, pois o Hudson será o cara que irá baixar do SVN, buildar via maven e fazer deploy em Homologação e/ou produção.

Gostaria de pedir sugestões, indicações de plugins e/ou ferramentas que pudessem facilitar esses pontos que enxergo como pontos que tornam o processo não suave.

Outra pergunta: indicam alguma boa ferramenta de code review?

Obrigado!

#2

uma boa ferramenta de code review é o sonar: http://www.sonarsource.org/

Ele possui vários recursos bem legais como:
Duplicidade de código
Cobertura de teste
comentário nos códigos
etc.

O melhor é que ele se entrega com o hudson.

#3

Não sei se forçar o IDE (já que estão trabalhando com o Maven) seria uma boa ideia. Principalmente forçando o Eclipse, que (pra mim) possui o pior plugin de integração com o Maven.

Você ganha muito mais padronizando a estrutura do projeto e deixando o desenvolvedor usar o que mais gostar, desde que mantenha a estrutura sobre o Maven. Digo isso por experiência própria. No time de desenvolvimento tínhamos gente usando IntellijIDEA, Eclipse com M2Eclipse, Eclipse com mvn eclipse:eclipse, JBoss Developer Studio e dava até pra usar NetBeans!! Engessar o IDE não é muito legal se você não usa a estrutura de projeto do IDE como padrão.

E, por mais infeliz que possa ser esta tarefa no SVN, utilize branches.

Se eu pudesse sugerir ferramentas, trocaria o Hudson pelo Jenkins (a comunidade inteira já migrou pro Jenkins e o Oracle Hudson está praticamente abandonado), o SVN pelo Git (depois do primeiro merge no Git você nunca mais vai querer usar o SVN na vida) e o Maven pelo Gradle (não sei quanto ao Maven 3, mas o Maven 2 foi o bastante pra me fazer perder o pouco de sanidade que me resta com configurações).

#4

[quote=Ataxexe]Não sei se forçar o IDE (já que estão trabalhando com o Maven) seria uma boa ideia. Principalmente forçando o Eclipse, que (pra mim) possui o pior plugin de integração com o Maven.

Você ganha muito mais padronizando a estrutura do projeto e deixando o desenvolvedor usar o que mais gostar, desde que mantenha a estrutura sobre o Maven. Digo isso por experiência própria. No time de desenvolvimento tínhamos gente usando IntellijIDEA, Eclipse com M2Eclipse, Eclipse com mvn eclipse:eclipse, JBoss Developer Studio e dava até pra usar NetBeans!! Engessar o IDE não é muito legal se você não usa a estrutura de projeto do IDE como padrão.

E, por mais infeliz que possa ser esta tarefa no SVN, utilize branches.

Se eu pudesse sugerir ferramentas, trocaria o Hudson pelo Jenkins (a comunidade inteira já migrou pro Jenkins e o Oracle Hudson está praticamente abandonado), o SVN pelo Git (depois do primeiro merge no Git você nunca mais vai querer usar o SVN na vida) e o Maven pelo Gradle (não sei quanto ao Maven 3, mas o Maven 2 foi o bastante pra me fazer perder o pouco de sanidade que me resta com configurações).[/quote]
òtimas dias.
Realmente prender em uma IDE já que está utilizando maven, não faz muito sentido.
Sobre o maven o 2 estava bem ruim, mas na versão 3 ele ficou praticamente 100% mais rápido.

#5

[quote=otaviojava][quote=Ataxexe]Não sei se forçar o IDE (já que estão trabalhando com o Maven) seria uma boa ideia. Principalmente forçando o Eclipse, que (pra mim) possui o pior plugin de integração com o Maven.

Você ganha muito mais padronizando a estrutura do projeto e deixando o desenvolvedor usar o que mais gostar, desde que mantenha a estrutura sobre o Maven. Digo isso por experiência própria. No time de desenvolvimento tínhamos gente usando IntellijIDEA, Eclipse com M2Eclipse, Eclipse com mvn eclipse:eclipse, JBoss Developer Studio e dava até pra usar NetBeans!! Engessar o IDE não é muito legal se você não usa a estrutura de projeto do IDE como padrão.

E, por mais infeliz que possa ser esta tarefa no SVN, utilize branches.

Se eu pudesse sugerir ferramentas, trocaria o Hudson pelo Jenkins (a comunidade inteira já migrou pro Jenkins e o Oracle Hudson está praticamente abandonado), o SVN pelo Git (depois do primeiro merge no Git você nunca mais vai querer usar o SVN na vida) e o Maven pelo Gradle (não sei quanto ao Maven 3, mas o Maven 2 foi o bastante pra me fazer perder o pouco de sanidade que me resta com configurações).[/quote]
òtimas dias.
Realmente prender em uma IDE já que está utilizando maven, não faz muito sentido.
Sobre o maven o 2 estava bem ruim, mas na versão 3 ele ficou praticamente 100% mais rápido.
[/quote]

Legal! Era um inferno digitar mvn compile e ver a internet sendo baixada pro seu pc :twisted:

Tem um artigo bem legal sobre isso em http://www.iternum.com/knowhow/guidelines/maven-vs-ant/document.pdf

#6

Concordo com a questão de forçar a IDE, realmente não faz muito sentido. O que quero proporcionar ao desenvolvedor é a chance de utilizar todos os recursos da IDE escolhida, porém sem manchar a estrutura do projeto e/ou o SCM.

Pra isso, não tem jeito: o desenvolvedor vai ter que importar o projeto pra realidade da IDE dele, e sempre com cuidado pra não commitar os arquivos de configuração… nada harmful, mas suja o SCM.

A questão toda é que se a gente usa maven, um bom plugin é necessário pelo menos pra gerenciar as dependências do projeto… o problema é o seguinte: voce adiciona a dependencia ao POM.xml, se não houver um plugin que traga aquilo pra realidade da IDE, seu desenvolvimento local vai quebrar. Achei o m2eclipse horrível pra fazer isso, fora que quando você importa o projeto pro eclipse ele perde o track do projeto.

Quanto às sugestões, vou analisá-las todas, mas SCM deve ser o SVN mesmo, isso já tá meio que definido… Jenkins eu já estava pensando em migrar mesmo. E estou usando o maven 3.

#7

Gostei muito desse tópico, Preciso implementar esse conceito aqui na empresa, estava estudando o Hudson. Porém com essas dicas vou redirecionar meus estudos para Jenkins…
mas tenho uma duvidas se alguém de vocês estiver disposto a compartilhar.

Tem-se a fabrica de softwares, (Programadores , Integrado ao SVN), ambiente interno de homologação(Expedição interna), vários clientes (cliente um (projeto-produção, projeto homologação), cliente dois(projeto-produção, projeto homologação)).
Então temos um ambiente muito coplexo, redes internas, atualização externa em clientes em seus ambientes, Todos usuam tomcat, não temos formas alguma de automatização… desses processos… preciso arranjar um formar melhor de gerenciar isso… essas idéias aqui parecem muito show…

Com Jenkins consigo automatizar esses nossos ambientes?
Consigo fazer o deploy .war de uma aplicação de forma remota. em um cliente atualizando seu ambiente de homologação e produção direto do meu SVN, através de uma rotina assincrona para tal evento?
Com relação a licença dei uma lida mas não identifiquei qual é o tipo?

até mais…!

#8

[quote=MarceloNeo]Gostei muito desse tópico, Preciso implementar esse conceito aqui na empresa, estava estudando o Hudson. Porém com essas dicas vou redirecionar meus estudos para Jenkins…
mas tenho uma duvidas se alguém de vocês estiver disposto a compartilhar.

Tem-se a fabrica de softwares, (Programadores , Integrado ao SVN), ambiente interno de homologação(Expedição interna), vários clientes (cliente um (projeto-produção, projeto homologação), cliente dois(projeto-produção, projeto homologação)).
Então temos um ambiente muito coplexo, redes internas, atualização externa em clientes em seus ambientes, Todos usuam tomcat, não temos formas alguma de automatização… desses processos… preciso arranjar um formar melhor de gerenciar isso… essas idéias aqui parecem muito show…

Com Jenkins consigo automatizar esses nossos ambientes?
Consigo fazer o deploy .war de uma aplicação de forma remota. em um cliente atualizando seu ambiente de homologação e produção direto do meu SVN, através de uma rotina assincrona para tal evento?
Com relação a licença dei uma lida mas não identifiquei qual é o tipo?

até mais…![/quote]

Pode, sim! O Jenkis (com os plugins certos) pode fazer deploys em servidores remotos e criar uma tag no SCM indicando o número do build e ainda mandar um email pra equipe de suporte (um exemplo). É muito tranquilo automatizar as coisas com ele.

Sobre a licença, é MIT.

#9

[quote=Ataxexe][quote=MarceloNeo]Gostei muito desse tópico, Preciso implementar esse conceito aqui na empresa, estava estudando o Hudson. Porém com essas dicas vou redirecionar meus estudos para Jenkins…
mas tenho uma duvidas se alguém de vocês estiver disposto a compartilhar.

Tem-se a fabrica de softwares, (Programadores , Integrado ao SVN), ambiente interno de homologação(Expedição interna), vários clientes (cliente um (projeto-produção, projeto homologação), cliente dois(projeto-produção, projeto homologação)).
Então temos um ambiente muito coplexo, redes internas, atualização externa em clientes em seus ambientes, Todos usuam tomcat, não temos formas alguma de automatização… desses processos… preciso arranjar um formar melhor de gerenciar isso… essas idéias aqui parecem muito show…

Com Jenkins consigo automatizar esses nossos ambientes?
Consigo fazer o deploy .war de uma aplicação de forma remota. em um cliente atualizando seu ambiente de homologação e produção direto do meu SVN, através de uma rotina assincrona para tal evento?
Com relação a licença dei uma lida mas não identifiquei qual é o tipo?

até mais…![/quote]

Pode, sim! O Jenkis (com os plugins certos) pode fazer deploys em servidores remotos e criar uma tag no SCM indicando o número do build e ainda mandar um email pra equipe de suporte (um exemplo). É muito tranquilo automatizar as coisas com ele.

Sobre a licença, é MIT.

https://github.com/jenkinsci/jenkins/blob/master/LICENSE.txt[/quote]

Ataxexe, tentei de várias forma mas sem sucesso, você poderia me dar umas dicas mais precisa a respeito do assunto… peguei fonte do projeto quero dar uma estudada, mas estou perdendo a esperaça parece que tudo isso é só promessa, e nada intuitivo de usar…

#10

Pessoal, o ambiente está ficando show de bola, mas surgiu uma dúvida conceitual.

Quem deve fazer o deploy dos artefatos no artifactory?

Quando o jenkins baixa um projeto do SVN e vai buildar com o Maven, ele lê o pom e identifica as dependencia, buscando no repositorio local e depois no artifactory. Daí surgiu minha duvida: o proprio jenkins deve fazer o deploy lá (ja vi que existe plugin) ou o desenvolvedor, quando julgar necessário? Pode ser que nem sempre a cada build seja correto fazer um deploy no artifactory. Julgo que o desenvolvedor deve fazer isso, mas corre-se o risco do esquecimento. O que voces fazem? Sugestões?

#11