Vigiar sem estar presente, barrar sem ser chato. Pipelines são os melhores aliados para equipe de qualidade.
Nos dias de hoje, uma pipelien de entrega contínua (Continuous Integration/Continuous Deployment — CI/CD) é uma prática fundamental para empresas que desejam acelerar o desenvolvimento de software e garantir eficiência em colocar seus serviços em produção de forma rápida e eficiente. No entanto, para garantir que essa abordagem funcione corretamente e produza resultados de alta qualidade, os testes desempenham um papel crucial e neste artigo, vamos explorar como a área de testes podem usufruir de um ciclo de CI/CD de pipelines e como podemos barrar uma má implementação de ir para produção.
Para melhor aproveitamento desse artigo, considero um pré requisito a leitura sobre o que é uma pipeline de software e a criação de uma pipeline eficiente para sofware.
Momento de execução de cada tipo de teste
Testes de componentes: Os testes de componentes ideal para integração de componentes entre o sistema, num cenário ideal, não devem passar de 20 minutos e podem ser programados para serem executados no ambiente de testes. Se você achar que há necessidade de replicá-los em outros ambientes, não será um problema, você apenas tornará o processo de CI/CD um pouco mais lento.
Testes fim-a-fim ( End-to-end ): Aconselhável habilita-lo em qualquer ambiente com o intuito de garantir que as features basicas do sistema estejam operacionais. Seu tempo pode varias entre 10 minutos a 40 minutos.
Teste de web-page-quality: Como esses testes fazem análise estática dos componentes web, podemos executa-los bo ambiente de produção fora da janeala de horário comercial. Não há teste de funcionalidades nem carga no sistema com esse teste.
Testes de performance: O ideal seria utilizar o máximo de recurso computacional das pipelines para simular a quantida real de usuarios ou cenários de promoções e picos. Esses testes devem ser executados em pré-prod, pois é o ambiente mais próximo do cenário real. Outro conselho é executar os testes de performance em janelas fora do horário comercial devido ao excessivo uso da pipeline, que pode se tornar um gargalo durante o horário comercial.
Testes de contrato: Assim como testes de componentes, o ideal seria testar se todas integrações entre serviços estão operacionais, você pode economizar recurso computanal apenas testando no ambiente de pré-produção, pois, dependendo da quantidade de comunicação entre serviços o tempo de execução também pode ser alto.
Testes de regressao: Os testes que tem a maior carga e se não um dos mais importantes para qualquer release e que acaba exigindo muitas horas de execução pois tem a necessidade de executar vários testes. Alguns serviços de pipelines como Bitbucket e Azure DevOps permitem que algumas pipelines possam ser executadas através de uma trigger ou até mesmo através de tarefas agendadas, o que seria o mais ideal para esse tipo de testes, fazendo com que todo recurso computacional obsoleto ( provavelmente de madrugada ) possa ser utilizado para validar todas as evoluções do sistema.
Ferramentas que podem auxiliar no processo
Uma das maravilhas do processo de CI/CD é a capacidade de criar checks para serem validados sem ter que alocar uma pessoa ou uma equipe para fazer gestão de coisas repetitivas, algumas ferramentas podem permitir que você controle a qualidade do código que foi implementado, como:
Jira: Como o JIRA hoje possibilita o uso de API, você pode usar o modelo de integração entre o Git e o Jira, para que o desenvolvedor sempre commit o ticket que ele está trabalhando como “JIRA-123 — Implementando conexão com Redis” e então, durante a pipeline resgatar esse ticket para validar via API se o ticket se encontra em um status desejado para ir para produção, caso não esteja, a pipeline proibe a mudança no ambiente.
K6 ou JMeter: Com uma das ferramentas, você pode efetuar excessivas chamadas para seu serviço via CLI simulando testes de carga.
Sonar: Com o recurso de Quality Gate, o Sonar consegue analisar a qualidade do código desenvolvido e a quantidade de testes proporcional ao que foi desenvolvido e caso não atenda os requisitos desejados, ela pode forçar a pipeline de não prosseguir com o próximo passo.
Pact: Permite testar contratos entre serviços independentemente da tecnologia usada para implementar esses serviços, em caso de falha, podemos bloquear os próximos passos também.
Eai, como estão os seus testes nas pipelines?
Nos próximos artigos, trarei alguns exemplos práticos de como utilizar as ferramentas dentro de um fluxo de CICD.
Tem interesse em aprender mais sobre? Entre em contato conosco ❤️!
✉️email: [email protected]
