Como gerenciar configurações de mais de 17 projetos e estabelecer reuso

Programação Arquitetura
#1

Olá todos. Gostaria de saber quais métodos de automatização de projeto vocês vem usando e que vem dando certo.

Hoje, tenho uma relação de 17 projetos para reconfigurá-los. O pessoal incrementou algumas políticas de uso no cvs, então para cada sistema terei que criar uma [branch] e efetuar as modificações e reintegrá-lo novamente no [head] do cvs.

Bem, fiz alguns tasks básicos no ant para alguns projetos e que funcionou bem, tais como: [criaWar] - [deployServidorTestes] - [DeployServidorProducao] - entre outros que ajudam pacas. Eu criei um arquivo .properties para parametrizar os nomes de servidores entre outras strings de configuração de banco e outros. Estou também a realizar outros como efetuar o checkout de uma tag e efetuar o deploy em um servidor, entre outros para setar configurações internas e usos do junit.

Gostaria de sugestões nos seguintes pontos enumerados abaixo:

[quote]1. Tenho o seguinte problema. Quando baixo um sistema no cvs, a taks via ant que implementei está funcionando perfeitamente. Sendo que o pessoal tem uma mania de ficar modificando o mapeamento dos servidores. Aí eu me quebro e toda vez terei que modificar o arquivo .properties, inclusive no cvs. E o pior é que quem pegar nos outros projetos também. Alguém tem um problema parecido?

  1. Outro problema também, é que todo mundo tem uma referência diferente do jdk e do tomcat no build path quando baixa o projeto. Por exemplo, toda vez que alguns caras baixam no eclipse, aparece uma referência [unbound] do jdk aí o cara tem que ir lá e modificar. Estive pensando em uma forma de o pessoal baixar do cvs e que não fosse necessário nada a mais do que clicar no start do tomcat e rodar o sistema.[/quote]Caso vocês tenham algum link sobre configurações de projeto e extensões via padrões e reusos agradeço. Mas para adiantar, não temos uma gerência de configuração na equipe, estou me propondo a realizar estas atividades para resolver estes e outros conflitos.
#2

Simples. Arquivos que representam configurações locais não são atualizados no CVS. Talvez apenas uma versão inicial, mas depois sua atualização pode ser ignorada.

Simples também. Estabeleça um padrão e configure a JDK de todas as máquinas da mesma forma. Em 5 min cada desenvolvedor faz isso e resolve o problema. Daí dá pra incluir o .project do projeto no CVS também :slight_smile:

#3

Estive pensando nisto Ivan, mas a bronca é que são mais de 20 pessoas. Estou vendo que terei que fazer um mutirão para conseguir realizar esta atividade.

Estive tentando achar alguma material ou alguma postagem em blogs quanto às boas práticas de gerência de configuração em projetos com java.

Venho tentando automatizar os processos de build e deploy por aqui, através do ant, e se conseguir utilizando o maven também.

#4

Outra coisa que tinha me esquecido de mencionar Ivan, é sobre TDD. E vi que em seu blog existem vários post muito interessantes sobre o assunto.

Eu estou pensando a algum tempo em extender isto com a equipe de desenvolvimento. Acho que de certa forma faltou até coragem para convencer ao pessoal de que é melhor escrever o código de testes antes e o código final vem depois. O pessoal tem me criticado sobre o assunto.

Há alguns meses comprei este livro, mas só li os primeiros capítulos. Mas assim que puder pretendo melhorar meus conhecimentos quanto a automatização de frameworks e TDD, entre outros, e outras metodologias ágeis.

Gostaria de saber as consequências e o que beneficiou em projetos que você teve que estabelecer os adeptos do TDD.

#5

Um jeito fácil de implementar isto é ter um target “init” da vida que leia configurações no home do usuário. Aí definições locais ficam fora da árvore do projeto e podem ser compartilhadas. No maven isto já ocorre de forma automática. Não lembro agora se o ant tb. o faz.

#6

Não crie tasks mágicas no ant que dependam de ambientes. O buildfile deve criar apenas o build da aplicação, você pdoe até usar ant para fazer deploy mas deixe isso a cargo de outro arquivo.

O buildfile deve gerar um arquivo war ou ear ou algo do tipo que é passível de deploy em qualquer isntência de servidor, os outros scripts (ant, perl, bash, rake, sei lá) baixam o cvs, chamam o build e copiam o resultado para o servidor A ou B.

