O que é CI/CD?

CI/CD combina duas práticas: integrar o código ao repositório principal todo dia, com build e testes automáticos, e manter o software sempre pronto para produção. A primeira é a integração contínua (CI), a segunda, a entrega contínua (CD), e o “CD” esconde uma terceira leitura, a implantação contínua, sem aprovação humana antes do deploy. Aqui você vê como o pipeline funciona do commit à produção, quanto custa, por que falha e o que a inteligência artificial (IA) mudou. Em novembro de 2026, o ponto quente é esse: a IA entrou na escrita do código, mas ficou fora da esteira que o valida.

• 90% dos profissionais de software dizem usar IA no trabalho, segundo o relatório DORA 2025, com quase 5.000 respondentes ouvidos entre 13/06 e 21/07/2025
• 73% dos respondentes não usam IA nos fluxos de CI/CD, segundo a pesquisa State of CI/CD 2025 da JetBrains, de outubro de 2025
• 101 estudos primários, de 2003 a 2019, sustentam a revisão sistemática do arXiv de 2021 que conclui: CI ajuda a qualidade, mas ligar o serviço, sozinho, não acelera a entrega de pull requests
• 5 métricas em dois fatores (throughput e instabilidade) formam o conjunto atual do DORA para medir se o pipeline melhorou alguma coisa
• 20/12/2023 é a data da versão final da NIST SP 800-204D, que trata o pipeline de CI/CD como alvo e pede atestação no build e zero trust

O que é CI/CD e o que as siglas integração contínua e entrega contínua significam

CI/CD é a junção de duas práticas de engenharia de software: a integração contínua (CI, de continuous integration) e a entrega contínua (CD, de continuous delivery). Na primeira, cada pessoa do time integra seu código ao repositório principal pelo menos uma vez por dia, e um build automatizado com testes confere cada integração. Na segunda, o software fica sempre em condição de ir para produção, mesmo que alguém ainda precise apertar o botão.

A definição que todo mundo cita vem de Martin Fowler. Para ele, a essência da prática é “everyone on the team integrating frequently, at least daily, against a controlled source code repository”, com cada integração verificada por build e testes automáticos para pegar erro de integração o mais cedo possível. O artigo nasceu em 2001, ganhou atualização em 2006 e foi reescrito do zero em 2023. Fowler também chama a prática de desenvolvimento baseado em tronco (trunk-based development), e o nome diz muito: todo mundo trabalha perto da branch principal, em vez de sumir numa branch própria por semanas.

A parte confusa é o “CD”. A sigla serve para duas coisas diferentes:

• Entrega contínua: o pipeline deixa o software pronto para liberar a qualquer momento, mas a liberação para produção passa por uma decisão humana. É assim que o Microsoft Learn descreve a prática.
• Implantação contínua (continuous deployment): uma etapa a mais, em que toda mudança que passa pelo pipeline vai sozinha para produção, sem portão manual. A descrição é do Azure Architecture Center.

A Red Hat, na versão em português do seu material, registra exatamente essa ambiguidade. A diferença entre as duas leituras é uma só: existe ou não um humano aprovando o deploy final.

As demais definições de fornecedor convergem. A AWS, no whitepaper em português sobre o tema, trata CI/CD como o conjunto de práticas que permite mudar o software rapidamente sem perder a estabilidade e a segurança do sistema. A IBM, também em português, descreve o pipeline de CI/CD como um fluxo de trabalho automatizado de DevOps que simplifica a entrega.

E de onde vem a palavra “pipeline”? A ideia de deployment pipeline ganhou nome no livro Continuous Delivery, de Jez Humble e David Farley, publicado em 2010 pela Addison-Wesley e ainda em catálogo na Pearson. O livro é a origem do conceito geral: uma sequência automatizada que leva cada mudança do commit até a produção, com paradas de verificação no caminho. O detalhe de cada parada varia por equipe, por linguagem e por década, e é melhor olhar para a prática atual do que atribuir receitas ao livro.

Como funciona um pipeline de CI/CD do commit até a produção

