Se você configurou um pipeline de CI/CD há três anos e não mexeu mais, a chance de estar rodando algo defasado é alta. O ecossistema mudou. As ferramentas mudaram. Até a forma de medir se um pipeline funciona bem ganhou uma métrica nova.

Este post reúne o que aconteceu de concreto no mundo de integração contínua entre 2024 e 2026: dados de mercado, comparativos entre ferramentas, segurança de supply chain, o impacto (controverso) de IA nos pipelines e estratégias para monorepos que cortam tempo de build em mais de 90%.

O estado do CI/CD: os números de 2025

O mercado global de ferramentas de CI foi avaliado em USD 1,35 bilhão em 2024 e deve chegar a USD 6,11 bilhões até 2033, segundo a Straits Research. Um crescimento anual de 18,22%. O deploy em cloud responde por mais de 60% dessa receita.

A pesquisa State of CI/CD 2025 da JetBrains trouxe números que refletem bem o dia a dia de quem trabalha com pipelines:

  • 62% usam GitHub Actions em projetos pessoais; 41% usam no trabalho
  • 32% das organizações mantêm duas ferramentas de CI/CD diferentes
  • 9% operam com três ou mais

O motivo mais citado para escolher uma ferramenta de CI é simples: ela mora onde o código mora. Quem usa GitHub escolhe GitHub Actions. Quem usa GitLab escolhe GitLab CI. A decisão raramente acontece de forma isolada.

Do lado das métricas, o relatório DORA 2024/2025 trouxe uma mudança estrutural no framework. Mas isso merece uma seção própria.

GitHub Actions dominou, mas Jenkins não morreu

Em 2025, desenvolvedores consumiram 11,5 bilhões de minutos no GitHub Actions. O marketplace da plataforma tem mais de 10 mil actions em 32 categorias e cresce cerca de 41% ao ano.

Para projetos open-source, a adoção chega a 68%. No ambiente corporativo, o número é menor (41%), mas vem subindo consistentemente.

E o Jenkins? Continua vivo. A Datanyze estima que mais de 30 mil empresas usam Jenkins, incluindo Amazon, Walmart e Apple. Com cerca de 44% de market share no segmento de CI, chamar Jenkins de morto é prematuro. O que acontece é uma migração gradual: o Jenkins perde share ano a ano enquanto GitHub Actions e GitLab CI avançam.

O GitLab CI, por sinal, cresce com força no segmento enterprise. A empresa reportou receita de USD 759 milhões no ano fiscal 2025, crescimento de 31% ano a ano, com clientes acima de USD 1 milhão de ARR subindo 28%. O diferencial é ter segurança embutida (SAST, DAST, container scanning) sem depender de actions de terceiros.

Na prática, quem já vive no GitHub e quer setup rápido com marketplace extenso vai de GitHub Actions. Organizações que exigem scanning de segurança nativo e compliance integrado gravitam para o GitLab CI. E Jenkins segue firme quando já existe infraestrutura madura com centenas de pipelines customizados e a migração não compensa o custo.

Um efeito colateral do marketplace aberto: boa parte das actions novas duplicam funcionalidade de actions já existentes. A abundância nem sempre é sinal de qualidade.

Segurança na pipeline: de shift-left a shift-smart

A ideia de shift-left (mover segurança para mais cedo no ciclo) virou mainstream. Praticamente toda ferramenta de CI oferece algum tipo de scanning integrado. Organizações que adotam DevSecOps reportam redução de 40 a 60% em retrabalho por vulnerabilidades detectadas cedo.

Mas a conversa evoluiu. O conceito emergente é o de shift-smart: aplicar inteligência de segurança no ponto certo, no momento certo, com o contexto certo. Em vez de rodar todos os scanners em todo commit, definir políticas que escalam a intensidade da verificação conforme o risco.

Um pipeline moderno com segurança bem implementada tem pelo menos estas camadas:

  1. Pre-commit: scanning de secrets com push protection
  2. Build no CI: SAST (análise estática) executado em cada pull request
  3. Dependências: SCA (Software Composition Analysis) verificando pacotes
  4. Containers: scanning de vulnerabilidades na imagem final
  5. Infraestrutura: verificação de IaC com ferramentas como Checkov ou tfsec

SLSA e proveniência de artefatos

O framework SLSA (Supply Chain Levels for Software Artifacts), criado pelo Google, ganhou tração significativa. Ele define níveis progressivos de maturidade para garantir a integridade de artefatos de software (a spec original estabelecia quatro níveis; a v1.0 consolidou três no Build track, com o quarto planejado):

  • Nível 1: build totalmente scriptado com metadados de proveniência (sem assinatura)
  • Nível 2: build em plataforma hospedada com proveniência assinada criptograficamente
  • Nível 3: controle de source verificado e ambiente de build isolado
  • Nível 4: builds herméticos e reproduzíveis com revisão obrigatória

O GitHub Actions já suporta geração de attestations e SBOM alinhados com a especificação SLSA. Do lado regulatório, a Executive Order 14028 nos EUA e o Cyber Resilience Act na Europa empurram a adoção: fornecedores de software para governos precisam comprovar proveniência verificável.

DORA agora tem cinco métricas

Durante anos, o framework DORA trabalhou com quatro métricas: deployment frequency, lead time for changes, change failure rate e mean time to recovery. O relatório de 2024 adicionou uma quinta: rework rate.

