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!!

Série Continuous Integration: Automatizando banco de dados com flyway plugin

Olá Pessoal,

No post de hoje vamos ver como automatizar a criação do Banco de Dados usando o Jenkins + o plugin flyway via Maven. Aqui na ITS usamos Continuous Integration e Continuous Delivery em todos os projetos, respiramos isso. Não apenas por ser algo “bacana tecnicamente”, mas pelo valor que é entregue aos projetos e para empresa também.

Lets go…

Cenário

Iai, quantas vezes você já teve que falar: “ah, agora vai para o ambiente de dev e tenho que gerar toda base de dados, e vou levar pelo menos 30min”. Pois é, aqui já tivemos esse cenário enquanto estávamos validando qual ferramenta íamos usar e, para não sair usando qualquer coisa, o ideal era fazer manualmente, mesmo consumindo media de 30min para ter todo banco pronto antes de fazer o deploy da aplicação no ambiente de DEV.  E se uma tabela sofre alteração? E se preciso replicar a mesma tabela em outro ambiente? Quanto tempo levaria?  Acho que já percebeu o problema aqui, certo? 

Pensando em resolver esse débito técnico, conhecemos o flyway. Na verdade já falei dele em outro post, mas agora vamos integrar o flyway com o Jenkins que nos permite ter um job que vai executar apenas a criação das tabelas.  

Vou me limitar apenas em configurar o Flyway no Jenkins e eu assumi que você já tem ele configurado no pom.xml do seu projeto. Caso não tenha feito isso, confira o post que falei em específico sobre como usar o plugin.

Requisito

Antes de mais nada, crie um arquivo .sql  que crie uma simples tabela no banco de dados, e nas configurações do pom.xml garanta que o usuário tem as devidas permissões.  O arquivo .sql deve estar na estrutura esperada pelo flyway.

Starting…

Passo 1

Crie um novo Job no Jenkins, dê um nome ao job e escolha Build a maven2/3 project.

jenkinsdbscript

Passo 2

Agora precisamos informar a url do repositório do projeto (no meu caso está no github).

jenkinsflywayconfig

Informamos a branch, que pode ser deixado em branco e será considerado a master.

Não é requerido que seu projeto use o Git. Pode ser SVN ou qualquer outro controlador de versão, desde que você informe o repositório do projeto.

Passo 3

Em pre-step vamos executar um clean e compile e por final exibir o status de execução do flyway, ou seja, saber qual script será executado.  Lembre que o compile é requerido pelo flyway.

Passo 4

Agora em build deixe assim:

jenkinsflwyaybuild

É esse cara que faz a mágica de criar as tabelas, ou seja, ele vai executar o(s) arquivo(s) .sql.

Passo 5

É isso apenas. Agora vamos buildar o projeto e esperar que a tabela seja criada. Acompanhe pelo console.  Outro ponto importante é garantir que o banco de dados está rodando. Parece óbvio, mas nada impede de esquecermos de iniciar o DB. Salve as alterações e clique em build now.

 

Resultado

Olhando o console vamos ver o seguinte (claro que será diferente do seu):

jenkinsbuildinfosuccess

No meu caso já tinha outros .sql executados, mas na última linha observe que está marcado como future, ou seja, que será executado. Esse é o resultado do comando que colocamos no pré-step, e como deu tudo certo aqui, vamos ver o resultado do build.

jenkinsflywaybuildok

Agora acesse seu banco de dados e o esperado é que a tabela tenha sido criada. Analise o tempo que levou para execução do script. Quando trabalhamos com projetos pequenos parece que ter esse trabalho de configurar e criar uma build para esse fim é como se fosse inútil, que fazer manualmente seria mais rápido, porém pode acreditar que o investimento feito no tempo de setup e configuração é muito menor que os problemas que passamos quando fazemos criação de base de dados manualmente.

Simples, não? Espero que tenham gostado do post.

Abraços, see ya!!