Um pipeline de CI/CD funciona como uma esteira automática disparada por um commit: o código entra, passa por build, testes, empacotamento e publicação do artefato, vai para um ambiente de teste e, com ou sem aprovação humana, chega à produção. Cada etapa só roda se a anterior passou. Se o build quebra, nada avança, e quem fez o commit descobre em minutos.

O fluxo típico tem estas paradas, nesta ordem:

1. Um push ou um pull request dispara o pipeline.
2. O build compila ou monta a aplicação a partir do código recém-integrado.
3. Os testes automatizados rodam sobre esse build (unitários primeiro, por serem rápidos, depois integração).
4. A aplicação é empacotada, em geral numa imagem de container.
5. O artefato vai para um registro, com versão identificável.
6. O deploy acontece num ambiente de teste ou homologação.
7. Um portão manual, opcional, libera o deploy em produção.

Hoje o pipeline vive no próprio repositório, como código. No GitHub Actions, cada workflow é um arquivo YAML dentro de .github/workflows, disparado por eventos como push ou pull request. Um workflow tem um ou mais jobs, e cada job tem uma sequência de steps. O resultado é que a definição do pipeline passa por revisão, versionamento e histórico exatamente como qualquer outra parte do sistema. Mudou o pipeline, tem commit, tem PR, tem quem aprovou.

Um exemplo com nome de produto ajuda a enxergar a montagem. A arquitetura de referência do Google Cloud para aplicações em container encadeia Cloud Code no desenvolvimento, Cloud Build para build e testes, Artifact Registry para guardar as imagens, Cloud Deploy para promover a versão entre ambientes e GKE como destino. A produção, nesse desenho, só recebe a versão depois que um operador aprova manualmente. O documento foi revisado pela última vez em 18/11/2022, então nomes e capacidades de serviço podem ter mudado desde então. A forma do fluxo, essa continua a mesma.

O que ninguém descobre até montar o primeiro pipeline é que ele quase nunca quebra no deploy. Quebra no build, por uma diferença entre a máquina de quem programou e o runner que executa o YAML: uma variável de ambiente que só existia localmente, uma dependência instalada à mão, uma versão de linguagem diferente. É chato e é bom ao mesmo tempo, porque a esteira está pegando em minutos o tipo de divergência que antes aparecia na madrugada de uma release.

Para que serve CI/CD na prática e que problemas ele resolve

CI/CD serve para descobrir problemas de integração horas depois de criados, em vez de semanas, e para transformar a release de um evento raro e tenso em algo rotineiro. Os problemas que a prática ataca são conhecidos de qualquer time que já passou por um “merge de sexta-feira”:

• Integração tardia: cada pessoa trabalha isolada por dias e só junta tudo no fim, quando os conflitos já se acumularam.
• Conflito de merge em branch longa: o material de aula da USP sobre integração contínua aponta exatamente esse ponto como motivador da prática.
• Release rara e arriscada: quanto mais mudanças entram de uma vez, mais difícil é saber qual delas quebrou o sistema.
• Erro descoberto só em produção: sem teste automatizado em cada integração, o usuário vira o testador.

A evidência a favor existe, mas tem ressalvas. Uma revisão sistemática de 101 estudos primários publicados entre 2003 e 2019, disponível no arXiv desde 2021, conclui que a integração contínua ajuda o processo de desenvolvimento e a garantia de qualidade, e ao mesmo tempo traz desafios técnicos próprios. Os autores também dizem que a pesquisa empírica na área ainda tem espaço para melhorar. Um achado da mesma linha de pesquisa merece destaque, porque contraria o senso comum:

Adotar um serviço de CI não necessariamente acelera a entrega de pull requests mesclados.

Ou seja, ligar o serviço não entrega velocidade. O que entrega é a disciplina de integrar pequeno e frequente, e a ferramenta só torna essa disciplina barata de cumprir.

Há casos individuais com números grandes. Um estudo de caso do Capital One, hospedado pelo Google, relata aumento de mais de 20 vezes na frequência de liberações sem aumento de incidentes. É o resultado de uma empresa, com práticas e orçamento de banco, e não serve como estatística geral para o seu time.

Para medir o efeito no seu contexto, o conjunto de métricas do programa de pesquisa DORA é o padrão de fato. A versão atual tem cinco medidas em dois fatores:

