Mais recentes

Conteúdo técnico, ferramentas e experiências práticas da IceNex.

Mostrando postagens com marcador devops. Mostrar todas as postagens
Mostrando postagens com marcador devops. Mostrar todas as postagens

quinta-feira, 25 de julho de 2024

A Importância da Automação de Testes em Projetos de Software

E aí pessoal, tudo bem?

A qualidade do software é um fator crucial para o sucesso de qualquer projeto de desenvolvimento. Com a crescente complexidade dos sistemas e a necessidade de entregas rápidas, garantir que o software funcione corretamente em todas as fases do ciclo de desenvolvimento tornou-se um grande desafio. É aqui que a automação de testes se torna essencial. Neste post, vamos explorar o conceito de automação de testes, seus benefícios e como ela pode transformar a maneira como desenvolvemos software.

O que é Automação de Testes?

Automação de testes é o uso de ferramentas e scripts para executar testes de software automaticamente. Isso inclui a criação de testes, a execução dos testes, a comparação dos resultados com os esperados e a geração de relatórios. A automação pode ser aplicada a diferentes tipos de testes, como testes unitários, de integração, de sistema, de aceitação e de regressão.

Benefícios da Automação de Testes

  1. Velocidade e Eficiência

    • Os testes automatizados são significativamente mais rápidos do que os testes manuais, permitindo que você execute testes repetidamente com alta eficiência.
  2. Cobertura de Testes Ampliada

    • A automação permite a execução de um grande número de casos de teste, cobrindo uma gama maior de cenários e aumentando a confiabilidade do software.
  3. Detecção Precoce de Defeitos

    • Com testes automáticos integrados ao pipeline de integração contínua, os defeitos são detectados mais cedo no ciclo de desenvolvimento, reduzindo os custos e o tempo de correção.
  4. Consistência e Reprodutibilidade

    • Testes automatizados garantem que os testes sejam executados de maneira consistente e reprodutível, eliminando a variabilidade dos testes manuais.
  5. Feedback Rápido

    • A automação fornece feedback imediato aos desenvolvedores, permitindo que eles identifiquem e corrijam problemas rapidamente.

Como Implementar Automação de Testes

  1. Escolha das Ferramentas

    • Selecione ferramentas de automação de testes que atendam às necessidades do seu projeto. Algumas opções populares incluem Selenium, JUnit, TestNG, e Cypress.
  2. Definição da Estratégia de Testes

    • Determine quais testes devem ser automatizados e crie uma estratégia que inclua testes unitários, de integração, de sistema e de regressão.
  3. Escrita de Scripts de Teste

    • Desenvolva scripts de teste que cobrem as funcionalidades críticas do seu software. Certifique-se de que os scripts sejam bem documentados e fáceis de manter.
  4. Integração Contínua

    • Integre seus testes automatizados com ferramentas de integração contínua (CI) como Jenkins, Travis CI ou GitHub Actions para garantir a execução automática dos testes a cada mudança no código.
  5. Monitoramento e Manutenção

    • Monitore os resultados dos testes e mantenha seus scripts de teste atualizados para refletir quaisquer mudanças no software.

Aqui vai um exemplo, de como ficaria um pipeline de integração contínua, testes e entrega contínua:

Pipeline - Integração e Entrega Contínua

Considerações Finais

A automação de testes é uma prática fundamental para garantir a qualidade do software em projetos modernos. Ao investir em automação, as equipes de desenvolvimento podem aumentar a eficiência, melhorar a cobertura de testes e fornecer um software mais robusto e confiável. Lembre-se de que a automação não elimina a necessidade de testes manuais, mas complementa-os, permitindo que os testers se concentrem em áreas que exigem atenção humana.

Até a próxima.

Abs
:wq!

domingo, 21 de março de 2021

Jenkins - Pipeline para subir uma aplicação Java

Fala pessoal, beleza?

Espero que estejam todos bem!

Conforme meu post sobre Jenkins e pipeline para deploy de uma aplicação, vamos para segunda parte.

A primeira parte foi apenas para instalação e a segunda agora é para criação e uso de um pipeline.

Vamos definir pipeline como uma sequência de instruções que serão executadas até finalizar e prover uma entrega.