#7

[quote=faelcavalcanti]Bem, fiz alguns tasks básicos no ant para alguns projetos e que funcionou bem, tais como: [criaWar] - [deployServidorTestes] - [DeployServidorProducao] - entre outros que ajudam pacas.
[/quote]

Você tem certeza absoluta de que você quer permitir que um desenvolvedor faça, acidentalmente, um deploy de uma versão não testada no seu servidor de produção?

#8

[quote=Daniel Quirino Oliveira][quote=faelcavalcanti]Bem, fiz alguns tasks básicos no ant para alguns projetos e que funcionou bem, tais como: [criaWar] - [deployServidorTestes] - [DeployServidorProducao] - entre outros que ajudam pacas.
[/quote]

Você tem certeza absoluta de que você quer permitir que um desenvolvedor faça, acidentalmente, um deploy de uma versão não testada no seu servidor de produção?[/quote] Foi bom você ter mencionado nisto. Não tinha pensado ainda neste ponto. Mas afinal, neste caso o que pode ser feito? Pois gostaria de deixar todas as funcionalidades pré-implementadas.

Acabei achando interessante a opção do buildFile obter informações de máquinas locais para efetuar tarefas para ambientes específicos, inclusive, reutilizar outros scripts, agora gostaria de obter tais templates implementados. Onde porderia conseguir?

Outra coisa que gostaria de abordar e saber por aqui é quanto a automatização de task para testes unitários e talvez utilizando via cactus para web, o que acham? Inclusive lendo scripts de banco de dados. (Agora não tenho experiência nenhuma quanto a scripts estarem acompanhando algum projeto que mapeiem algum teste implementado, o que acham também? ).

É um tanto interessante poder automatizar tudo isto, mas não esperava ter tanta dificuldade.

#9

[quote=faelcavalcanti][quote=Daniel Quirino Oliveira][quote=faelcavalcanti]Bem, fiz alguns tasks básicos no ant para alguns projetos e que funcionou bem, tais como: [criaWar] - [deployServidorTestes] - [DeployServidorProducao] - entre outros que ajudam pacas.
[/quote]

Você tem certeza absoluta de que você quer permitir que um desenvolvedor faça, acidentalmente, um deploy de uma versão não testada no seu servidor de produção?[/quote] Foi bom você ter mencionado nisto. Não tinha pensado ainda neste ponto. Mas afinal, neste caso o que pode ser feito? Pois gostaria de deixar todas as funcionalidades pré-implementadas.

[/quote]

Veja a sugestão do Shoes, uma mensagem antes da minha, de criar scripts diferentes para etapas diferentes do seu ciclo e distribua estes scripts apenas para as pessoas certas.

#10

Boa daniel, acho que estas estratégias já me ajudariam pra caramba . Afinal, é como o “shoes” falou, pois eu estava praticamente bitolado no ant.
Quanto a TDD que tinha mencionado acima, esqueci de postar o link do livro que tinha comprado sobre o assunto aqui.

Bem, venho tentando me reanimar , motivar e estabelecer formas de utilizar algumas práticas junto com a equipe. Alguém tem alguma sugestão ou dica quanto a implementação, reuso e problemas em testes caixa branca?

[caso seja melhor criar um novo tópico sobre o assunto me avisem!!!] :wink:

#11

Sobre TDD, seja um pouco malvado no começo. Exija que todas as classes sejam criadas usando test-first design e tenham testes unitários e use uma ferramenta de análise de cobertura de testes (como o JCoverage, Cobertura,… ) para acompanhar o andamento das coisas. A esta hora da manhã, é a única coisa que eu consigo me lembrar para recomendar.

#12

[quote=faelcavalcanti] Foi bom você ter mencionado nisto. Não tinha pensado ainda neste ponto. Mas afinal, neste caso o que pode ser feito? Pois gostaria de deixar todas as funcionalidades pré-implementadas.

Acabei achando interessante a opção do buildFile obter informações de máquinas locais para efetuar tarefas para ambientes específicos, inclusive, reutilizar outros scripts, agora gostaria de obter tais templates implementados. Onde porderia conseguir?[/quote]