Fator	Métrica	O que mede
Throughput	Lead time de mudança	Tempo do commit até rodar em produção
Throughput	Frequência de implantação	Quantas vezes o time coloca mudança em produção
Throughput	Tempo de recuperação de implantação com falha	Quanto demora para restaurar o serviço após um deploy ruim
Instabilidade	Taxa de falha de mudança	Fração dos deploys que causam incidente ou rollback
Instabilidade	Taxa de retrabalho de implantação	Fração dos deploys que exigem um novo deploy corretivo

Essas métricas são a primeira coisa a instrumentar antes de qualquer discussão sobre ferramenta, e é por elas que começa um trabalho honesto de consultoria DevOps: sem lead time e taxa de falha medidos antes, ninguém sabe se o pipeline novo melhorou alguma coisa.

Nem todo sistema cabe na parte “implantação” da sigla. O material da USP lembra que aplicações desktop, apps móveis e sistemas embarcados exigem instalação ou atualização no dispositivo do usuário, e por isso a implantação contínua até a produção não se aplica a eles. A integração contínua, com build e testes a cada push, continua valendo para todos. O deploy automático, não.

Qual a diferença entre integração contínua, entrega contínua e implantação contínua?

A diferença entre as três práticas está em até onde a automação vai: a integração contínua automatiza build e testes a cada commit, a entrega contínua automatiza tudo até deixar uma versão pronta para produção, e a implantação contínua tira o último botão e publica sozinha. Cada uma pressupõe a anterior. Sem integração contínua estável, a entrega contínua vira um pipeline que ninguém confia para liberar, e sem entrega contínua confiável, publicar sem aprovação humana é só uma forma mais rápida de derrubar o sistema.

Lado a lado, as três ficam assim:

	Integração contínua	Entrega contínua	Implantação contínua
O que automatiza	Build e testes a cada push	Build, testes, empacotamento e deploy em homologação	Tudo, inclusive o deploy em produção
Onde está o portão manual	Depois dos testes, para decidir o que fazer com a versão	Antes da produção	Em lugar nenhum
Pré-requisito	Repositório único e testes automatizados	Integração contínua funcionando há meses	Testes em que o time confia a ponto de dispensar a aprovação
Tipo de sistema	Qualquer um, inclusive desktop, mobile e embarcado	Serviços e APIs que o próprio time publica	Serviços e APIs com rollback rápido

Por que o “CD” confunde tanto? Porque entrega e implantação compartilham o pipeline inteiro e diferem num único ponto: a aprovação humana antes da produção. O Microsoft Learn descreve a entrega contínua como um processo em que o software está sempre pronto para liberar, com a liberação em si feita à mão. O Azure Architecture Center descreve a implantação contínua como a etapa a mais, que leva automaticamente à produção qualquer mudança aprovada pelo pipeline. Dois nomes, uma sigla, um botão de diferença.

O portão manual costuma ser uma escolha, e muitas vezes a certa. Se você toca o time de engenharia de uma fintech em São Paulo ou de uma operadora de saúde, há mudanças que precisam de janela, comunicação e alguém de plantão. A entrega contínua entrega exatamente isso: a versão pronta, testada e versionada, esperando a decisão. O que dá errado na prática é outra coisa. O portão vira gargalo quando uma pessoa só aprova, e as versões se acumulam na fila de homologação até que o deploy de sexta carregue dez mudanças de uma vez, que era justamente o cenário que a prática existia para evitar.

Quais ferramentas de CI/CD o mercado usa e como escolher entre elas

As ferramentas de CI/CD mais usadas são GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, Cloud Build e Cloud Deploy no Google Cloud, AWS CodePipeline e TeamCity, e a escolha entre elas depende menos de recurso e mais de onde o código está hospedado, de quem vai operar a infraestrutura e do que já existe na empresa. O mercado está longe de consolidado. A pesquisa State of CI/CD 2025 da JetBrains, publicada em outubro de 2025, registra que o GitHub Actions ainda não substituiu Jenkins e GitLab CI dentro das empresas, e que as equipes escolhem a ferramenta conforme onde o código mora.

