Tag: jenkins

Série Continuous Integration: Build a partir da Tag Github

jenkinslogo

Olá Pessoal,

O post de hoje vamos ver como fazer um build no Jenkins a partir de uma tag  do Github. Vou considerar que você já como configurar o seu job no Jenkins com o Git/Github.

Lets go…

 

Starting…

Uma hora você vai precisar fazer um build de uma tag, versão estável. Então como fazer isso  no Jenkins?Você pode pensar que é apenas informar */tags/nomedatag É bem simples veja os passos:

Passo 1

Instale o plugin Git parameter Plugin no Jenkins

Passo 2

Marque a  opção  : This build is parameterized. Vou considerar que você já tem a tag criada no seu repositório Github

jenkinstaggithub

Agora preencha conforme a imagem acima, observe que no campo tag filter, é o nome da tag que você deu. Em Branch coloque */tags

Passo 3

Agora em source code  management deixei conforme a imagem a seguir:

jenkinsgittagsource

O ponto mais importante aqui é informar em branch o parâmetro ${tag} que acabamos de crair no passo anterior.

Passo 4

Salve as alterações

Passo 5

Clique em Build with parameter  e escolha a tag que acabou de criar.

jenkinsgithubcheckouttag

Pronto agora é aguardar o build ser concluído e verificar no console  que o código está sendo baixado a partir da tag

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!!

Série Continuous Integration: Criando uma tag no github via Jenkins

 

jenkinslogo

olá Pessoal,

Hoje vamos ver como criar uma tag em nosso projeto e publicar no github. Considerando que você já tem o seu ambiente Jenkins funcionando.

Lets go..
Starting…

Primeiro passo é instalar o plugin Git Publisher.

Passo 2

Após ter instalado o plugin vá no seu projeto e clique em configuration. Em sourceCode Management clique em Advanced

jenkinsgittagsourcecode

No campo Name que deve está vazio, informe o nome que desejar, eu coloco o nome do projeto.

Passo 3

Adicione um Post-build Actions Step e escolher Git Publisher

jenkinsgitpublisher

Observe que podemos ter um create new tag ou update new tag. Se for uma nova tag escola create new tag. Informe em Tag to Push como será o nome da sua tag.

O ponto mais importante aqui que temos é informar o repositorio que é feito em Target remote name onde informar o nome que definimos nos campo Name em source
code.

Passo 4

Feito isso, salve as alterações e iniciei o build. Após a conclusão do build a tag será criada no github, vá no repositorio e veja se a tag foi criada em
releases

jenkinstaggithubreleased

Simples não? Agora vc tem a criação de tags para o github automatizada.

abraços,

E-Book: Integração Contínua com Jenkins p/ Desenvolvedores Java

olá Pessoal,

Como foi o ano novo de vocês? Eu espero que tenham curtido bastante e descansado também. No meu caso foi consegui um tempo para descansar, mas como não consigo ficar parado 100%, aproveitei e trabalhei nos meus projetos pessoais. E um deles  é poder esse ano lançar através da ITSLabs alguns ebooks mão na massa compartilhando cada experiência que vamos tendo aqui na empresa.  Eu sempre  quis ter livros práticos que me ensinasse rapidamente como sair fazendo as coisas e depois eu poderia aprender e me aprofundar na parte teorica, sendo assim esse será o objetivo dos nossos e-books.

Esse livro  do Jenkins por exemplo venho escrevendo desde do final de 2012, mas somente agora foi possível para e olhar  e filtrar para saber o que colocar.

Preço 

Os livros estão sendo formatados.Mas, a ideia é ter um preço justo. É verdade, não é nosso objetivo ganhar dinheiro com os ebooks, apenas queremos disponibilizar com um valor justo e  o mais importante é pegar o valor total de vendas  pagar os custos operacionais e o que sobrar vamos doar para uma instituição  que ajuda pessoas em tratamento contra o câncer. É isso mesmo, o seu investimento será re-investido em uma instituição que estou selecionando e em breve vou divulgar aqui qual será a instituição que queremos ajudar.

Cópia e Distribuição do Ebook 

Sei que qualquer um pode comprar o ebook e sair distribuindo pelo dropbox, google drive ou qualquer outro meio. Dai a responsabilidade é sua. Ah! Não falo de processo. Por que o custo financeiro  e tempo com isso não compensa e não é meu interesse.

Mas, quero dizer que a partir do momento que você  faz isso, está deixando de ajudar aquelas pessoas que estão lutando pela vida a cada minuto. Pense nisso por um minuto, ainda bem que não é você que em uma situação com uma doença tão crítica como o câncer.

E-book 

O ebook está disponivel  em https://leanpub.com/integracaocontinuacomjenkins  se ficou interessado informe seu e-mail e quanto pagaria pelo livro.

Formatos:

  • PDF (Mac or PC)
  • EPUB ( iPad, iPhone, Android)
  • MOBI (Kindle)

Conclusão

Esse é o primeiro que espero de muitos livros mão na massa que quero lançar durante esse ano.

abraços!!

Série Continuous Integration: Clonando workpace no Jenkins

jenkinslogo

olá Pessoal,

O post de hoje vamos ver como clonar um workspace de um outro job. Mas, você pode está se perguntando, pq eu fazer uma clone de workspace? Para responder a pergunta vou apresentar um cenário e ai você entende o motivo.

lets go…

 Instalando o plugin

Vamos instalar o plugin que permite clonar o workspace no Jenkins em manage plugins procure por: Clone Workspace SCM Plug-in e instale o plugin.
O cenário

Por que eu deveria clonar um workspace? Na verdade o que seria clonar o workspace?

vamos lá. Clonar um workspace nada mais é que copiar o conteúdo de um workspace para outro. Mas, pq eu faria isso? para não ter que baixar o projeto novamente e usar o do último build. Nos projetos aqui na empresa temos vários jobs por exemplo: compile >> tests >> build >> deploy

Da esquerda para direita, o primeiro job é o que verificar se houve mudança no repositorio remoto e em caso positivo começa o build. Os demais projetos, não podem verificar no repositorio repositorio remoto, apenas usam o código baixado para executar o que foi definido no job. E ai que entra a vantagem de fazer clone do workspace, caso o job compile passe, podemos copiar o workspace.Eu já cometi o erro de não fazer isso, e simplesmente pegar o código do repositorio no proximo step do Jenkins, mas é um risco grande do código que foi executado no primeiro job, não ser mesmo o que está no segundo ou nos posteriores, pois se algum código foi enviado para o repositorio remoto nesse intervalo os próximos job vão fazer o checkout. E para evitar isso é melhor copiar o workspace.

Na prática

No projeto inicial, precisamos dizer que se o build passar, ele deve permitir que o workspace seja clonado. No meu caso é o job que chamei de compile que vai fazer isso:

jenkinscloneworkspace

Agora no segundo job que é tests, vai copiar o conteúdo do workspace do projeto compile:

jenkinsourcecodecloneworkspace

Observe que no source code informei que o código vem de outro workspace e não do git, svn etc.
Build

Agora build o projeto inicial(compile) e depois o próximo projeto(tests) e veja que o workspace foi copiado.

Simples não?

vou ficando por aqui e espero que tenha gostado do post.

abracos, see ya!!