Podemos fazer com que a integração contínua seja contínua, minuto a minuto, projetos muito grande onde uma equipe de desenvolvimento e um equipe de teste estão real time devem ter uma integração continua bem estável, não podemos ter sistemas “desatualizados”, pior ainda é projetos onde a manutenção do dia-a-dia afeta os fontes que estão recebendo evoluções, para isso “auditores” de fontes, triggers no controle de versão que não deixa uma tag passar a outra, a tag “Produção” nunca pode passar pela “Homologação” se isso acontecer vamos mover automaticamente a tag “Homologação” para onde está a tag “Produção”, esse caso é comum se uma equipe corrigir um problema em produção pontual onde foi autorizado sua publicação sem passar pela equipe de teste, acontece.. e muito.., para isso o xmlrpc entra em ação, ele que vai chamar o build para levar o fonte em questão.
Isso se for usado algo do tipo Apache Continuum ou o Hudson.. falo mais depois.
abrass.
Pessoal, quero informar que é possívem sim a equipe trabalhar durante um deploy automático J2EE sem esperar o JBoss baixar e receber seus novos ear e ai subir, esse processo demora em média 30 minutos dependendo da quantidade de aplicações dentro do seu deploy.
Mas para isso precisamos de algumas configurações, segue link com as configurações iniciais o Apache e mod_jk ,
De uma olhada no link http://www.abcseo.com/tech/java/clustering-tomcat-apache nele o autor mostra como configurar o Apache e o modulo do mod_jk , depois disso precisamos colocar os nossos dois jboss em cluster de sessão para que um usuario logado no jboss1 esteja logado no jboss2 quando o build estiver em ação.
Segue um link http://docs.jboss.org/jbossas/guides/clusteringguide/r2/en/html/cluster.chapt.html explicando como colocar os jboss em cluster de web .
Posto mais detalhes em breve.
Pessoal precisamos nos cercar de ferramentas para garantir um ambiente estável, segue uma ótima idéia de colocar o CVS como servidor de configurações.
No Blog “Just for I.T.” http://blog.dossot.net/2006/11/centralized-configuration-management.html o autor apresenta uma ideia sobre ter um servidor de controle de versão para controlar arquivos de configuração de ambiente, isso pode ser muito util para ambientes grandes, a ideia de “hospedar” um xml de configuração no cvs e controla-lo por tags é boa e válida podemos acessar ele passando a url para o arquivo que o chama ou podemos ter um build para levar as configurações para o ambiente.
http://viewvc.tigris.org
O ViewVC é um cliente CVS baseado em browser podendo ser acessado pela url ex:
http://201.7.205.81/viewvc/viewvc.py/ProjetosJava/Contabilidade/contabilidade-ear/src/main/application/services/contabilidade-web-mail-service.xml?view=co&revision=1.29
Essa URL nos traz o arquivo na sua revisão 1.29 podemos trocar a versão pela TAG ex: &revision=TESTE
Nesse caso podemos colocar arquivos de configuração no CVS e acessa-los pela url.
Blz? …
Segue um help da sintax da URL do ViewVC
http://viewvc.tigris.org/nonav/source/browse/*checkout*/viewvc/trunk/docs/url-reference.html
Pessoal, se falarmos de integração continua de projetos java, com certeza vamos falar de POM ( Project Object Model ) não gosto muito dele mas e muito importante, pois ele facilita muito a rotina de build, esse xml pode conter todos os passos para o build, veja mais na wikipedia sobre o Apache Maven http://pt.wikipedia.org/wiki/Maven .
Builds mais antigos vemos muito o uso do Apache ANT,
Apache ANT
Segundo a Wikipedia o Apache Ant é uma ferramenta utilizada para automatizar a construção de software. Ela é similar ao make mas é escrita na linguagem Java e foi desenvolvida inicialmente para ser utilizada em projetos desta linguagem.
A mais aparente diferença entre as ferramentas Ant e make, é que a primeira utiliza um arquivo no formato XML para descrever o processo de construção (build) e suas dependências, enquanto o make possui o seu próprio formato de arquivo, o Makefile. Por padrão este arquivo XML tem o nome build.xml. [ leia mais em http://pt.wikipedia.org/wiki/Apache_Ant ]
Até o próximo post.
Pessoal, pretendo nesse post dar uma breve dica sobre deploy de tecnologias WEB cuja o sentido da integração é um só do CVS para o wwwroot , isso eu chamo de deploy automático, mas existe também o reverso disso, do wwwroot para a lixeira nesse caso chamo de Desintegração ou Integração Reversa o fonte já está no servidor web só que ele foi descontinuado, cancelado no CVS e ai precisamos remover ele do servidor web para diminuir a poluição dentro do wwwroot, complicado? não questão de organização.
Para essa tarefa uso o Python como ferramenta de script, faço um CVS LOG apontando para um arquivo.log e ai um pequeno parse no log procurando os fontes cancelados, pós isso tenho uma lista de fontes que não deveriam estar mais dentro do meu wwwroot e saio apagando os arquivos, apago sim.. pois um arquivo no CVS como cancelado não poderia estar no ambiente! OK?
Até o próximo post.