Ferramenta	Modelo de execução	Onde faz mais sentido	Ponto de atenção
GitHub Actions	Serviço do GitHub, com runners hospedados ou próprios	Código já no GitHub	Workflow em YAML dentro do repositório
GitLab CI	Serviço ou instalação própria	Código já no GitLab	Mesma lógica de pipeline como código
Jenkins	Open source, servidor próprio	Legado e controle total da execução	A manutenção do servidor fica com o time
Azure Pipelines	Serviço da Microsoft	Infraestrutura e ferramentas Microsoft	Integração com o restante do Azure
Cloud Build + Cloud Deploy	Serviços gerenciados do Google Cloud	Aplicações em GKE	Arquitetura de referência revisada em 2022
AWS CodePipeline	Serviço gerenciado da AWS	Infraestrutura na AWS	Amarração ao ecossistema AWS
TeamCity	Ferramenta da JetBrains	Times que já usam ferramentas JetBrains	Mantido pela empresa que publica a pesquisa acima

Os critérios que decidem a escolha são poucos:

1. Onde o código está. Se o repositório vive no GitHub, o Actions elimina uma integração inteira. Se vive no GitLab, o GitLab CI faz o mesmo. É o critério que mais pesa na pesquisa da JetBrains, e com razão.
2. Quem opera os runners. Serviço hospedado tira a manutenção da sua mão e cobra pelo uso. Instalação própria devolve o controle (e a conta de luz, as atualizações e o plantão).
3. Para qual nuvem o deploy vai. Ferramenta nativa do provedor de destino encurta a parte de implantação, ao custo de ficar presa a ele.
4. O que já existe. Uma empresa com centenas de jobs no Jenkins raramente migra tudo. Ela convive com dois sistemas por anos, e esse é o retrato que a pesquisa de 2025 mostra.

A comparação Jenkins versus GitLab é tão recorrente que virou tema de trabalho de conclusão de curso em universidade brasileira, com cinco critérios de avaliação. O que esses comparativos raramente capturam é o custo da migração em si. Quem já moveu um pipeline antigo para o Actions sabe que o YAML novo é a parte fácil. A parte difícil é descobrir o que os scripts shell de 2017 faziam de verdade.

Quanto custa implementar CI/CD em tempo, infraestrutura e equipe

Implementar CI/CD custa em três frentes: tempo de configuração e aprendizado, infraestrutura para executar e guardar o que o pipeline produz, e pessoas para manter a esteira e sustentar a disciplina de integrar todo dia. Não existe tabela pública de preço que sirva para qualquer empresa, e a frente mais cara quase nunca é a que aparece na fatura.

• Tempo. O primeiro workflow que roda build e testes leva horas. A curva real está depois: deixar os testes confiáveis, criar ambientes equivalentes e tratar cada falha do pipeline como bug de verdade, e isso se mede em semanas de atenção do time.
• Infraestrutura. Serviço hospedado cobra pelo tempo de execução dos runners, então pipeline lento custa dinheiro diretamente. Runner próprio troca essa conta por máquina, manutenção e atualização. Entram ainda o armazenamento de artefatos e imagens, que só cresce, e um ambiente de homologação que precisa parecer produção.
• Pessoas. Alguém mantém o pipeline, responde quando ele quebra e defende a regra de integrar ao menos uma vez por dia. Esse custo é salário e é cultura, e é o que mais falta quando o projeto para.

Os cenários mudam a proporção entre as três frentes:

Cenário	Onde o custo concentra	O que dá para adiar
Projeto pequeno, time de 2 a 5 pessoas	Tempo de quem monta o primeiro workflow	Runner próprio, múltiplos ambientes
Produto médio com homologação e produção	Ambientes equivalentes e testes de integração	Implantação contínua sem portão
Empresa com dezenas de times e legado	Pessoas dedicadas à plataforma e convivência de ferramentas	Migração completa de ferramenta

Quem desenha o pipeline deveria ser quem o opera depois, porque o custo de manutenção aparece em quem recebe o alerta às 3h. É a mesma regra que o time da AlphaCorp AI aplica a si mesmo: as pessoas que conversam com o cliente são as que constroem.