Nosso cenário será o seguinte:

  • Um servidor com o Jenkins instalado e configurado (feito no posto anterior)
  • Um servidor com linux instalado onde iremos subir um pacote de uma aplicação java que ao final do deploy nos dará uma ferramenta de monitoração
  • Chave SSH entre o servidor do Jenkins e o servidor onde a aplicação será instalada
  • Pipeline com as instruções para cada passo que iremos definir no processo de deploy (cópia de arquivos, descompactação, ajuste de parâmetros, criação de serviços, start

Uma observação importante: Eu não sou um expert e nem estou falando que este modelo de pipeline que estou propondo é o melhor e que não podemos fazer de outra forma. Essa foi uma forma que achei para ajudar em uma necessidade do meu dia-a-dia, OK? Cada um deve avaliar a melhor forma de usar a estrutura de funcionalidade e adaptar para o seu uso.

Agora vamos a criação do pipeline na console do Jenkins. 

Para isso clicar em New Job - Insira um nome - Clique em pipeline - OK


Agora irá abrir uma nova tela de configuração onde podemos colocar um comentário para documentarmos melhor o pipeline, algumas opções via checkbox para não termos deploys concorrentes, usar po Git, etc.

No nosso caso, não iremos marcar nenhuma opção. Vamos direto no campo pipeline e inserir a estrutura abaixo:

pipeline {
    agent none
    environment {
            IP = "xx.xx.xx.xx"
    }
    stages {
        stage ('Copia o pacote da aplicacao para o servidor') {
            agent any
           
            steps {
                sh '''#!/bin/bash
                scp /home/jenkins/repoapp/mon-java.tar.gz root@$IP:/opt
                '''
            }
        }
        stage ('SSH + desccompacta pacote do aplicacao') {
            agent any
            steps {
               sh '''#!/bin/bash
               ssh -o StrictHostKeyChecking=no root@$IP << EOF
               tar xzvf /opt/mon-java.tar.gz -C /opt
               exit
               EOF
               '''
            }
           
        }
        stage ('Adiciona usuario banco Postgres e muda permissao do data e tmp'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                useradd -m -d /opt/ManageEngine/OpManager/pgsql/ postgres
                chown -R postgres:postgres /opt/ManageEngine/OpManager/pgsql/tmp/
                chown -R postgres:postgres /opt/ManageEngine/OpManager/pgsql/data/
                exit
                EOF
                '''
            }
        }
        stage ('Cria o serviço e incia a aplicacao'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                cd /opt/ManageEngine/OpManager/bin/
                ./linkAsService.sh
                systemctl daemon-reload
                systemctl start OpManager.service
                exit 0
                EOF
                '''
            }
        }
        stage ('Alguns tunings na aplicacao'){
            agent any
            steps {
                sh '''#!/bin/bash
                ssh -o StrictHostKeyChecking=no root@$IP << EOF
                sed -i 's/wrapper.java.initmemory=512/wrapper.java.initmemory=600/g' /opt/ManageEngine/OpManager/conf/wrapper.conf
                sed -i 's/wrapper.java.maxmemory=1024/wrapper.java.maxmemory=1500/g' /opt/ManageEngine/OpManager/conf/wrapper.conf
                sed -i 's/24MB/1024MB/g' /opt/ManageEngine/OpManager/pgsql/data/postgres_ext.conf
                sleep 4m
                exit
                EOF
                '''
            }
        }
 }
}

Vejam que temos uma variável neste pipeline: IP = "xx.xx.xx.xx"
Trabalhar com variáveis torna o nosso pipeline mais preciso, pois em qualquer ponto necessário iremos declarar apenas a variável e seu conteúdo pode sofrer alterações que será replicado para todos. =)
Vale o mesmo conceito adotado em programação...

O IP da nossa máquina de aplicação neste exemplo é: 192.168.100.109, então devemos colocar este IP na variável.

Agora vamos no servidor do Jenkins, na shell do user Jenkins copiar nossa chave SSH para o servidor de aplicação:


Com isso, ao tentar acessar SSH o servidor destino através do shell do usuário Jenkins, não será solicitado senha (por que no meu exemplo foi configurado dessa forma). Se você colocar senha em sua chave, será necessário criar um mecanimos para essa senha seja digitada automaticamente no pipeline. 

** Importante **

A questão de ter que fazer o passo da chave SSH pode ser resolvido se no seu processo de deploy ou criação do ambiente (máquina virtual, instância, físico não importa) se você já adicionar a chave SSH do usuário Jenkins =)

Bem, agora na console do Jenkins vamos  clicar no pipeline que criamos e na opção Build Now, para o processo começar.

