DEV Community: Nathally Souza

Utilizando o Docker para potencializar Github Actions

Nathally Souza — Wed, 01 Mar 2023 12:42:53 +0000

PARTE 1 Construindo uma pipeline com o Github Actions

Anteriormente mostrei como podemos construir uma pipeline com Github Actions e até compartilhei uma simplificada para demonstrar o funcionamento. Agora vamos aprofundar um pouco mais e entender como podemos rodar uma instância do Docker com as actions para aumentar a cobertura dos nossos testes.

Antes de entender a implementação, vale a pergunta: porque ter um container nas actions? Não vou aprofundar sobre o uso de container, mas nesse caso, ele permite que implementamos um banco local, que será o nosso database para rodar os nossos testes integrados ou e2e, sem a necessidade de conexão com um banco remoto, além de podermos utilizar filas locais, como o RabbitMQ ou Kafka, por exemplo. Somente nesse ponto, já ganhamos performance para a execução dos nossos testes.

Agora podemos partir para a implementação. Primeiro precisamos criar um arquivo docker-compose.yml, que será onde colocaremos as instruções para montar nossa imagem. No nosso exemplo utilizaremos o Postgres como banco de dados. Para isso, no nosso arquivo, especificamos qual imagem iremos utilizar e já configuramos as variáveis de ambiente, como nome de usuário e senha para acesso ao banco.

Ainda na configuração do docker, finalizamos especificando o nome de uma rede local para utilizarmos.

version: "3.6"

services:
  postgres:
    image: postgres:11.7-alpine
    ports:
      - 5432:5432
    environment:
      POSTGRES_PASSWORD: admin
      POSTGRES_PASSWORD: password
networks:
  default:
    external:
      name: my-network

Feito essa configuração passamos ao nosso workflow para inserir as novas configurações na execução dos testes. Para isso, precisamos de três comandos do docker.

Essa sequência irá criar a rede local para a execução da nossa instância, posteriormente buildar nossa imagem do docker e por fim apenas exibir os dados da rede que está disponível. Pronto, dessa forma temos uma instância com banco de dados pronta para ser utilizada por nossa aplicação.

    - name: Creating network
      run: docker network create "microservice-network"

    - name: Build docker-composer
      run: docker-compose up -d

    - name: Check running container
      run: docker ps -a

Caso necessário, você pode executar migrations com dados de testes e povoar o banco com as informações para executar os seus testes e rodá-los em sua pipeline. Dessa forma, em menos de 5 minutos, temos um container pronto para nossa pipeline.

Construindo uma pipeline com o Github Actions

Nathally Souza — Mon, 13 Feb 2023 18:22:54 +0000

Que o Github é uma plataforma extremamente útil, todas nós sabemos, mas dentre uma de suas funcionalidades uma das que mais me fascina é o Github Actions. Com as Actions nós podemos construir uma pipeline para nossas aplicações desde as mais simples, até se precisarmos de uma complexidade maior com banco de dados.

Antes de mergulharmos nesse processo, é necessário entender o que é uma pipeline. Dentro do universo de desenvolvimento, uma pipeline é onde podemos visualizar as validações antes de entregar nossa aplicação em produção. É nessa etapa onde rodamos nossos testes automatizados para garantir que as alterações, que estão sendo enviadas para produção, não irão gerar nenhum erro.

Com este primeiro conceito, agora entra uma segunda etapa, uma pipeline bem configurada, permitindo que tenhamos um ambiente de stage, ou homologação, e o nosso ambiente de produção. A ideia é que no ambiente de stage sejam feitos testes manuais antes de enviar todas as mudanças para produção.

Quando qualquer erro é encontrado, a pipeline impede o deploy para qualquer um dos ambientes e é necessário que realizemos as correções antes do deploy. No exemplo abaixo temos o caso de uma pipeline que teve falha em uma das verificações dos testes unitários e bloqueou a mudança em stage.

No caso do exemplo exibido, é necessário fazer a correção na mensagem retornada para que as validações sejam feitas e o deploy possa seguir em cada um dos ambientes. Se tudo der certo, a aplicação será disponibilizada em todos os ambientes após os testes automatizados.

Neste cenário, temos a situação em que todas as validações passaram e conseguimos disponibilizar nossa aplicação no ambiente final. Depois desses conceitos, como podemos realizar todo esse processo usando o Github Actions?

No nosso exemplo temos uma aplicação simples com Nest, então usaremos as definições fornecidas pelo Github para aplicações com Node.

Na raiz do nosso projeto, criamos uma pasta .github, dentro dela um repositório workflow, onde colocaremos nosso
arquivo main.yml. É este arquivo yaml que será o responsável por definir quais são as etapas que serão percorridas em nossa pipeline.

No nosso exemplo o nosso arquivo yaml está da seguinte forma

name: Development

on:
  push:
    branches:
      - main
      - stage
  pull_request:
    branches:
      - main
      - stage