Segurança é item de orçamento, e desde 2023 há guia público para cobrar isso. A NIST SP 800-204D, com versão final publicada em 20/12/2023, recomenda atestação de software na etapa de build e princípios de zero trust no pipeline. A CISA e a NSA publicaram em 28/06/2023 um informe conjunto sobre defesa de ambientes de CI/CD, e o OWASP mantém desde setembro de 2022 a lista Top 10 de riscos de segurança em CI/CD, na versão 1.0. Cuidado com a numeração do NIST: a SP 800-204C, de março de 2022, trata de microsserviços com service mesh e é outro documento. Cada uma dessas recomendações vira horas de engenharia, e o orçamento que ignora essa linha paga por ela no primeiro incidente.

Por que pipelines de CI/CD falham e como evitar os erros mais comuns

Pipelines de CI/CD falham por motivos repetitivos: testes instáveis que o time aprende a ignorar, esteiras lentas que ninguém espera, branches longas que anulam a integração diária, ambientes que não se parecem, segredos vazados em log e dependências de terceiros que ninguém confere. Nenhum desses problemas é de ferramenta. Todos são de disciplina ou de desenho, e por isso trocar de ferramenta nunca os resolve.

Os erros de engenharia aparecem primeiro, e quase sempre nesta ordem:

• Teste flaky: um teste que passa e falha sem nenhuma mudança no código. Depois de três alarmes falsos, o time passa a clicar em “rodar de novo” e a esteira perde a única função que tinha, que era merecer confiança.
• Pipeline lento: se o feedback demora 40 minutos, as pessoas fazem commits maiores e mais raros para esperar menos vezes, e a integração deixa de ser contínua.
• Pipeline sem dono: o YAML foi escrito por quem já saiu da empresa, acumula steps que ninguém sabe para que servem e o time tem medo de mexer.
• Branch longa: semanas de trabalho isolado antes do merge. É o erro mais comum em time que “tem CI” e integra uma vez por sprint.
• Ambiente de teste diferente da produção: versão de banco, variável de ambiente, permissão de rede. O pipeline fica verde e o deploy quebra.

Como evitar? Trate falha de pipeline como bug com prioridade de produção, com dono e prazo. Teste flaky é consertado ou apagado na mesma semana, nunca silenciado. Tempo de execução é métrica acompanhada, e quando passa do limite combinado o time para e corta. E a regra de Fowler de integrar ao menos uma vez por dia vale mais que qualquer configuração de ferramenta.

Depois vêm as falhas de segurança, e aí o pipeline deixa de ser vítima e vira alvo. O OWASP Top 10 de riscos de segurança em CI/CD, na versão 1.0 de setembro de 2022, nasceu na Cider Security e foi doado à OWASP. As áreas de risco que a lista cobre incluem:

• código inseguro entrando no fluxo sem verificação
• poisoned pipeline execution, em que o atacante altera a própria definição da esteira para rodar o que quiser
• configuração errada de permissões e de acesso
• serviços de terceiros com mais acesso do que precisam
• segredos expostos em variáveis, logs e artefatos

O caso SolarWinds costuma ser citado como o exemplo de pipeline comprometido: a esteira de build distribuiu código malicioso aos clientes com a assinatura legítima do fornecedor.

A resposta do NIST, na SP 800-204D, é tratar o pipeline como ambiente de produção. Isso tem duas partes: atestar o software gerado em cada build, para que seja possível provar que o artefato saiu daquele código e daquela esteira, e aplicar zero trust, em que nenhum step, runner ou integração ganha confiança só por estar dentro da rede. Na prática, são credenciais de curta duração para cada job, permissão mínima para o token que publica o artefato, actions e dependências de terceiros fixadas em versão conferida, e segredo nunca impresso em log. O erro mais frequente é o oposto disso: um único token de administrador compartilhado por todos os workflows, porque na segunda-feira em que o pipeline foi montado era mais rápido assim.

CI/CD vale a pena para times pequenos e projetos iniciantes?

Vale a pena, desde que o time pequeno monte só a parte que se paga no primeiro dia: integração contínua mínima, com testes e lint rodando a cada push num único repositório. Isso leva uma tarde, custa pouco ou nada nos planos de entrada dos serviços hospedados e elimina o “funciona na minha máquina” antes que o time cresça o bastante para sofrer com ele.