Uma outra sugestão, e uma solução que adotamos aqui é ter todos as tasks de deploy implementadas por padrão, e teoricamente todo mundo consegue fazer. Na verdade é gerado um único arquivo e este é o mesmo arquivo para qualquer base(desenvolvimento, teste, homologação, produção, etc). O que limita o usuário é diretamente no servidor que nós só liberamos acesso para os IPs que podem realizar o deploy.

#13

Concordo com o Daniel. Só aconselho, ao invés de fazer análise de cobertura, usar uma métrica mais simples chamada Relação Código/Teste (Code to Test Ratio).

Relação Código/Teste = Linhas de Código / Linhas de Teste

Com essa relação simples já é possível avaliar se a quantidade de testes no sistema está aumentando ou não :wink:

#14

Pessoal, vocês tem algum projeto modelo ou exemplo pré-implementado para eu baixar e estudar melhor(tipo pode ser um projeto no svn do java.net, ou sourceforge, entre outro repositório ou local para download). Gostei bastante desta métrica para avaliar a quantidade de testes quanto ao que foi implementado.

Na verdade também estou com bastante motivação pelas informações de vocês e/ou posts em blogs e tal. Pois estou filtrando várias informações para convencer a equipe de que esta é uma forma legal de agente se adaptar, por exemplo.

Sinceramente estou com dificuldades neste ponto, em poder convencer e mostrar tanto na prática como na teoria que isto nos trará grandes benefícios, e ainda mais já que se trata de uma fábrica de software.

Percebi também que tenho que estudar um pouco mais sobre maven, e estarei começando pelo artigo de maurício daqui do guj, tá bem legal, assim como este JCoverage, e entre outros.

Sei que tenho que ser breve e objetivo e fazer um desenho de tudo que tem que ser feito agora e a médio/longo prazo, mostando as consequências, vantagens e desvantagens. Vou ter que fazer várias analogias sobre diversas situações de projeto. Mas neste momento, gostaria de começar a fazer um desenho e propostas para melhorias na parte de gerência de configuração(visto que não temos uma pessoa para isto, pelo menos por enquanto), assim como para o lance de estabelecimento de algumas métricas voltadas ao TDD.

Outro lance também é que em breve o pessoal estaria trabalhando em cima de pontos de função para estimativa de esforço de algumas implementações tanto na parte de projeto como codificação, e portanto pretendemos manter uma boa qualidade.

Bem desabafei com vocês do guj, mas obrigado galera pelas informações estou aprendendo pacas do que certificações não trazem no sentido de ter maturidade para lidar com projetos. Percebi também que preciso continuar a pesquisar e entender mais, de forma a, em breve, retornar com o conjunto de idéias que tenho e consequentemente vocês me sugeriram.

#15

Isso faz parte de algum projeto interno para mudar o jeito de fazer as coisas por aí ou você que está querendo revolucionar?

Bom, independente do como for eu aconselho trazer mudanças aos poucos (Baby Steps), botando na prática e avaliando uma coisa por vez (Inspect & Adapt). Acredito que assim seu trabalho ficará mais fácil. O que você acha?

#16

Aproveitando o contexto de automatização e melhoria, alguém aqui usa Continuous integration? Andei pesquisando sobre esse assunto, porém encontrei pouco material. Dicas de bibliografia e testemunhos são bem vindos.

#17

[quote=s4nchez]Isso faz parte de algum projeto interno para mudar o jeito de fazer as coisas por aí ou você que está querendo revolucionar?[/quote] Concordo com você colega. Tenho andado um pouco pretencioso sobre o assunto. Na verdade o que acontece é que estou em um contexto de fábrica de software, e estive tentando fazer um levantamento de possíveis métricas que poderia adotar a médio/longo prazo para garantir uma certa confiabilidade com os clientes, demonstrando maturidade no processo de desenvolvimento.

A maioria dos projetos são legados e estou pensando em uma forma de acoplar algo que possa medir, testar e explicitar algo sobre os projetos que venhamos nos envolver. Infelizmente não poderemos fazer isto em alguns projetos novos, pois temos um prazo para o final do 2º trimestre.

Contudo, voltando a sua pergunta. Eu digo que de certa forma sim, mas valeu pelo conselho. Afinal, não adianta abraçar os braços com o mundo se você não é tão capaz suficientemente maduro a ponto de envolver estas abordagens tanto nos projetos tanto com a sua equipe. Fallow!!! :wink:

#18