Vamos aprender a utilizar o Ansible:

Uma visão geral da estrutura de pastas do Ansible:

Inventory:

Na pasta hosts definimos o inventário das nossas máquinas que serão executados os playbooks (já veremos o que isso significa), no exemplo abaixo, temos um inventário chamado de blog-server, que contém apenas uma máquina inventariada.

Poderíamos ter outros inventários no mesmo arquivo ou outras máquinas inventariadas. Bastaria adicionar o endereço, login e senha dos outros servidores.

Ansible.cfg:

No arquivo ansible.cfg definimos qual será o inventário padrão e ignoramos a pergunta relacionada ao desejo de adicionar o IP da máquina ao arquivo known_hosts.

Playbooks:

Podemos dizer que um playbook é uma receita, onde é definido o que será provisionado nos nossos inventários. Fazendo uma analogia, seria um passo a passo para uma receita de bolo.

Nesse exemplo temos 3 passos a serem executadas, config-basic, docker, start-services. É importante dizer que esses passos são executados sequencialmente. Abaixo veremos o que cada um deles faz:

Roles:

Na pasta roles temos o seguinte formato:

Roles
  config-basic
    files
    tasks
  docker
    files
    tasks
  start-services
    files
    tasks

Dentro de cada role, existe a pasta files, onde ficam os arquivos que serão utilizados para configurar algo no provisionamento do ambiente. Dentro da pasta tasks ficam as tarefas que serão executadas para provisionar o ambiente desejado. Por padrão o Ansible sempre procura dentro da pasta tasks um arquivo main.yml.

config-basic:

Abaixo temos o nosso arquivo main.yml com tarefas para configurar: timezone, language, criação de um usuário, adicionar o usuário no grupo de sudo e instala o unzip na máquina provisionada.

Docker:

Dentro da pasta files temos um arquivo do docker-compose.yml para subir o blog que desejamos na máquina provisionada.

Dentro da pasta tasks temos uma tarefa para adicionar o arquivo docker-compose.yml para dentro da home do usuário.

Agora tempos a tarefa para instalar o Docker na máquina que irá ser provisionada.

Próxima tarefa é para instalar o docker-compose na máquina provisionada.

Agora o arquivo main.yml tem apenas os imports das tarefas que estão na mesma role, dessa forma, fica mais organizado do que adicionar todas as tarefas no mesmo arquivo.

Start-services: E por último, vamos executar o comando para "startar" o serviço com o docker-compose.

Para provisionar uma máquina e rodar o blog com o Ghost, basta executar o comando:

ansible-playbook blog-server.yml

Ao executar este comando será apresentada a imagem abaixo, quando finalizar o provisionamento do nosso blog.

Ao acessar a máquina que provisionamos, podemos ver o nosso blog em execução, pronto para configurarmos.

É isso pessoal, espero que tenham gostado desse post. Até o próximo.

Referencias

http://docs.ansible.com/ansible/playbooksbestpractices.html https://www.ansible.com/

É necessário ter configurado:

• Android SDK
• Node
• Appium
• Java JDK
• Genymotion

Vamos começar

A aplicação que iremos testar é simples, ela faz o controle de abastecimentos realizados no mês.

Vamos utilizar o Maven e como vimos no post anterior, para isso devemos ter o arquivo pom.xml com nossas dependências.

Criaremos agora nossa classe base para os demais testes:

Então iremos criar nossas pages:

Agora basta criar os testes que utilizarão as pages criadas:

Temos nossos testes funcionando, mas para serem executados ainda precisamos executá-los de forma manual. É nessa hora que o Jenkins vai nos ajudar a executá-los e deixando-nos livres de realizar esse trabalho manual.

Devices (Dispositivos)

Nem sempre temos nossos targets (dispositivos) "plugados" em nosso servidor de integração contínua, nesse caso, irei utilizar o Genymotion para simular um device com a API 22 do Android.

Para adiantar nosso trabalho no Jenkins, vamos executar o seguinte comando no terminal:

| VBoxManage list vms

O resultado da execução desse comando, são os nomes das VM's que possuímos em nossa máquina, no meu caso lista a seguinte VM:

| "Google Nexus 5 - API 22" {1483f101-24a2-45c9-87f2-043de64ca883}

Configurando o Jenkins

Criaremos o nosso projeto no Jenkins.

Agora basta configurar o repositório do projeto, no exemplo, estou utilizando um projeto que está no github.

Vamos configurar para "startar" o emulador do gennymotion.

| /mnt/rafael/desenvolvimento/genymotion/player --vm-name "Google Nexus 5 - API 22"

O comando abre o emulador do Gennymotion, porém tenho que esperar alguns segundos para iniciar a execução dos testes.

OBS.: Caso tenha um dispositivo conectado não é necessário o passo acima.

Configuraremos o Maven com clean e install para executar nossos testes e mandaremos construir nosso build, com isso, finalmente teremos nossos testes automatizados sendo executados pelo Jenkins.

Aqui termino a série de posts sobre Deixando o Jenkins fazer o trabalho manual. Espero que tenham gostado e que o conteúdo dos posts tenham servido para agregar conhecimento e disseminar a troca de informações. Até breve pessoal!

O exemplo no qual irei demonstrar a utilização do Selenium é bem simples, utilizarei o padrão Page Objects juntamente com Java e Maven.

Exemplo: Iremos lançar notas de um Aluno e verificar se o mesmo foi Aprovado, Reprovado ou está em Prova final.

Vamos começar a configurar nossos testes:

Criaremos um projeto Maven e configuraremos o pom.xml.

Agora criaremos uma classe WebDriverFactory.java para criar novos drivers do Selenium, no exemplo vou utilizar apenas o Chrome.

Depois criaremos uma classe chamada de BaseTestes.java.

Analisando a página para lançamento de notas, iremos criar a classe PageLancamentoNotas.java, mapeando os seguintes métodos para os testes da página.

Agora implementaremos os métodos da nossa page.

Agora é a hora de criar os testes.

Neste momento estamos com todos os testes implementados, mas não colocamos nosso "best friend" Jenkins para fazer nosso trabalho manual, para isso, vamos configurar agora o nosso projeto no Jenkins.

Depois vamos configurar no Jenkins um repositório no github para fazer o clone e executar os testes. Lembre-se que no meu caso, a aplicação está executando localhost.

Feito essa configuração é só mandar executar o build.

Podemos configurar para mostrar o resultado dos testes no build.
Feito isto, teremos o resultado da execução dos testes.

Clicando sobre o Test Result Trend, iremos para uma tela onde mostra: Pacote do projeto > Pacote de testes > Classe de teste > Execução dos testes.

Espero que tenham gostado. No próximo post dando continuidade a série, iremos falar de testes mobile utilizando Appium. Até a próxima. Para conferir o código completo do exemplo.

Para não fugir do assunto da série, vamos voltar ao primeiro passo: Aprender a como provisionar (instalar/configurar) o Jenkins. Neste post aprenderemos a fazer este primeiro passo usando Vagrant e logo depois com Docker.

Quando comecei a utilizar ferramentas para provisionamento de ambientes, fazia muita confusão na utilização do Vagrant e Docker. Aprofundando os estudos vi que para criar uma imagem personalizada com Vagrant tinha que utilizar uma ferramenta de provisionamento e a que mais vi exemplos foi o Puppet. Ao estudar Docker, pude observar que com um arquivo dockerfile eu teria uma ferramenta que faz tudo que o Vagrant e Puppet faz. A grosso modo, podemos dizer que sim, só que o Vagrant é a ferramenta para criar a "máquina", que pode utilizar vários provedores de máquinas virtuais (VMWare, VirtualBox entre outros) e para personalizar essa máquina, pode ser utilizada diversas ferramentas (Puppet, Docker, Ansible, Shell Script, Chef entre outras).

Minha primeira tentativa foi provisionar uma máquina utilizando shell script, bom funcionou! Mas manter o script de provisionamento com shell script não tem uma boa legibilidade, então vi que era possível provisionar com Ansible (esta ferramenta está no backlog de posts) e ficou muito mais simples manter o script de provisionamento. Agora vamos arregaçar as mangas e por a mão na massa e mostrar a diferença da utilização das ferramentas.