Rework rate mede a proporção de deploys não-planejados feitos para corrigir problemas visíveis ao usuário. É a métrica que diferencia quem entrega rápido de quem entrega rápido e quebra.

O framework foi reorganizado em duas categorias:

  • 3 métricas de throughput: deployment frequency, lead time for changes e failed deployment recovery time
  • 2 métricas de instabilidade: change failure rate e rework rate

Além disso, reliability entrou como uma quasi-métrica complementar. Times de elite mantêm rework rate baixo sem sacrificar frequência de deploy.

O dado mais interessante (e contraintuitivo) do relatório DORA 2025 envolve IA. Mais de 80% dos respondentes percebem que IA aumentou sua produtividade individual, e 59% observam impacto positivo na qualidade do código. Em 2025, a correlação entre IA e throughput de entrega ficou positiva pela primeira vez, revertendo o resultado negativo de 2024. Mas a instabilidade persiste: times com maior adoção de IA continuam apresentando menor estabilidade de entrega. A conclusão do relatório é que IA funciona como amplificador. Em organizações com boas práticas, ela acelera. Em organizações com problemas estruturais, ela amplifica o caos.

IA nos pipelines: testes flaky e workflows que se consertam

Fora do relatório DORA, a aplicação de IA dentro dos pipelines de CI/CD está ganhando espaço em frentes específicas.

A mais madura é a detecção de testes flaky. Ferramentas como Trunk.io, Datadog Test Analytics e Currents usam machine learning para analisar histórico de execução e atribuir uma pontuação de flakiness a cada teste. Testes identificados como instáveis são automaticamente colocados em quarentena. Times que implementaram essa abordagem reportam redução de até 70% no tempo de execução de testes, com melhoria na taxa de detecção de defeitos reais.

Outra frente são os chamados self-healing workflows: pipelines que detectam anomalias e resolvem problemas automaticamente sem intervenção humana. Triage automático de falhas, retry inteligente, reconfiguração de recursos. Ainda é cedo para chamar isso de padrão, mas ferramentas como Mabl e TestDino estão explorando esse espaço ativamente.

O GitLab reportou 1,5 milhão de desenvolvedores usando suas ferramentas de IA. A empresa atribui a adoção a releases 30% mais rápidos. Mas voltando aos dados do DORA: velocidade individual nem sempre se traduz em estabilidade de entrega. A adoção de IA em pipelines merece atenção, não entusiasmo cego.

Monorepos e o problema do build de 45 minutos

Se o seu repositório cresceu a ponto de cada push acionar rebuild de tudo, monorepo tooling é onde o ganho de tempo é mais dramático.

As três ferramentas dominantes cobrem perfis diferentes. O Turborepo foca em execução rápida de tasks com cache e é a opção mais simples, com integração nativa com Vercel para remote caching. Funciona bem para times React e startups. O Nx vai além: é uma plataforma completa com orquestração avançada, execução distribuída, caching inteligente e geradores de código. Encaixa melhor em projetos enterprise e ecossistemas Angular. Já o Bazel é a artilharia pesada. Suporta qualquer linguagem, garante builds herméticos (reproduzíveis bit a bit) e escala para milhões de linhas de código. É a escolha de organizações com equipes de build engineering dedicadas.

Os números de antes e depois são expressivos. Um time de 50 desenvolvedores migrou de Lerna para Turborepo + Nx com remote caching em S3 e nx affected para pular projetos não afetados. O resultado: CI caiu de 45 minutos para 4 minutos, ignorando 80% das tasks.

A Stripe migrou mais de 300 serviços para um monorepo com Bazel. O tempo de CI caiu de aproximadamente 45 minutos para menos de 7 minutos.

As estratégias que fazem diferença em monorepos são poucas e diretas:

  1. Affected detection: rodar build e testes apenas nos projetos impactados pelo commit
  2. Remote caching: compartilhar cache entre CI e desenvolvimento local (Nx Cloud, Vercel Remote Cache ou S3 customizado)
  3. Paralelização: executar tasks independentes simultaneamente
  4. Composição inteligente de cache keys: combinar OS, versão do Node e hash do lockfile

Para a maioria dos times JavaScript/TypeScript, a escolha fica entre Turborepo (simplicidade) e Nx (plataforma completa). Bazel fica reservado para organizações poliglotas dispostas a investir em infraestrutura de build.

Conclusão

O cenário de CI/CD em 2026 se resume a três movimentos simultâneos. A consolidação de ferramentas ao redor de GitHub Actions e GitLab CI, com Jenkins mantendo uma base instalada que resiste à migração. A entrada de segurança e proveniência como requisitos de pipeline, não como afterthought. E a adoção cautelosa de IA para otimização de testes e detecção de anomalias.

Se eu fosse priorizar uma coisa para revisar nos meus pipelines hoje, seria a quinta métrica do DORA: rework rate. Medir quantos deploys existem só para corrigir o deploy anterior conta uma história que deployment frequency sozinha esconde.

A próxima fronteira é a convergência entre as três frentes. Pipelines que combinam affected detection de monorepos, scanning de segurança contextual (shift-smart) e triage automatizado de falhas com ML. Separadamente, cada peça já existe. Juntar tudo de forma coerente é o trabalho dos próximos dois anos.

Referências pesquisadas nesta publicação