Iniciante - Primeiros passos com o Jenkins

[Alex Silva]

   Ola pessoa, sou iniciante em ferramentas de integração continua. Nas minhas pesquisas encontrei o Jenkins e resolvi adotá-lo,  consegui instalar sem problemas, também instalei o ANT para trabalhar em conjunto com o Jenkins. Por enquanto não integrei com o git e/ou  CVS. 

   Encontrei alguns problemas, não estou sabendo como fazer o Jenkins perceber as mudanças realizada em meu projeto, também estou com duvida em relação ao build.xml do ANT.  

   Se possível queria uma orientação de vocês. Como vocês realizaram as configurações em seus Jenkins ?  E que dicas vocês me dão ?

   

   Agradeço deste já a atenção e a ajuda !

[João Francisco Amorim Enomoto]

Fala Alex, seja bem vindo à comunidade!

Dada a sua explicação eu imagino que você esteja querendo fazer várias coisas ao mesmo tempo. Vou tentar descrever em passos as coisas que você precisa se atentar para deixar seu projeto rodando direto no Jenkins:

- antes de instalar o ANT para funcionar no Jenkins, você precisa fazer com que a construção do seu projeto funcione com ANT. Certifique-se que você possa fazer a construção do seu projeto localmente pela linha de comando: a configuração que você precisa fazer no Jenkins é exatamente a mesma que você faz pra compilar/rodar os testes na sua máquina;

- para que o Jenkins perceba alterações no seu projeto é fundamental que ele esteja em algum repositório Git/CVS/SVN/Mercurial/etc. É possível você configurar o Jenkins para checar alterações automaticamente no seu repositório para disparar as construções do seu projeto, mas ele precisa saber de onde ele deve baixar o projeto para saber se houve ou não alterações;

Sobre ANT, eu mexi muito pouco e talvez não seja a pessoa mais aconselhada para dar esse suporte, mas tem outras pessoas na comunidade e com certeza bastante material na internet.

Abraços!

--
Você recebeu essa mensagem porque está inscrito no grupo "jenkinsci-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para jenkinsci-br...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Adriano Andrulis]

Minhas dicas sao (antes de pensar em jenkins):

- definir seu controle de codigo. Git com preferencia, senao Subversion. Nao recomendo usar CVS pois nao e suportado por alguns plugins pro jenkins.

- definir uma ferramenta para o build que defina um ciclo de vida mais definido. Gradle e Maven sao opcoes bem melhores, especialmente se seu projeto for java. Ant eh muito "flexivel", significando que voce vai ter de implementar muitos passos manualmente.

- construir seu software manualmente com sucesso, por exemplo usando maven seria o comando: mvn clean install

Com o seu projeto sendo construido com sucesso, so entao criar o job em jenkins que reaja ao codigo sendo alterado e chame o mesmo: mvn clean install 

se maven for sua escolha, jenkins oferece um tipo de job maven que tem varias simplificacoes ao inves de um job adhoc.

Jenkins deve ser usado mais como uma ferramenta de automação de projetos com um minimo necessario de plugins para jenkins, pois senao a vida do desenvolvedor fica mais dificil pois nao da para reproduzir o processo de construcao localmente.

Se voce nao configurar um sistema de controle de versoes, nao vejo um opcao para "reconhecer" mudancas. Vc poderia mandar executar o job a cada X minutos, mas nao seria baseado em mudancas.

Normalmente voce configura o jenkins job para checar por alteracoes no seu controle de versoes a cada X minutos e se uma mudanca e reconhecida o job e executado.

Abracos,

Adriano

--

[Leonardo Kobus]

Sobre o ANT eu daria chance a algumas outras tecnologia, ou coisas que utilizam o ant por debaixo do pano.
Existe uma tendência muito grande de se usar DSL (Domain Specific Language) mais code friendly do que XML, vide o crescimento de Gradle, rake e powershell. E como XML não é algo feito para programar porque é chato e demorado outras DSL se mostram mais eficaz em criar scripts mais rapido e mais poderosos, sem dizer que é bem melhor de se lê, já que alguns scripts podem ficar bem grandões.

Eu usava o MSBuild (trabalho muito com .NET) e ele é muito parecido com o ANT, e o XML da no saco uma hora e te limita bastante, depois que comecei usar powershell que é mais código o negocio mudou bastante, sem dizer que fica melhor para outra pessoa mexer também porque algumas coisas é possível testar e documentar com algumas IDE de suporte.

Acredito que vale mais a pena conhecer o ant e partir pra outra coisa do que trabalhar com ele, mas ai você tem que decidir.

E sobre o Jenkins, para ele perceber a mudança, tem que entender o ciclo dele que é bem básico (talvez tenham mais passos, mas é o que a UI costuma mostrar por padrão)
1 - disparador -> o que inicia o jenkins ( poder ser um clock de relógio, pode ser uma alteração em SCM (svn/git/mercurial e etc)), é o passo que vai disparar o build começar a executar tudo o que foi pré programado. (esse é o passo que vai perceber as mudança).
2 - Pré build -> É possivel setar algumas configurações antes de começar o build como variaveis, ou configurações que vão mudar o comportamento do build.
3 - Build -> É o que vai fazer o trabalho bruto, seja compilar um projeto, fazer um deploy ou chamar qualquer outra atividade que deva executar.
4 - Post Build -> é o que o Jenkins vai fazer depois de terminar o Build, executar uma outra atividade chamando outro Job, guardar artefatos para uso posterior ou analisar o que ocorreu no build (alguns plugins permitem isso).

Tentei dar um overview.

Já que está começando eu recomendaria também ler alguns tópicos ( se tiver interessado em emergir no mundo de DevOps e afins) como:
- Controle de versão
- Ferramentas de SCM
- Linguagens de build (geralmente chamadas de DSL)
- One click build
- One click Deploy

A algum tempo atrás eu li o livro Entrega Contínua (do jez humble) cada capitulo abrangem um tópico estilo o que citei acima, e falar de diversas tecnologias desde coisas windows/linux, e diversas linguagem como c/php/java/c# e etc, talvez fosse uma leitura legal pra começar a pegar o feeling do que se quer fazer (as vezes o Jenkins da tanta opção que o cara fica meio perdido, e o livro me ajudou a dar uma orientada no que realmente importava).

Espero que ajude.

[] ' s

[Alex Silva]

 Obrigado pelas boas vindas pessoal. Obrigado pelas dicas e por tirarem as minhas duvidas.

 Estou com mais uma duvida e gostaria da ajuda de vocês novamente.

 Estou usando o Maven e gostaria de saber como faço para gerar junto ao numero da versão a data e a hora. Por exemplo: 3.0.1-2015-03-03_19:43. 

E outra duvida é fazer com que a cada segunda feira, por exemplo, o Jenkins automaticamente fizesse o Build.

[Diego Rafael]

Olá Alex,

Para fazer a cada segunda-feira o Jenkins executar um build, você pode configurar uma cron expression para o Job.

https://wiki.jenkins-ci.org/display/JENKINS/Cron+Column+Plugin

Sobre a versão, a única forma que eu conheço seria fazer um script "customizado" (Python, Shell Script) para controlar este numero da versão com a data/hora pra você, não conheço uma forma de fazer isso pelo jenkins.

Abraços!

--

[Thiago Colbert]

Alex,

Não é uma boa prática colocar esse tipo de informação no número da versão. Sugiro que depois dê uma olhada em http://semver.org para dicas nesse assunto. No topo da página tem link pra ela em português, caso prefira.

Também não é boa prática tornar o <version> do POM dinâmico. Você pode usar outros recursos, dependendo da necessidade. O que eu vejo muito ser feito é:

- Adicionar o n° do build do Jenkins ao número da versão, ficando algo como: 3.0.1-build-25, 3.0.1.25 ou 3.0.1-25, dependendo do padrão que for adotado. Isso fica configurado na tag <finalName> do POM.
- Se for pra exibir essa informação na tela, usar plugins e recursos do Maven que permitem disponibilizar o número da versão e a data do build (e outras informações) na tela, via arquivos properties, por exemplo.
- Se for somente pra ficar registrado, adicionar um atributo dentro do MANIFEST.MF do WAR/JAR/EAR contendo a data do build.

Se for realmente necessária essa data no número da versão, acho que fica mais "elegante" usar o timestamp ou mesmo os valores um ao lado do outro, sem separadores (/, :):
3.0.1-100320151411 ou 3.0.1.100320151411
(Versão 3.0.1 de 10/03/2015 14:11)

Nunca cheguei a implementar esse último caso, mas provavelmente você precisaria do build-number-plugin pra usar a data como "build number" e definir seu finalName como algo do tipo:
<finalName>${project.artifactId}-${project.version}-${buildNumber}</finalName>
(Mais info em http://mojo.codehaus.org/buildnumber-maven-plugin/ )

Se não tiver problemas com inglês, sugiro dar uma olhada:
- http://stackoverflow.com/questions/1230015/can-i-set-the-project-version-with-a-buildnumber-maven-plugin

Espero ter ajudado em algo. :)

Att.
Thiago

--