Vagrant

Executaremos a sequência de passos abaixo:

|Primeiro passo:

vagrant init [box-name]

Para conseguir o nome dos box basta acessar a URL.

Irei mostrar o exemplo com o box ubuntu/trusty64. Comando que será executado:
|vagrant init ubuntu/trusty64

Feito isso, será criado um arquivo Vagrantfile como mostra a imagem abaixo:

Ao abrir o Vagrantfile, podemos observar que é adicionado o comando de configuração de qual box será utilizado para provisionar a máquina.

| Segundo passo:

Adicionar quanto de memória terá nossa máquina, isso mesmo, ao utilizar o Vagrant deixamos reservado uma quantidade fixa de memória.

| Terceiro passo:

Adicionar qual ferramenta será utilizada para fazer o provisionamento, neste exemplo, para deixá-lo mais simples irei utilizar shell script.

| Quarto passo:

Adicionar os comandos para provisionar, no nosso caso, os comandos para provisionar o Jenkins.

|Quinto passo:

Antes de executar o comando para provisionar a máquina, vamos adicionar alguns TLGs (Toques de leveza e graciosidade).

Adicionei um nome para o host name, o nome da máquina no Virtual Box e adicionei a porta 8080 para fazer o bind e acessar o Jenkins como localhost:8080.

Agora vamos executar o comando para subir e provisionar a máquina com o Jenkins.

|vagrant up --provider virtualbox

Esta será a saída do resultado da execução do comando acima.

Feito isso temos nosso Jenkins provisionado pelo Vagrant.

Docker

Agora para provisionar o Jenkins com o Docker seguiremos os passos abaixo:

| docker run -d --name jenkins-desafio -p 8082:8080 jenkins

Neste comando o container irá rodar em background utilizando o -d. A porta que será feito o bind com o container é a 8082.

Você deve está pensando: Com o Docker é muito mais simples! E eu lhe respondo que sim, mas apesar das ferramentas fazerem a mesma coisa, são utilizadas com propósitos diferentes. Podemos usá-las em conjunto, o Vagrant cria a máquina e a personalização fica por conta do Docker. A principal diferença nas ferramentas:

Docker

• Compartilha os recursos da máquina (memória, disco e etc), mas não reservado;
• Containers são mais leves, já que não precisam de um ambiente virtual completo;
• Inicialização muito rápida.

Vagrant

• Traz todo o sistema operacional;
• Traz usuários do sistema operacional;
• Compartilha os recursos da máquina (memória, disco e etc), mas reservados, mesmo quando não utilizado.

Concluindo…

Quando precisamos isolar nossa aplicação do sistema operacional, a melhor opção na minha opinião é utilizar o Vagrant. Caso contrário, usar Docker para provisionar sua aplicação antes de executar seus testes automatizados não faz mal a ninguém :). Espero que tenham gostado e não se esqueçam, seus comentários são sempre bem vindos, até breve!

Vamos dividir em passos:

Primeiro passo:

Criaremos nossas requisições para a execução do teste de performance. Para a utilização, vou mostrar um simples exemplo em uma API chamada "Academico", que foi desenvolvida por mim e com ajuda de um membro do meu time: Diego Coronel :). Essa API é bem simples: Cadastra alunos, Disciplinas, Professores, Realiza matrícula de alunos e Atribui professor para as disciplinas. Vamos por a mão na massa.

Criamos uma requisição simples, passando um objeto que contém Nome, Carga Horária, Horário e Período da disciplina. Adicionamos um Gerenciador de cabeçalho "http" para adicionar o Content-Type: application/json.

Segundo passo:

Criaremos as demais requisições e adicionamos ouvintes(relatórios) e asserts para verificar o status da requisição e o retorno da requisição.

Terceiro passo:

Agora adicionamos a quantidade de usuários virtuais e o tempo de intervalo entre cada requisição. Definir nesse momento um valor qualquer, pois como é uma API simples e para testes, não tenho requisitos não funcionais :).

Quarto passo:

Agora chegamos na parte em que executamos os testes de performance e coletamos os resultados.