O legal é que para cada passo que criamos dentro do pipeline, ele irá gerar uma saída com a identificação, e caso necessário um log da execução.



Ao término, dando tudo certo, o pipeline ficar tudo "azul" indicando que todos os passos concluíram com sucesso.
Caso algum item apresente erro, teremos uma indicação na cor vermelha e com um breve log do possível erro para tratarmos.


Legal também é que temos o tempo que cada step demorou em sua execução completa.

Agora validando no servidor de aplicação, devemos ter nossa ferramenta de monitoração instalada, configurada com os tunings que fizemos, os serviços criados, etc. Sendo que no nosso caso basta apenas acessar a URL e autenticar para ver se ela encontra-se disponível para uso.





A ideia deste pipeline é para uma execução bem simples, mas que automatiza uma tarefa que poderia demorar fazendo tudo de forma manual, nos dando maior possibilidade de erros humanos, cada um fazendo um deploy de um jeito diferente, etc.

Lembre-se que existe uma infinidade de possibilidades de configuração e cenários para uso. Com issa ideia "base" espero que vocês possam adequar so seu modelo de uso e assim tornar tarefas corriqueiras automatizadas da melhor forma possível.

Por hoje é isso!
Abs e até a próxima.
:wq!

sábado, 19 de dezembro de 2020

Jenkins - Instalação no Debian

Fala galera, beleza?

Espero que tudo bem ...

Hoje muito se fala de automação, entraga de forma automatizada, DevOps, etc.

Bem, pensando nisso eu resolvi fazer dois posts, sendo o primeiro com o passo-a-passo de instalação de Jenkins no Debian (já vou começar a fazer os labs no Debian, visto que o projeto do CentOS está chegando ao fim) e o segundo post com um exemplo de um pipeline para automatizar a entrega de uma ferramenta de monitoração, algumas customizações do SO, criação de serviço e start.




Primeiramente ... O que é Jenkins?

- Nada mais é do que um servidor/serviço de automação gratuito muito utilizado hoje em dia em esteiras DevOps para entrega contínua.

Para saber mais sobre o projeto, basta acessar o site oficial: https://www.jenkins.io/

Laboratório utilizado:

  • VirtualBox
  • Debian na versão 10.7
  • Jenkins instalado via repo
Tendo você já o Debian instalado, vamos fazer o update e instalar o default JDK necessário para o correto funcionando do Jenkins:

Para o update:

# apt-get update

Para instalar o Default JDK:
# apt-get install default-jdk

Será solicitado seu OK para confirmar a instalação ... Caso queira fazer tudo de forma direta é só colocar o parâmetro -y no comando acima?

Agora precisamos baixar e aplicar a GPG Security key.

Isso se faz necessário para autenticar/validar o software que instalamos. É mais para informar que o software que queremos instalar é confiável.

Vamos ao download do GPG...

# wget –q –O – https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add –

Dando tudo certo iremos receber um OK ao final da execução do comando:

** colocar o print **

Com o comando abaixo iremos adicionar o repo do Jenkins no Debian para podermos fazer a instalação através do apt-get instal também:
# sh –c ‘echo deb https://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list’
Obs.: este repo é para quem usa a versão stable do Debian, OK?

Caso você utilize outra versão é necessário adicionar o seguinte repo: sh -c 'echo deb https://pkg.jenkins.io/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

Agora que já temos o java default, as keys de validação e o repo adicionado, vamos fazer a instalação do Jenkins:
# apt-get update && apt-get install jenkins
Novamente será solicitado o seu OK para realizar a instalação ... caso queria pular este passo é só colocar o -y no apt-get install jenkins -y

A instalação finalizando com sucesso, vamos fazer o start do serviço e já habilitá-lo para start automático durate a inicialização do servidor.
# systemctl start jenkins ; systemctl enable jenkins

É necessário agora finalizar a configuração do Jenkins através da console Web:

Acessar a console no próprio servidor (http://localhost:8080) ou acessar de forma remota (http://ip_do_server:8080). É normal demorar um pouco até o start completo e com isso aparecer o seguinte status:




Será solicitado que você capture a senha criada na instalação para continuar:
# cat /var/lib/jenkins/secrets/initialAdminPassword

Na tela seguinte selecionar para que seja feita a instalação dos plugins sugeridos...



No passo seguinte criar o usuário que será utilizado para administrar e configurar/usar o Jenkins daqui pra frente...




Assim que finalizar é só fazer o teste acessando o Jenkins com o usuário e senha definidos na instalação.




Agora está tudo pronto para o próximo post, onde iremos criar um cenário para fazermos um pipeline do deploy de uma ferramenta de monitoração, alguns ajustes, tunings, etc.

Abs e até a próxima galera!
:wq!

quarta-feira, 25 de dezembro de 2019

Feliz Natal =)