O que pode esperar:

• Implantação contínua até a produção. Com duas pessoas e um produto sem usuário pagante, um deploy manual por dia é tolerável. Automatize quando a frequência de deploy começar a incomodar.
• Múltiplos ambientes. Homologação que imita produção custa infraestrutura e manutenção. Enquanto a produção inteira cabe numa instância, um ambiente de teste temporário por PR resolve.
• Runner próprio. O serviço hospedado sai mais barato que o tempo de alguém cuidando de máquina.

Quando a prática atrapalha mais que ajuda? Quando o time copia o pipeline de uma empresa grande antes de ter o que ele protege. Doze steps, três ambientes e um portão de aprovação para um protótipo com zero teste automatizado produzem uma esteira lenta que protege nada e que as pessoas contornam com push direto na main.

A revisão sistemática de 101 estudos sobre integração contínua, publicada no arXiv em 2021, traz o aviso que importa aqui: adotar um serviço de CI, por si só, deixa a entrega de pull requests no mesmo ritmo de antes. A velocidade vem de commits pequenos e frequentes, somados a testes em que o time confia. Um time de três pessoas consegue isso sem comprar nada, e um time de trezentas consegue perder isso com a melhor ferramenta do mercado.

O que mudou em CI/CD com IA e agentes de código em 2026

O que mudou em CI/CD com inteligência artificial (IA) foi o volume de código que chega ao pipeline: a maioria dos desenvolvedores já gera código com assistentes, enquanto a esteira que verifica esse código continua, na maior parte das empresas, sem IA nenhuma. Os dois números que descrevem essa tensão vêm de pesquisas de 2025.

90% dos profissionais de software dizem usar IA no trabalho, segundo o relatório DORA 2025, anunciado pelo Google Cloud em 23/09/2025, com quase 5.000 respondentes ouvidos entre 13/06 e 21/07/2025. O relatório trocou de nome: deixou de ser “Accelerate State of DevOps” e virou “State of AI-assisted Software Development”. A tese central, na página de pesquisa do DORA sobre IA, é que a IA age como amplificador. Ela aumenta os pontos fortes das organizações que já entregam bem e aprofunda as disfunções das que têm dificuldade.

73% dos respondentes não usam IA nos fluxos de CI/CD, segundo a pesquisa State of CI/CD 2025 da JetBrains, publicada em outubro de 2025.

Lidos juntos, os dois dados contam a história. A IA entrou na escrita do código e ficou fora da esteira que o valida, então mais código chega mais rápido a um pipeline desenhado para o ritmo de antes. O gargalo muda de lugar, e deixa de ser a digitação para virar a verificação.

Outras conclusões circulam em resumos e comentários do relatório, sem a mesma solidez: a associação entre uso de IA e aumento simultâneo de vazão e de instabilidade na entrega, e a ideia de que a revisão de código vira o novo gargalo. Fazem sentido dentro da tese do amplificador, mas quem for usar esses argumentos numa decisão de orçamento deve conferir o PDF completo do relatório antes de citar.

Na minha leitura, a tese do amplificador é a mais útil para quem opera pipeline em 2026. Se a esteira tem testes confiáveis e o time integra todo dia, o código gerado por IA chega, é testado e vai. Se tem teste flaky e branch longa, a IA só produz mais código para entrar na mesma fila. A ferramenta é indiferente ao estado do pipeline, e o pipeline é o que decide se o ganho vira entrega.

Perguntas frequentes sobre CI/CD

As dúvidas que mais aparecem na busca sobre CI/CD giram em torno de três confusões: o que a sigla inclui ou não, o que é preciso ter antes de começar e se a esteira é segura. As respostas curtas estão abaixo.

CI/CD é a mesma coisa que DevOps?

Não. CI/CD é um conjunto de práticas de engenharia (integrar o código todo dia, testar cada integração e manter o software pronto para liberar), enquanto DevOps é a cultura mais ampla de aproximar desenvolvimento e operação. Um artigo do CESJF/UniAcademia trata integração contínua, entrega contínua e feedback contínuo como pilares dessa cultura, o que ajuda a enxergar a relação: CI/CD é a parte do DevOps que vira pipeline.