Até esse momento fizemos um passo a passo simples para executar os testes de performance em uma API, porém foram feitas várias alterações na API para adicionar a parte do histórico do aluno para lançar notas e verificar se o aluno está aprovado, reprovado ou em prova final.
Preciso rodar os testes de performance mais uma vez, manual. E se ao invés de rodar os testes de forma manual, colocássemos o Jenkins para fazer esse trabalho?
Vamos ver como colocar o nosso amigo Jenkins para fazer esse trabalho.

Primeiro passo é adicionar o plugin performance

Depois de instalarmos o plugin criaremos um novo projeto no Jenkins.

Criaremos um projeto freestyle, e adicionaremos as configurações para a execução dos testes de performance pelo Jenkins.

Iremos configurar agora os testes para ser executado pelo Jenkins.

Configuramos o caminho de onde está o JMeter e o nosso arquivo .jmx (criado na suíte do JMeter).

Definimos onde está o arquivo .jtl (resultado de execução dos testes do JMeter)

Precisamos definir limites de erros para nosso build falhar ou ficar instável. No exemplo coloquei -1, ou seja qualquer erro que apresentar nos testes o build irá falhar.

Executar o build do projeto

Podemos observar os gráficos ao abrir o projeto no Jenkins, neste exemplo, não temos nenhum erro nas requisições. Podemos ver melhor os gráficos clicando sobre eles.

Nesses gráficos é possível observar que o "Adicionar Alunos" está com o tempo de resposta de 200ms. A cada build gerado no Jenkins é possível verificar esses gráficos de performance do projeto.

Agora podemos agendar a execução dos testes:

Os testes serão executados todos os dias às 22:30, essa foi a configuração definida, mas é possível fazer outras configurações como por exemplo:

# todo minuto
* * * * *
# no minuto 5 de cada hora (ou seja '2:05,3:05,...') 
5 * * * *

Espero que tenham gostado do post, como vimos é simples colocar o nosso amigo Jenkins para fazer o trabalho manual. Até o próximo post onde falarei sobre a execução de testes web com o Selenium no Jenkins.

A ideia deste post é falar um pouco mais de Docker e algumas coisas que podem ser feitas além do "hello world".
Quando comecei a usar Docker apenas tinha em mente ter uma aplicação rodando em background e pronto, tela preta e um serviço rodando (postgres, wildfly e outros). Descobrir que Docker vai além disso é muito interessante e instigante, dá para fazer muitas coisas bem legais.
Esses dias queria fazer uma api em php utilizando o Slim Framework, porém tinha que instalar todo o ambiente na minha máquina para desenvolvê-la. Será que isso vale a pena, quando somente pretende-se "brincar" com um framework? Bom, acredito que não, então o que fiz:

web:
  image: tutum/apache-php
  hostname: web
  links:
   - mysql
  ports:
   - 80:80
  volumes:
   - .:/app

mysql:
  image: mysql
  hostname: mysql
  environment:
   - MYSQL_ROOT_PASSWORD=root 

Nessa parte é feito o link do container apache-php com o container do mysql.

links:
 - mysql

Aqui está sendo feito a parte mais importante desse docker-compose,

volumes:
 - .:/app

Esse volume basicamente serve para mapear um diretório no local onde está sendo executado o docker-compose com a pasta app do container. Ao criar um arquivo nessa pasta, será adicionado ao apache, com isso não é preciso configurar todo o ambiente do php para conseguir "brincar" com o Slim Framework, isso possibilita fazer inúmeras coisas como: compartilhar entre a máquina e o container, .jar, .war, .js, .html e etc.
Outra funcionalidade muito importante do volume é fazer backup de dados, como por exemplo: criar um volume com o banco de dados do postgres e toda vez que subir um container do postgres, apontar para o volume criado, com isso não seria perdido os dados do banco de dados, às vezes isso é bem útil, ainda mais quando utilizado docker em produção :).

Mas você deve está se perguntando: - Ainda é uma interface preta que está apenas rodando um serviço! Então vamos ver uma coisa legal :).

E se agora eu não tivesse mais interesse em instalar o Google chrome na minha máquina, então bastaria executar o seguinte comando:

docker run -it --net host --cpuset-cpus 0  -m 512mb -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=unix$DISPLAY -v /dev/snd:/dev/snd --privileged --name chrome jess/chrome

E com isso temos:

É possível compartilhar placa de som, USB e etc com um container, isso possibilita fazer muitas coisas, por exemplo: não precisar instalar o ambiente do Android na máquina, para executar testes em app Android, mas isso fica para um próximo post! Até breve.

Para subir o grid:

java -jar selenium-server-standalone-2.48.2.jar -role hub

Para subir o node:

java -jar selenium-server-standalone-2.48.2.jar -role node  -hub http://localhost:4444/grid/register

É possível fazer isso de forma mais simples utilizando Docker. A própria comunidade do Selenium mantém as images Docker com o hub, Firefox e Chrome nodes. Vamos começar a criar nosso grid utilizando Docker.

Subindo nosso hub:

$ docker run -d -P --name selenium-hub selenium/hub:2.48.2

Subindo nossos nodes:

  $ docker run -d --link selenium-hub:hub selenium/node-chrome:2.48.2
  $ docker run -d --link selenium-hub:hub selenium/node-firefox:2.48.2

Agora se precisarmos criar outros nodes, precisaríamos criar novos containers:

  $ docker run -d --link selenium-hub:hub selenium/node-firefox:2.48.2

O trabalho ainda está bem manual. É possível deixar este processo ainda mais simples utilizando o docker-compose. Abaixo exemplo do docker-compose para criar nosso grid.

Criando o grid com docker-compose:

hub:
  image: selenium/hub:2.48.2
  hostname: selenium-hub
  ports:
   - 4444:4444

chrome:
  image: selenium/node-chrome:2.48.2
  links:
   - hub

firefox:
  image: selenium/node-firefox:2.48.2
  links:
   - hub

Basta executar o comando:

docker-compose up -d

Para criar novos nodes execute o comando:

docker-compose scale hub=1 chrome=3 firefox=3

Colocando a quantidade desejada para cada node.

A proposta deste post é mostrar como a utilização de especificação de cenários em features utilizando a técnica de BDD, pode deixar nossos casos de testes “vivos”, para conseguir mantê-los atualizados com mais facilidade.

A proposta é escrever um caso de testes no seguinte formato:

Mas você deve está se perguntando: Vou transformar BDD em casos de testes?

A proposta é: Transformar os casos de testes automatizáveis em cenários e não fazer de uma feature um amontoado de "casos de testes", com milhares de combinações. O que eu quero dizer com isto é:

Se tenho a seguinte tela:

Login:

Senha:

Não vou fazer os cenários:

• Logar na aplicação;
• Nome de usuário inválido;
• Senha de usuário inválida;
• Deixar campo “Nome” e “Senha” em branco;
• Colocar caracteres especiais nos campos “Nome” e “Senha”; Etc.

Se terei uma funcionalidade “Cadastrar pessoa” e para cadastrar uma pessoa terei que logar na aplicação, então não preciso ficar fazendo milhares de combinações na Tela de login, afinal, isso não vai gerar valor de negócio ao cliente, ninguém desenvolve somente uma Tela de login para um cliente.

Agora vendo o cenário abaixo:

Qual ganho teríamos colocando os casos de testes em features ao invés de criá-los no Testlink?

Ao optar por escrever um cenário em uma feature este deve ser automatizado, caso não seja, praticamente não terá ganho algum em relação aos casos de testes criados no Testlink. Ao adicionar esses cenários automatizados no pipeline do servidor de integração contínua, toda vez que seus testes falharem, eles irão impedir a geração de uma nova release e com isso obrigatoriamente os cenários terão que ser atualizados. Vale lembrar que a automação dos cenários de uma feature deve utilizar boas práticas de desenvolvimento, nada de:

Thread.sleep(1000);

Afinal, se seu teste por algum motivo demorar 2 segundos, não quer dizer que sua funcionalidade quebrou, pode ser um indicador que seus testes talvez não estejam bons. Em um outro momento, farei um outro post relacionado a como configurar o ambiente e como executar os testes no servidor de integração contínua.