env:
  PORT: 5000

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

    - name: Run unit tests
      run: yarn test

  e2e:
    if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
    needs: [test]
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

    - name: Running e2e tests
      run: yarn test:e2e

  stage:
    if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
    needs: [test, e2e]
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

  deploy:
    if: ${{ always() && contains(join(needs.*.result, ','), 'success') && github.ref == 'refs/heads/main' }}
    needs: [test, e2e, stage]
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

Como usamos um arquivo yaml, precisamos nos atentar à indentação, que é uma das bases dessa linguagem. Feita essa observação, note que temos três conjuntos principais de instruções: on, env e jobs. Destas três, apenas on e jobs são obrigatórias, a env usamos apenas as nossas validações precisam de uma variável de ambiente. No nosso caso, definimos apenas uma porta para a aplicação rodar localmente durante o deploy.

O on é utilizado para definir quais serão os gatilhos da nossa pipeline, ou seja, quando executaremos essas verificações. No nosso caso definimos que sempre quando realizarmos um push ou pull requests nas branchs main e stage.

on:
  push:
    branches:
      - main
      - stage
  pull_request:
    branches:
      - main
      - stage

env:
  PORT: 5000

Agora vem a parte funcional da nossa pipeline. Dentro do jobs, definimos quais serão as ações executadas durante cada um dos processos. No nosso exemplo possuímos os dois primeiros jobs test e e2e, que estão configurados para rodar os testes automatizados.

Neste caso, antes de executar de fato cada etapa, definimos no runs-on e na strategy as configurações necessárias da nossa aplicação. No nosso caso, temos explicito que vamos usar um setup do Ubuntu lts e na sequência o Node na versão 16. Este ponto é específico de cada linguagem e necessita de consulta à documentação para saber qual a configuração ideal para sua aplicação.

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

    - name: Run unit tests
      run: yarn test

Ainda dentro dos jobs o segredo para impedir a execução da pipeline em caso de erro está no nosso if, que aparece a partir do e2e. Nesse caso, pedimos que sempre os testes tenham sucesso para somente após isso executar o próximo passo. Sem esse if, mesmo que ocorra um erro na etapa anterior, a pipeline seguirá todo o fluxo até produção, que não é nossa ideia.

stage:
    if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
    needs: [test, e2e]
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}

    - name: Install dependencies
      run: yarn --frozen-lockfile

Por fim, nos dois jobs finais, em stage e deploy, é quando realizamos a entrega da nossa aplicação em cada um dos ambientes. Nesse caso, usamos uma branch diferente para construir cada um desses ambientes.

Dentro desses jobs informamos os comandos para realizar o deploy da aplicação e é onde podemos integrar com outros serviços. Esse ponto é um assunto para outro momento.

https://github.com/nathyts/products-api

Qualidade, testes e desenvolvimento

Nathally Souza — Sun, 04 Dec 2022 12:31:17 +0000

Na maioria das vezes, quando falamos em qualidade no desenvolvimento de software, ou citamos a pessoa QA, pensamos em alguém que tem única e exclusivamente o papel de mapear os cenários de testes, testar nossa aplicação e encontrar bugs que eventualmente acontecem após a entrega do código.

A questão é que pensar em qualidade e testes não tem que ser uma função de uma única pessoa, deve ser algo comum a todos do time. Qualidade é uma cultura a ser construída dentro das equipes.

Nas experiências que já tive, entendo que pensar na qualidade vem desde a primeira discussão de uma ideia. Onde isso tem impacto, quais são os cenários desejáveis, o que não queremos que aconteça são algumas das perguntas que tem que ser feitas ainda nesse momento para podermos elaborar os cenários de testes.

Aqui um adendo: caso o time tenha a presença de uma pessoa QA, entendo que ela tem que participar desde esse primeiro momento junto com a tech lead. Caso o time não tenha uma pessoa QA, no meu entendimento, a tech lead, tem que conseguir mapear esses cenários. Uma vez que entendo que QA é cultura, no cenário ideal, todas no time devem ter capacidade para mapear estes cenários, porém a realidade não é o meu cenário ideal.

Porque eu penso que todas no time tem que ter essa mentalidade? Uma vez que garantimos que todas as desenvolvedoras conseguem pensar na qualidade do código, nos cenários corretos e errados, essas pessoas também conseguirão escrever testes, unitários, e2e e funcionais mais eficazes, aumentando a segurança no momento do deploy, diminuindo o risco de bug em produção e a velocidade de resposta para eventuais correções ou implementações.

Por fim, sempre lembrando que não vivemos no cenário que eu julgo ideal, o time de negócios também precisa ter esse olhar de qualidade. É importante que as histórias tenham escopo bem definido e critérios de aceite objetivos. Esses critérios de aceite podem ser exatamente os cenários de testes que esperamos de uma funcionalidade.

Qualidade é cultura e deve ser papel de todos no time, pensar na qualidade do código e da entrega para o usuário final. Essa obrigação não é apenas da QA.