22 de julho de 2026
Qualidade de Código: Integrando a Validação de Software de Forma Nativa em Pipelines
Breno de Oliveira Veroneze; Everton Gomede
DOI: 10.22167/2675-6528-202600606
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
A demanda por entregas rápidas e a padronização rigorosa no desenvolvimento de software tornaram a validação manual de código ineficiente e suscetível a erros. Nesse contexto, fluxos de Integração Contínua (CI) emergiram como alternativa essencial para otimizar o desenvolvimento, garantir a qualidade e reduzir a dívida técnica. O objetivo deste trabalho foi propor e avaliar um guia de boas práticas para integração de testes automatizados em pipelines de integração contínua e demonstrar seu valor em equipes de desenvolvimento. Para isso, adotou-se uma metodologia de pesquisa mista, que combinou elementos quantitativos e qualitativos. Realizaram-se experimentos cronometrados com dois desenvolvedores, nos quais se comparou a execução manual e automatizada de etapas de pipeline, e testes de código para avaliar o comportamento do SonarQube em diferentes cenários de cobertura e vulnerabilidades. A pipeline foi implementada utilizando GitHub Actions e SonarQube, com testes unitários via Jest e análise de qualidade por inteligência artificial (Groq Cloud), em um sistema de controle de estoque. Os resultados demonstraram que a automação reduziu significativamente o esforço manual, gerou economia de tempo e custos, e que a imposição de padrões de código impediu a integração de código não conforme, diminuindo a dívida técnica. Concluiu-se que pipelines automatizadas para validação e integração de código representam ferramentas vitais que proporcionam vantagem competitiva ao longo do ciclo de vida do software.
Palavras-chave: Automação; Código; Desenvolvimento; Integração Contínua; Padronização.
1. Introdução
O setor de Tecnologia da Informação (TI) tem experimentado um crescimento exponencial, assumindo um papel cada vez mais central em empresas de diversos segmentos. A Associação Brasileira das Empresas de Software (ABES, 2022) reportou investimentos de US$58,6 bilhões no setor em 2024, com uma projeção de crescimento de 9,5% para o ano de 2025. Este cenário de intensa competitividade impulsiona a necessidade de velocidade no desenvolvimento e na entrega de soluções de software, tornando-os fatores estratégicos para o sucesso organizacional.
Nesse contexto, o conceito de fluxo de entrega contínua, englobando a Integração Contínua (CI) e a Entrega Contínua (CD), emergiu como um paradigma transformador na cultura de equipes de desenvolvimento e operações. Por meio de pipelines automatizadas, o CI/CD permite a otimização de cadeias de construção, testes e implantação de aplicações, garantindo segurança e eficiência no ambiente de produção e atendendo às expectativas do mercado.
A Integração Contínua, desenvolvida por Kent Beck na década de 1990 como parte da Extreme Programming, surgiu para resolver os problemas decorrentes da integração isolada de código. Beck propôs integrações diárias e frequentes, permitindo a identificação e correção precoce de problemas. Conforme a IBM (2025), a CI é fundamental quando múltiplos desenvolvedores colaboram no mesmo código, utilizando ramificações e pull requests para submeter alterações a um repositório central, onde testes automatizados são executados antes da mesclagem.
Complementarmente, a Entrega Contínua, conforme descrito por Fowler (2006), incentiva os desenvolvedores a submeterem alterações frequentemente, minimizando a probabilidade de problemas no código. A CD automatiza a implantação do código em ambientes de produção após as validações necessárias, eliminando tarefas manuais e reduzindo os riscos associados a intervenções humanas. A adoção de CI/CD, portanto, otimiza o tempo e assegura a execução padronizada de todas as etapas do fluxo de desenvolvimento, resultando em menos rollbacks e na redução de dívidas técnicas, tanto de código quanto de infraestrutura.
Apesar da consolidação desses conceitos na literatura, observa-se uma lacuna significativa em relação à estruturação da validação automatizada de código dentro das pipelines de CI/CD. Muitas equipes de desenvolvimento implementam a automação sem definir critérios de qualidade adequados, o que pode levar a um aumento da dívida técnica e a retrabalhos que poderiam ser evitados em etapas iniciais. Diante desse cenário, a problemática central desta pesquisa questiona qual o benefício e como garantir a qualidade de código de forma automatizada em esteiras de integração. Assim, o presente trabalho justifica-se pela necessidade de aprofundar a compreensão sobre a integração efetiva de validações de código em pipelines, visando aprimorar a qualidade do software, reduzir custos e otimizar o tempo de desenvolvimento. O objetivo é propor e avaliar um guia de boas práticas para integração de testes automatizados em pipelines de integração contínua e demonstrar seu valor em equipes de desenvolvimento.
2. Material e Métodos
A presente pesquisa adotou uma natureza aplicada, buscando gerar conhecimento prático diretamente voltado à solução do problema da garantia de qualidade de código por meio de fluxos de pipeline automatizados. A abordagem metodológica empregada foi de caráter misto, combinando elementos quantitativos e qualitativos para uma compreensão abrangente do fenômeno estudado.
Os aspectos quantitativos da investigação foram sustentados por experimentos com execuções cronometradas, além da coleta de métricas relacionadas à cobertura de código e à detecção de inconsistências em validações de qualidade. Complementarmente, os elementos qualitativos envolveram a análise dos impactos culturais que uma nova tecnologia pode suscitar e os desafios técnicos inerentes à implantação de ferramentas em ambientes corporativos.
Quanto aos objetivos, o estudo classificou-se como exploratório e descritivo. Foi exploratório por investigar práticas ainda pouco sistematizadas na literatura sobre a integração nativa de testes automatizados em pipelines. Foi descritivo por mapear e documentar o processo, as ferramentas utilizadas e os resultados obtidos a partir do experimento realizado.
O delineamento da pesquisa foi experimental, com a realização de testes em um ambiente controlado. Este ambiente foi configurado para simular um fluxo de integração contínua, buscando aproximar-se da realidade de equipes de desenvolvimento em empresas, com o propósito de avaliar práticas e ferramentas de desenvolvimento de software.
A unidade de análise ou objeto empírico do estudo consistiu em um sistema de controle de estoque de uma papelaria, desenvolvido na linguagem Node.js. Para a condução dos experimentos cronometrados, participaram dois desenvolvedores, que executaram as etapas da pipeline tanto de forma manual quanto automatizada.
O ambiente experimental foi configurado com um sistema operacional Windows 11 64bits, processador Intel Core i5-10ª geração e 16GB de memória RAM. Para o desenvolvimento e execução do código, utilizou-se Node.JS 20.17.0 como linguagem de programação e o Visual Studio Code [VS Code] 1.112.0 como editor de código.
As ferramentas de suporte à integração contínua e qualidade de código incluíram a biblioteca de testes Jest 30.2.0, a ferramenta de qualidade SonarQube Community Edition 9.9.8 e o GitHub Actions como ferramenta de CI/CD. O repositório remoto público utilizado foi o Github, e a plataforma de conteinerização empregada foi o Docker Desktop 4.34.3. Para a inteligência artificial, utilizou-se Groq Cloud.
Os procedimentos de coleta de dados envolveram experimentos cronometrados, nos quais se comparou a execução manual e automatizada das etapas da pipeline. Cada um dos dois desenvolvedores realizou cinco execuções para cada modo (manual e automatizado), e os tempos foram registrados para posterior comparação.
Para a execução manual, utilizaram-se os comandos `npm test –coverage`, `node scan.js` e `node ai-review.js`. Na execução automatizada, os comandos empregados foram `git add .`, `git commit -m “”Dev X – Teste Automatico Y”` e `git push`, que acionavam a pipeline de integração contínua.
Adicionalmente, realizaram-se execuções de testes de código para demonstrar o comportamento do SonarQube. Avaliaram-se códigos com diferentes coberturas de testes e vulnerabilidades inseridas intencionalmente, a fim de observar a detecção de inconsistências e a aplicação das regras de qualidade.
A pipeline de integração foi implementada utilizando GitHub Actions e configurada para ser executada automaticamente a cada novo `commit` no repositório. As etapas sequenciais incluíram a inicialização do ambiente em máquina virtual, o checkout do código, a configuração do Node.js e a instalação das dependências do projeto.
As etapas de qualidade do código na pipeline consistiram na execução de testes unitários por meio da biblioteca Jest e na análise de qualidade pelo SonarQube. Este último foi configurado com um `quality profile` e um `quality gate` específicos, sendo que o não atendimento aos requisitos mínimos do `quality gate` resultaria na interrupção da integração.
O `quality profile` do SonarQube foi configurado para a linguagem Javascript, baseando-se no perfil padrão e adaptando regras conforme o contexto da aplicação. Exemplos de regras incluíram “Laços de repetição não deveriam ser infinitos” com severidade bloqueante e “As variáveis devem ser declaradas com “let” ou “const”” com severidade crítica, entre outras de alta, baixa e informativa.
O `quality gate` estabeleceu condições para a aprovação do código, como cobertura de código em novas linhas maior ou igual a 90%, linhas duplicadas em novas linhas menor ou igual a 3%, e ratings de manutenibilidade, confiabilidade e segurança não piores que “A”. Também se exigiu 100% de Security Hotspots revisados e a ausência de bugs críticos no código geral.
A inteligência artificial Groq Cloud foi integrada à pipeline como um auxiliar, com a função de analisar o código e sugerir melhorias e otimizações. A IA foi configurada com um prompt específico para guiar sua análise, mas sua atuação se limitou a sugestões, sem barrar a integração do código.
Para a análise dos dados, os tempos cronometrados foram comparados para avaliar o impacto da automação em termos de tempo e custo. As métricas de qualidade fornecidas pelo SonarQube foram observadas para verificar a conformidade do código com os padrões estabelecidos. A análise qualitativa focou nos impactos culturais e desafios técnicos de implantação da automação.
3. Resultados e Discussão
Os resultados desta pesquisa demonstram o valor da integração de testes automatizados em pipelines de integração contínua, abordando a lacuna na literatura sobre a estruturação da validação automatizada de código e respondendo ao problema de pesquisa sobre o benefício e a garantia da qualidade de código em esteiras de integração. A investigação focou na otimização e padronização dos processos de desenvolvimento, especialmente em contextos de equipes grandes e distribuídas, onde a garantia robusta de qualidade e a integração segura do código são cruciais. Observou-se que a literatura atual, embora abranja temas como segurança, inteligência artificial e entrega contínua, carece de aprofundamento na qualidade de código e na estruturação de testes automatizados em pipelines, conforme evidenciado pela análise de trabalhos acadêmicos recentes.
A pesquisa quantificou o impacto da automação no tempo e custo, realizando experimentos cronometrados com dois desenvolvedores. A média de cinco execuções manuais de etapas do pipeline revelou um tempo médio de 96 segundos por desenvolvedor. Em contraste, a execução automatizada das mesmas etapas resultou em um tempo médio significativamente menor, de 25 segundos. Essa diferença de 71 segundos por integração representa uma otimização substancial no ciclo de desenvolvimento, liberando os desenvolvedores de tarefas repetitivas e demoradas.
Para calcular a economia financeira, utilizou-se uma fórmula que considerou a frequência mensal de integrações (aproximadamente 110 por desenvolvedor, baseada em cinco integrações diárias em 22 dias úteis), o tempo médio manual (96 segundos), o tempo médio automatizado (25 segundos) e o custo médio da hora do desenvolvedor (R$ 39,55). A aplicação desses valores indicou uma economia de R$ 85,80 por desenvolvedor por mês. Embora essa métrica represente um cenário idealizado, ela ilustra o potencial de ganhos reais, que se traduzem no reaproveitamento das horas economizadas em atividades de maior complexidade e valor agregado para a empresa, conforme discutido por DeMarco e Lister (1987) sobre a gestão de tempo e produtividade.
Contudo, é fundamental reconhecer as limitações do experimento. Fatores como fadiga do desenvolvedor, familiaridade com as ferramentas e a complexidade de eventuais conflitos de código podem influenciar os tempos de execução manual e automática. Apesar dessas variáveis, o fluxo automatizado estabelece um padrão rigoroso, garantindo que todas as integrações sigam requisitos mínimos de qualidade e segurança, algo que pode ser negligenciado ou burlado em processos manuais. Isso reforça a importância da automação não apenas pela eficiência, mas também pela consistência e conformidade.
Barreiras técnicas podem surgir na implementação de um fluxo de integração contínua, especialmente em empresas com código legado. Nesses casos, o código existente que não segue padrões de testes pode precisar ser desconsiderado pela pipeline de testes de qualidade, permitindo que apenas o código novo passe pelas validações. Para mitigar esses desafios, é crucial que o *quality profile* e o *quality gate* sejam configurados de forma adequada na ferramenta SonarQube, alinhados ao contexto específico de cada produto ou aplicação.
O *quality profile* está diretamente ligado à linguagem de programação da aplicação e avalia regras de codificação, boas práticas e segurança. Cada regra possui um grau de severidade, que determina o peso das *issues* (erros) geradas. As severidades incluem: Bloqueante, para falhas com alta probabilidade de impactar a produção (erros de lógica, conexões não encerradas); Crítico, para falhas que podem causar comportamentos inesperados ou falhas de segurança; Alta, para falhas que prejudicam a manutenção do código (complexidade ciclomática); Baixa, para falhas que afetam a legibilidade, mas sem grande impacto; e Informativo, para apontamentos sem relação com problemas de boas práticas ou falhas.
Para o sistema de controle de estoque utilizado no experimento, o *quality profile* foi configurado com regras específicas. Por exemplo, a regra “Laços de repetição não deveriam ser infinitos” foi classificada como Bloqueante, visando impedir estruturas de repetição sem condição de fim, que poderiam comprometer o funcionamento da aplicação. A regra “As variáveis devem ser declaradas com ‘let’ ou ‘const'” foi definida como Crítica, pois a utilização de ‘var’ pode levar a problemas de vazamento de escopo e redeclaração acidental, conforme as recomendações do ECMAScript 2015.
Outras regras importantes incluíram a validação de “Funções não devem ser definidas dentro de laços de repetição”, classificada como Alta, por ser uma boa prática que evita resultados inesperados, mesmo sem gerar um problema direto no código. A regra “Importações desnecessárias devem ser removidas” foi classificada como Baixa, pois, embora não cause falhas de execução, polui o código e pode impactar a performance. Por fim, uma regra Informativa, “Rastrear usos das tags ‘TODO'”, foi incluída para alertar o desenvolvedor sobre código incompleto, auxiliando na identificação de problemas em conjunto com outras regras.
O *quality gate* atua como um conjunto de condições que o código deve atender para ser integrado. No experimento, as condições para o “novo código” incluíram: cobertura de testes unitários mínima de 90%, máximo de 3% de linhas de código duplicadas, percentual de dívida técnica menor que 5%, ausência de *bugs*, 100% dos *Security Hotspots* revisados e ausência de falhas críticas de segurança. Para o “código geral”, a única condição era a ausência de *bugs* críticos, garantindo que mesmo o código legado fosse avaliado para correções antes da integração.
Para demonstrar a funcionalidade do *quality gate*, foram inseridas intencionalmente vulnerabilidades no código do sistema de controle de estoque. Uma delas foi a inclusão de credenciais de banco de dados (`dbPassword` e `awsToken`) diretamente no código, uma prática de segurança inadequada. Outra vulnerabilidade foi a inserção de um atributo *string* concatenado em uma consulta, permitindo a injeção de SQL. Adicionalmente, foi implementado um trecho de código que possibilitava a injeção de comando, utilizando a função `exec` com entrada de usuário, e o uso de um algoritmo de *hashing* fraco (MD5).
Essas falhas de segurança e a ausência de cobertura de testes unitários (0% no código novo, quando o mínimo exigido era 90%) fizeram com que a avaliação de segurança do SonarQube caísse para “E”, sendo “A” o mínimo para aprovação. O SonarQube também apontou dois novos *Security Hotspots* não revisados. Consequentemente, o *quality gate* recusou a integração, e a pipeline “falhou” na etapa de análise de qualidade, impedindo que um código não conforme com as boas práticas e com vulnerabilidades de segurança fosse integrado. Após a correção dessas vulnerabilidades e o atendimento aos requisitos do *quality gate*, o SonarQube aprovou o código, e a integração na pipeline do GitHub Actions ocorreu com sucesso.
Além das barreiras técnicas, a implementação de um fluxo de integração contínua pode enfrentar barreiras culturais significativas dentro das empresas. A Lei de Conway (1967) sugere que a estrutura de um sistema de software reflete a estrutura de comunicação da organização. Assim, equipes com comunicação isolada (“silos”) tendem a desenvolver sistemas fragmentados, o que pode dificultar a colaboração exigida pela integração contínua. A resistência à adoção de novas tecnologias também é um desafio, pois a automação pode ser percebida por profissionais experientes como uma ameaça à sua competência ou uma erosão de seu capital intelectual, conforme apontado por DeMarco e Lister (1987) e Rogers (2003) em sua Teoria da Difusão da Inovação.
Para superar essas barreiras culturais, é essencial um planejamento de comunicação e capacitação dos profissionais diretamente impactados. A automação deve ser apresentada como uma evolução que garante melhores resultados para o negócio e não como uma ameaça à carreira dos desenvolvedores. A transparência e o diálogo aberto entre gestão e equipes são fundamentais para que a nova tecnologia seja vista como um facilitador e não como um mecanismo de desqualificação, promovendo uma mudança cultural que valorize a colaboração e a padronização.
A inteligência artificial (IA) emergiu como um auxiliar valioso nos fluxos de desenvolvimento. Uma pesquisa da McKinsey (Ramos, 2024) indicou que 72% das empresas adotaram alguma forma de tecnologia de IA em 2024, evidenciando seu uso crescente. Na pipeline desenvolvida, o Groq Cloud foi integrado como um copiloto de IA, com o objetivo de analisar o código e sugerir melhorias e correções com base em um *prompt* pré-definido. É importante ressaltar que, nesta etapa, a IA atua apenas como um auxiliar, não possuindo a capacidade de reprovar a integração, diferentemente dos testes de qualidade e testes unitários.
A IA identificou as mesmas vulnerabilidades inseridas no código para o teste do *quality gate*, como credenciais *hardcoded*, injeção de SQL, injeção de comando, uso de algoritmo de *hashing* fraco, baixa legibilidade e oportunidades de otimização e cobertura de testes. Essa capacidade de diagnóstico da IA, mesmo sem poder de bloqueio, oferece um suporte valioso aos desenvolvedores, especialmente quando o código é reprovado por outras etapas da pipeline, fornecendo sugestões para correções e otimizações. A contextualização da IA por meio de um *prompt* pré-definido garante que suas avaliações sejam relevantes para o escopo do projeto.
Em síntese, a pesquisa demonstrou que a implementação de pipelines automatizadas com testes integrados é uma ferramenta vital para garantir a qualidade do código, reduzir a dívida técnica e otimizar o tempo de desenvolvimento. A automação não apenas gera economia de tempo e custos, mas também impõe padrões de qualidade que impedem a integração de código não conforme. A superação dos desafios técnicos, como a configuração de *quality profiles* e *quality gates* adequados, e dos desafios culturais, por meio de comunicação e capacitação, é essencial para o sucesso da adoção dessas práticas, consolidando a integração contínua como um diferencial competitivo no ciclo de vida do software.
4. Conclusão
O estudo buscou propor e avaliar um guia de boas práticas para integração de testes automatizados em pipelines de integração contínua e demonstrar seu valor em equipes de desenvolvimento. Verificou-se que a automação de etapas de pipeline reduziu significativamente o esforço manual, gerando uma economia de tempo de 71 segundos por integração e um potencial de economia financeira de R$ 85,80 por desenvolvedor por mês. Observou-se que a imposição de padrões de código, por meio da configuração de *quality profiles* e *quality gates* no SonarQube, impediu a integração de código não conforme e com vulnerabilidades de segurança, como credenciais *hardcoded* e injeção de SQL, contribuindo diretamente para a diminuição da dívida técnica. A inteligência artificial, atuando como copiloto, identificou essas vulnerabilidades e sugeriu melhorias, complementando o processo de validação sem, contudo, bloquear a integração. A principal contribuição reside na demonstração empírica de que pipelines automatizadas, com validação de código integrada, são ferramentas vitais que proporcionam vantagem competitiva ao longo do ciclo de vida do software, otimizando processos e garantindo a qualidade e segurança do código.
Contudo, o experimento apresentou limitações, como a influência de fatores humanos e a natureza idealizada do cálculo de economia financeira. A implementação de tais fluxos pode enfrentar barreiras técnicas, especialmente com código legado, e desafios culturais, como a resistência à inovação e a fragmentação da comunicação, que exigem planejamento de comunicação e capacitação. Para estudos futuros, sugere-se ampliar a pesquisa aplicando o fluxo de validação automatizada em diferentes contextos organizacionais, comparando empresas de portes distintos e equipes com variados níveis de maturidade. Recomenda-se também investigar o impacto quantitativo dessas práticas em métricas como redução de falhas em produção e evolução da dívida técnica, além de explorar o uso de inteligência artificial e análise preditiva para identificação antecipada de riscos de qualidade e adaptação dinâmica de *quality gates*.
Referências Bibliográficas
Associação Brasileira das Empresas de Software [ABES]. 2022. Brasil acelera crescimento no setor de TI, mantém posição no top 10 global e se destaca na América Latina, aponta novo estudo da ABES. Disponível em: https://abes.org.br/brasil-acelera-crescimento-no-setor-de-ti-mantem-posicao-no-top-10-global-e-se-destaca-na-america-latina-aponta-novo-estudo-da-abes/. Acesso em: 04 set. 2025.
DeMarco, T.; Lister, T. 2016. Peopleware: Gerenciando Projetos e Equipes de Desenvolvimento de Software. 3ed. Alta Books, Rio de Janeiro, RJ, Brasil. Acesso em: 27 nov. 2025.
Fowler, M. 2006. Continuous integration. Disponível em: https://martinfowler.com/articles/continuousIntegration.html. Acesso em: 02 out. 2025.
IBM. 2025. O que são testes contínuos? Disponível em: https://www.ibm.com/br-pt/think/topics/continuous-testing. Acesso em: 04 set. 2025.
Ramos, M. 2024. Uso de inteligência artificial aumenta e alcança 72% das empresas, diz pesquisa. Disponível em: https://www.cnnbrasil.com.br/economia/negocios/uso-de-inteligencia-artificial-aumenta-e-alcanca-72-das-empresas-diz-pesquisa/. Acesso em: 11 jan. 2026.
Rogers, E.M. 2003. Diffusion of Innovations. Free Press, New York, NY, USA. Acesso em: 05 jan. 2026.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy
