Blog

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

Série Continuous Integration: Reiniciando Jenkins sem reiniciar o servidor

Olá Pessoal,

No post de hoje vamos ver como reiniciar o Jenkins sem reiniciar o servidor pelo painel de controle. Parece algo que deveria ser simples, ou seja, um simples botão resolveria a situação. Mas não temos esse cara no painel do Jenkins. Então, como fazer?

http://seuservidor:porta/jenkins/restart

jenkinsrestartask

Se tiver local:

http://localhost:8080/jenkins/restart

 

jenkinsrestarting

 

O Jenkins vai perguntar se realmente deseja reiniciar o servidor, caso deseje clique no botão “OK” e aguarde.

Simples, não?

Abraços.

Experiência AngularJS + Java em Produção

divedoo

Olá Pessoal,

O post de hoje vou falar  um pouco sobre a experiência que tivemos aqui na ITSLabs com desenvolvimento de um produto usando AngularJS e hoje está em produção. O produto ainda é um MVP versão 1.0.0 e foi de desenvolvido em 45-50 dias.  Para quem acompanha o blog venho trabalhando com AngularJS no dia a dia a quase 1 ano e criei o grupo AngularJS-Brazil (https://groups.google.com/forum/#!forum/angularjs-brazil) no Google Groups e mais uma vez reforço para quem está chegando, quer aprender qualquer tecnologia? Saia do CRUD, só assim você vai poder aprender  de verdade.

Lets go…

 

ITSLabs

Antes de começar falando do projeto, deixa eu falar rapidamente da ITS. A ITS é uma start-up  voltada para criação de produtos web e mobile. Aqui buscamos resolver os problemas dos nossos clientes identificamos qual a tecnologia resolve melhor o problema. Portanto, a tecnologia nada mais é que apenas uma ferramenta para atingir o objetivo. Hoje temos projeto com AngularJS, NodeJS, Java etc.  Em breve assim que tiver um ok do cliente teremos mais um case que vou compartilhar aqui com vocês de um projeto NodeJS + AngularJS.  A ITSLabs não é consultoria, fabrica de software que tem o foco apenas em desenvolver software, vamos um pouco além, e precisamos entregar valor ao negócio do cliente e também trazer valor para nossa equipe técnica. Já rejeitamos projetos que financeiramente seria ótimo, mas valor entregue tecnicamente para nossa equipe seria quase zero. Nosso dia a dia é bem Agile, trabalhamos 95% remoto e pouco focado em horas trabalhadas ou que horas você entrou hoje e saiu ontem. Atender aos prazos com qualidade é o nosso maior ativo.

 

DiveDoo – www.divedoo.com

É uma plataforma que busca resolver o problema de quem  busca acessório, curso, equipamentos na área de mergulho, mas não sabe como e onde encontrar. Fazendo uma pesquisa no Google as informações estão espalhadas e alguns sites podem não ser confiáveis. Baseado nisso foi criado a plataforma pela mergulhadora Gabriela Galvão.

Nossa experiência com AngularJS          

Esse foi  o nosso terceiro projeto com AngularJS em produção, os dos primeiros eram projetos bem menores com relação ao DiveDoo.  Ter escolhido AngularJS foi  uma excelente escolha, por alguns motivos:

  • Manutenção do lado do cliente: ganhamos muito na organização de  js, css etc.  Isso foi fantástico e crucial  para o desenvolvimento;
  • Integração com back-end: ter o back-end e front 100% independente. É fantástico, podemos mudar para  qualquer outra tecnologia sem precisar tocar no código do cliente.
  • Ter programadores trabalhando em paralelo e separado sem bloqueios: isso ajudou bastante, alguns programadores back-end odeiam front-end (eu era um desses, mas deixei de ser graças ao AngularJS) e aqui podemos manter cada um trabalhando do seu lado e se comunicando apenas através de uma API REST.
  • IE: esse cara é uma dor de cabeça. Então se você pensa em querer dá suporte para versões antigas  como 8 ou inferior. Esquece de usar AngularJS, apesar que o pessoal da Google fala nas versões mais antigas do AngularJS que eles oferecem suporte e talz, algumas coisas não funcionam bem, e ainda depender do Windows com a versão do IE, pegamos incompatibilidade. É tenso o negócio, simplesmente consome um tempo enorme para tentar achar a solução e se encontrar.  Se você tem um projeto que vai dá suporte a esse camarada em versões antiga, pode ir buscando outro framework, pq o AngularJS não vai rolar. E o problema não é do AngularJS, na verdade ele nasceu sem vontade nenhuma em querer ajudar o browser da Microsoft :). A partir do IE9 as coisas já funcionam com uma compatibilidade melhor.

Tools

