Series – Blog do Camilo

Série AngularJS: Usando Yeoman com AngularJS

Olá Pessoal,

No post de hoje vamos ver como usar o Yeoman com AngularJS. Eu falei sobre o Yeoman rapidamente nesse post.

Lets go…

Step 1

Para o ambiente Windows, você pode ter o Gitbash instalado com suporte a execução de comando linux/unix. Instale também o NodeJS.

Step 2

Agora abra o Gitbash e digite o comando

npm install -g yo

Ao terminar

Step 3

Para ter suporte à criação de projetos com o angular, precisamos instalar o generator para o framework.

npm install -g generator-angular

Crie uma pasta algo como yeomandemo. Entre nela e digite

yo

Responda Y

E escolha a opção:

yo angular

E vá respondendo às perguntas.

Pronto, seu projeto foi criado. Para entender a estrutura há um post completo: http://www.sitepoint.com/kickstart-your-angularjs-development-with-yeoman-grunt-and-bower/

No meu github coloquei um exemplo do projeto demo que fiz com yoeman gerando o projeto com angular https://github.com/camilolopes/workspaceAngularJs

Abraços. 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.

Passo 2

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

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:

É 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):

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.

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

Se tiver local:

http://localhost:8080/jenkins/restart

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

Simples, não?

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:

O nome do projeto foi omitido.

Configurando o Job

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.

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 :

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.

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:

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:

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

E preencha:

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:

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:

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