Mais um natal...

E o blog MarinhoTI deseja à todos um feliz natal e obrigado pelo presente de estarmos mais um natal juntos!

:wq!

domingo, 17 de novembro de 2019

Monit - Monitoração pró-ativa de processos e serviços

Bom dia pessoal, tudo bem?

Recentemente conheci uma excelente ferramenta para nosso dia-a-dia. Além de ter a função de monitoração essa ferramenta também possui por assim dizer uma automação por asssim dizer para restabelecimento de serviços dentro do SO.

A ferramenta em questão é o Monit.



Resumindo o escopo dela: Monitoração pró-ativa de processos e programas.

Nos dias de hoje, sabemos o quanto as empresas valorizam e cobram cada vez mais por ambientes com mais autonomia, procedimentos automatizados e claro, monitoração efetiva.

Agora vamos ao procedimento de instalação e alguns exemplos de monitoração e ação de correção com o Monit.

Instalação

Para distribuições baseadas em RedHat o pacote pode ser instalado através do repo EPEL:

# yum install epel-release
# yum install monit

Para distribuições baseadas em Debian, basta apenas instalar:

# apt-get install monit

Em meu lab estou utilizando o CentOS 7, com isso vou passar os passados para utilizar essa distro.

Iniciando e habilitando o serviço do Monit

# systemctl start monit
# systemctl enable monit

O arquivo de configuração do Monit encontra-se no path abaixo:

/etc/monitrc

Cenário de testes

Para fazermos os testes e demonstrar as funcionalidades, eu criei uma máquina virtual com CentOS 7 e os seguintes serviços instalados:

- WebServer Apache: Serviço respondendo na porta padrão http - tcp/80
- Banco de Dados MariaDB: Serviço respondendo na porta padrão também tcp/3306

Obs.: Ambos os serviços estão apenas instalados e iniciados, sem nenhuma configuração.

O segundo servidor também com CentOS 7 e apenas com o serviço do Monit instalado.
- Monit: Ferramenta de monitoração pró-ativa respondendo na porta 2812

Endereços IP

Monit: 10.0.0.5
App: 10.0.0.4

Exemplo de monitoração com Monit

Abaixo está a sintaxe que deve ser utilizada para monitorar processos em servidores remotos. Para o funcionamento sem a necessidade de autenticação, eu criei chaves ssh para que o servidor do Monit possa chegar no servidor de Aplicação sem necessidade de passar autenticação.

check host host.domain.name with address ip.addy.here.ip
start program = "/usr/bin/ssh user@ipaddress /etc/init.d/servico start"
stop program = "/usr/bin/ssh user@ipaddress /etc/init.d/servico stop"
if failed port 6757
then restart


No exemplo a primeira linha devemos cadastrar o nome FQDN do servidor e seu respectivo IP, as duas linhas seguintes responsáveis pelo comando de start e stop da aplicação/processo que será monitorado e em caso de falha a ação de restart.

Vale uma observação quanto a monitoração do processo SSH de forma remota, caso o serviço fique indisponível seja por queda ou por algum bloqueio no servidor destino o Monit não conseguirá intervir para tentar fazer o start do serviço, mas pode servir para alarmar e notificar. OK?

Uma dica...

Ao informarmos o hostname do servidor no formato FQDN, caso não utizemos tudo por DNS podemos criar entradas na configuração do Monit contendo o nome do servidor + o serviço ao qual estamos monitorando.

Exemplo:

server-app1-apache
server-db01-mongodb

Assim teremos uma view mais rápida e fácil de qual serviço corresponde a monitoração.

Segue o trecho de configuração do arquivo monitrc com as entradas criadas para monitorar o Apache e o MariaDB:



Na console Web do Monit, fica assim:



Caso o serviço/processo monitorado fique indisponível, o Monit tentará fazer o start novamente utilizando o comando inserido na configuração.

No próprio arquivo de configuração temos algumas linhas com exemplo de configuração, no site do Monit também... isso ajuda muito pois podemos ter variações de configuração dependendo da versão.

Site do Projeto para quem queira conhecer mais: https://mmonit.com/monit/

Até a próxima.
:wq!