Usar Yeoman  & Grunt é um fator de produtividade. Criamos uma estrutura do lado do back-end onde o desenvolver front-end consegue testar aplicação com back-end localmente e podendo sempre pegar o ultimo código que foi comitado. Separamos isso em módulos :

  • Web: aqui  é a versão que vai para o servidor remoto
  • Core: todo back-end
  • Webdev: aqui é onde o programador front-end trabalha e segue toda a estrutura do Yeoman. Se for preciso debugar um código local basta subir aplicação a partir desse modulo  usando o comando: grunt Server  e pronto.O Server vai subir em porta e IP diferente da aplicação que possui o back-end.  Quando o trabalho de front-end está concluído e precisa ser integrado com o back-end basta executar um grunt build e todo código do front é minificado e colocado no modulo de web  para ser deployed. Para quem está trabalhando no front-end isso é transparente.

Montamos essa estrutura, pois em projetos passados sofremos bastante com isso, a estrutura tudo em um único projeto funciona bem, quando temos um projeto que não é grande, ou seja, poucas funcionalidades. 

Aprendizado

Aprendemos que sem Yeoman é querer sofrer. Realmente é uma ferramenta poderosa e querer fazer tudo na mão, é perda de tempo, exceto se você está querendo aprender criando seus projetos house made. Mas, projeto que vai para produção, não recomendo. UI-Router  esse é o cara. Muito bom, e facilita bem o uso de rotas dentro do AngularJS. Quando você usa o UI-router que percebe a limitação que temos com as rotas default com AngularJS. Em breve vou fazer um post sobre  ele. Aprenda a separar as coisas, controller, services etc. Ter tudo organizado e separado é importante. Crie padrões de nomeação de arquivos para facilitar na hora que for buscar. Se você usa o Yeoman, ele ajuda em manter tudo organizado.  Use e abuse da injection dependecy que temos no angularJS, é fantástico. Lembro que quando comecei a estudar AngularJS demorei um pouco para pegar o core de usar injeção de dependência , a dica é leve o tempo que puder estudando, mas aprenda.  Não tenha medo de perguntar e não ache que você sabe tudo, esse é o maior erro achar porque fez algum CRUD que já aprendeu, pelo contrario é nesse momento que a brincadeira começa, todo dia  você vai aprender alguma coisa nova.

Conclusão

Hoje usamos fortemente AngularJS em nossos projetos aqui na ITS, há outros valores na tecnologia da Google que se fosse entrar nos detalhes  o post viraria um livro. Por falara nisso, em breve estarei lançando meu próximo livro que será sobre AngularJS, que nada mais vai ser o que aprendi nesse  quase 1 ano em três projetos completamente diferente e os erros que cometi, e acertos que também tive.

Vou ficando por aqui…

See ya!!!Abraços,

Série Continuous Integration: Deploy Automatizando Jenkins TomCat

Olá Pessoal,

No post de hoje vamos ver como fazer um deploy automatizado usando o Jenkins. Como assim? Vamos entender a seguir.

Lets go…

Entendendo o contexto

Não é muito difícil encontrar algum programador que tenha algum dia trabalhado em um projeto onde o deploy da aplicação era feito manualmente, ou seja, gerar o .war localmente e copiar para o servidor remoto  via FTP, ssh etc. E sabemos o quanto é demorado fazer isso por mais que tenhamos uma boa conexão de internet já que o .war tende a aumentar à medida que nosso projeto vai evoluindo e permanecer fazendo isso manualmente tende a demorar mais ainda o tempo de cópia do .war para um ambiente remoto. Já fiz muito isso e em alguns projetos já levei 30min esperando o .war ser copiado. E quando vejo, a alteração que acabei de fazer não foi junto naquele .war porque fiz o build antes de ter salvo a alteração. O que fazer? Build e aguardar por mais 30min. E ai já foi 1hr do seu dia fazendo algo operacional e que custa caro.

Deploy Automatizado /Delivery Continuous

É ai que entra o deploy automatizado. No jenkis, além de oferecer o build automatizado, há suporte através de plugin para que possamos pegar o artefato (.war/ear) gerado no build e colocar em um servidor remoto (jetty, tomcat, glasshfish etc) de maneira automatizada, ou seja, quem vai copiar e colar o arquivo será a própria ferramenta e certamente será mais rápido que copiar da sua máquina local para o  servidor remoto. E outra coisa, tudo isso fazendo hotdeploy, ou seja, não é preciso parar o Server para colocar .war, mas é recomendado fazer quando a copia .war for muito grande, e se ela não termina antes do tomcat, jetty etc verificar se algo mudou, o arquivo será corrompido. E o que acontece com sua aplicação? Down. E teremos que subir manualmente. Claro que tudo depende do seu ambiente; se é de DEV não tem problema fazer hotdeploy, mas se for um ambiente de PROD, você arriscaria fazer um hotdeploy? A resposta seria: depende. Normalmente não vamos querer fazer uma release para PROD no horário comercial ou de mais acesso da aplicação por uma questão de segurança e disponibilidade do serviço.

Na prática

Considerando que você já tem o Jenkins rodando e um projeto, vamos direto ao ponto.

O que você precisa?

Vá em manager jenkins >> manager plugins

E instale o seguinte plugin

  • – Copy Artifact Plugin
  • – Deploy Plugin

O primeiro tem como objetivo copiar o artefato, ou seja, o .war. Então vamos configurar que após o build success do projeto X vamos copiar o artefato e deployed no servidor TomCat. Quem faz o deploy é o segundo plugin. Instale os plugins. Escolha a opção install without restart.

Criando um novo Job

Considerado que você já tem um projeto configurado no Jenkins, você não precisa fazer nada nesse projeto, apenas crie um novo Job do tipo Freestyle. A seguir o meu:

jenkinsdeploydev

O nome do projeto foi omitido.

Configurando o Job

jenkinsbuilddeploy

Em Project Name você informa de qual projeto você que copiar o artefacto. Verá que ao digitar o nome do projeto/job já existente o Jenkins vai oferecer um autocomplete.  Em seguida informamos que queremos apenas .war, senão ele vai copiar tudo que tiver no outro projeto, ou seja, se tiver um .ear ele seria copiado por exemplo.

Deploy no TomCat

Agora vamos fazer o deploy no TomCat.

jenkinsdeploytomcat

Aqui dizemos aos jenkins o que fazer depois que ele copiar o artefato, e estamos dizendo para fazer um deploy.  Para aparecer esse form, clicque em add post-build action e escolha deploy artficats. Na imagem acima informamos o tipo de arquivo que será deployed, o servidor, o contexto, usuário, password e a url onde está o servidor.

Claro que o usuário precisa ter acesso ao servidor. No caso do tomcat, vá em conf/tomcatusers.xml e verifique se o usuário está lá. E certamente não vai estar com role para execução de script, portanto adicione manager-script, ficando assim:

<role rolename="manager-script"/>

<user username="camilo" password="xxxx" roles=" admin,manager,manager-gui,

manager-script,manager-jmx"/>

 

Isso é requerido, senão o plugin não vai conseguir realizar o deploy. O .war será colocado dentro de webapps do servidor tomcat.  Quando o build terminar com sucesso, acesse sua aplicação. Se for local digite: http://localhost:8080/nomeDaSuaApplicacao

Lembre-se que se definiu o Context, informe o nome depois da / senão acesse pelo mesmo nome do arquivo .war.

Meu case

Antes de implementar o deploy automatizado aqui no projeto o tempo de cópia de um artefato para o ambiente de dev  remoto era de 30min incluindo o stop e start do tomcat, após o deploy automatizado caímos para 55sec, veja :

pipelinegreen

Note: Se você não especifica, o Context será o nome do arquivo .war.

Nota Importante

Se o Jenkins e sua aplicação são deployed no mesmo servidor, você não tem como fugir do hotdeploy, já que ao fazer um restart vai cair todos os serviços que estão rodando no Server.

Vou ficando por aqui espero que tenham gostado do post.

Abraços, see ya!!

Série Continuous Integration: Usando GitHub para autenticação no Jenkins

Olá Pessoal,

No post de hoje vamos ver como usar uma conta do GitHub como autenticação  para o nosso Jenkins. Eu particularmente acho isso fantástico, pois não preciso ficar gerenciando usuários. A única desvantagem é se o projeto não usar GitHub.  Daí podemos optar pelo próprio banco do Jenkins ou criar um com o MySQL, por exemplo, e fazer o Jenkins consultar o usuário nessa base de dados.

Lets go…

Starting…

Considerando que você já tem o Jenkins instalado, por default ele não pede autenticação, ou seja, qualquer um que souber o endereço do seu jenkins, caso esteja publico, pode acessar e buildar ou apagar o seu projeto. Que ruim heim? Vamos ver aqui como fazer autenticação.

Se você vem acompanhando o post no blog, certamente já tem o plugin do GitHub e o de autenticação instalado no Jenkins, senão instale em manage Jenkins >> manage plugins.

 

jenkinsplugingithub

Instale e salve. Escolha a opção Install without restart.

Agora vá novamente a manage jenkins e escolha configure global security. Por default vai estar desabilitada. Habilite.

E escolha:

 

jenkinsgithubauth

Aqui teremos que colocar as informações de autenticação do GitHub. Mas o que colocamos ai? A autorização de que usuários podem logar nessa aplicação a partir do GitHub. Então siga esses passos:

  1. Faça o login no Github com sua conta ou a conta que irá permitir acesso;
  2. Acesse: https://github.com/settings/applications
  3. E agora:

 

jenkinsregistergithub

E preencha:

 

jenkinsgithubregisterdone

O clientID e o Client Secret são gerados. Coloque no campo do Jenkins respectivamente, e agora vamos autorizar os usuários que podem acessar. Coloque no campo a seguir os usuários do GitHub que será admin no Jenkins, ou seja, terá permissão total sobre o build:

jenkinsgithubauthorization

A separação é por vírgula. Não se esqueça disso.

Salve as alterações. Feche o Jenkins e abra novamente. É esperado que apareça:

jenkinsgithublogin

Faça o Login. No primeiro acesso, o GitHub vai perguntar se você deseja acessar a aplicação de terceiro que você foi adicionar, permita o acesso e pronto. Você já vai cair no Jenkins.

Show e simples né?

Abraços. Vou ficando por aqui.

See ya!!