Qual a diferença entre CI/CD e pipeline?

CI/CD é a prática. O pipeline é a implementação dela: a sequência automatizada de build, testes, empacotamento e deploy que um commit percorre. Dá para ter um pipeline sem praticar CI/CD, e isso é comum: a esteira roda, mas o time integra uma vez por sprint em branches longas, e a prática não existe.

Preciso de Docker ou Kubernetes para usar CI/CD?

Não para a integração contínua. Build e testes a cada push rodam em qualquer linguagem e em qualquer runner, com ou sem container. A arquitetura de referência do Google Cloud usa imagens de container e GKE porque o alvo é um cluster, e esse desenho faz sentido para serviços. Se o seu produto roda em duas VMs, o deploy por script continua sendo CI/CD.

CI/CD serve para aplicativo mobile?

Em parte. A integração contínua serve: build, testes e lint rodam a cada push como em qualquer projeto. A implantação contínua até o usuário final não se aplica, porque o app precisa ser instalado ou atualizado no aparelho, limite que o material de aula da USP sobre integração contínua aponta também para desktop e sistemas embarcados. O que dá para automatizar é a entrega até a loja ou até o canal de testes.

O que são as métricas DORA?

São cinco medidas do programa de pesquisa DORA, descritas na página oficial sobre a história das métricas, divididas em dois fatores: throughput (lead time de mudança, frequência de implantação e tempo de recuperação de implantação com falha) e instabilidade (taxa de falha de mudança e taxa de retrabalho de implantação). A própria página registra que o relatório de 2021 chamou erroneamente a confiabilidade de “quinta métrica”. Fontes secundárias discordam sobre o ano em que a taxa de retrabalho entrou na lista, então desconfie de quem afirmar uma data.

GitHub Actions é gratuito?

Depende do plano e do uso. O serviço cobra pelo tempo de execução dos runners hospedados, com uma cota de entrada que costuma bastar para projeto pequeno, e runners próprios não consomem essa cota. Os valores mudam com frequência e variam por tipo de conta e de repositório, então confira a tabela vigente na documentação do GitHub antes de orçar.

CI/CD é seguro?

É tão seguro quanto o pipeline for tratado como ambiente de produção. A esteira guarda credenciais de deploy, roda código de terceiros e assina artefatos, o que a torna alvo, e por isso o NIST, a CISA e a NSA publicaram guias próprios sobre o tema em 2023. O mínimo defensável tem quatro itens:

• credencial de curta duração e permissão mínima para cada job
• actions e dependências de terceiros fixadas em versão conferida
• segredo nunca impresso em log nem gravado em artefato
• definição do pipeline revisada por PR, como qualquer outro código

Por onde começar a montar seu primeiro pipeline de CI/CD

Comece pelo menor pipeline que entrega confiança: um repositório único, testes automatizados que o time respeita e um workflow que roda build e testes a cada push. Só depois disso faz sentido falar em deploy.

A sequência que funciona para um time que parte do zero:

1. Junte o código num único repositório e combine que todo mundo integra na branch principal pelo menos uma vez por dia.
2. Escreva ou organize os testes automatizados antes de ligar a esteira, porque pipeline sem teste só confirma que o código compila.
3. Crie um arquivo YAML em .github/workflows (ou o equivalente da sua ferramenta) com dois steps: build e testes, disparados por push e pull request.
4. Acrescente um deploy automático para um ambiente de teste e deixe-o rodar por semanas, até que as falhas sejam raras e compreendidas.
5. Só então coloque o portão manual antes da produção, e decida, com base no risco do seu sistema, se um dia ele sai.

Para aprofundar, a documentação do GitHub Actions explica workflows, jobs e steps, o whitepaper da AWS em português descreve as práticas de ponta a ponta, e o artigo de Martin Fowler sobre integração contínua, reescrito em 2023, continua sendo a referência para a disciplina por trás da ferramenta.

Se o seu time quer montar essa esteira sem trocar de ferramenta no meio do caminho, fale com a AlphaCorp AI sobre o primeiro pipeline.