{"id":1901,"date":"2026-02-10T07:54:00","date_gmt":"2026-02-10T10:54:00","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1901"},"modified":"2026-05-10T23:16:04","modified_gmt":"2026-05-11T02:16:04","slug":"do-commit-ao-deploy-entendenda-o-que-sao-continuous-integration-continuous-testing-continuous-delivery-e-continuous-deployment","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/do-commit-ao-deploy-entendenda-o-que-sao-continuous-integration-continuous-testing-continuous-delivery-e-continuous-deployment\/","title":{"rendered":"Do Commit ao Deploy: entendenda o que s\u00e3o Continuous Integration, Continuous Testing, Continuous Delivery e Continuous Deployment"},"content":{"rendered":"\n

Se voc\u00ea trabalha com desenvolvimento de software h\u00e1 algum tempo, j\u00e1 ouviu falar em CI\/CD. O problema \u00e9 que esse termo agrupa conceitos distintos que muita gente confunde \u2014 e a confus\u00e3o come\u00e7a j\u00e1 na sigla. CI\/CD pode significar coisas diferentes dependendo de quem est\u00e1 falando: \u00e0s vezes \u00e9 Continuous Integration com Continuous Delivery, \u00e0s vezes com Continuous Deployment. S\u00e3o pr\u00e1ticas relacionadas mas com implica\u00e7\u00f5es bem diferentes para o time e para o neg\u00f3cio.<\/p>\n\n

Nesse post a gente vai destrinchar cada uma dessas pr\u00e1ticas, entender onde come\u00e7a e onde termina cada fase do pipeline e deixar claro de uma vez por todas qual \u00e9 a diferen\u00e7a entre Delivery e Deployment.<\/p>\n\n

Continuous Integration \u2014 a base de tudo<\/h2>\n\n

A Integra\u00e7\u00e3o Cont\u00ednua<\/strong> \u2014 ou CI<\/strong>, do ingl\u00eas Continuous Integration<\/em> \u2014 \u00e9 a pr\u00e1tica de integrar as mudan\u00e7as de c\u00f3digo de todos os desenvolvedores do time em um reposit\u00f3rio compartilhado com frequ\u00eancia, v\u00e1rias vezes ao dia se poss\u00edvel. Cada vez que algu\u00e9m faz um commit<\/em>, um servidor de CI automaticamente constr\u00f3i a aplica\u00e7\u00e3o e executa os testes.<\/p>\n\n

O objetivo \u00e9 simples: descobrir problemas o mais cedo poss\u00edvel, enquanto o contexto ainda est\u00e1 fresco e a corre\u00e7\u00e3o ainda \u00e9 barata. Um bug encontrado minutos depois do commit<\/em> leva minutos para ser corrigido. O mesmo bug encontrado duas semanas depois, quando o c\u00f3digo j\u00e1 foi integrado com o trabalho de outros cinco desenvolvedores, pode levar dias.<\/p>\n\n

Na pr\u00e1tica, um pipeline de CI faz basicamente isso: detecta o commit<\/em> no reposit\u00f3rio, baixa o c\u00f3digo, instala as depend\u00eancias, compila a aplica\u00e7\u00e3o e executa os testes unit\u00e1rios. Se qualquer etapa falhar, o time \u00e9 notificado imediatamente. O resultado de cada build<\/em> fica vis\u00edvel para todos \u2014 o que cria transpar\u00eancia e responsabilidade compartilhada sobre a sa\u00fade do c\u00f3digo.<\/p>\n\n

Um ponto importante: CI sozinha n\u00e3o inclui deploy<\/em> em produ\u00e7\u00e3o. Ela garante que o c\u00f3digo compila e passa nos testes. O que acontece depois disso \u00e9 responsabilidade das pr\u00e1ticas que v\u00eam a seguir.<\/p>\n\n

Continuous Testing \u2014 qualidade em cada etapa<\/h2>\n\n

O Teste Cont\u00ednuo<\/strong> \u2014 CT<\/strong>, de Continuous Testing<\/em> \u2014 \u00e9 muitas vezes tratado como parte impl\u00edcita do CI, mas merece aten\u00e7\u00e3o pr\u00f3pria porque vai muito al\u00e9m dos testes unit\u00e1rios que rodam no build<\/em> inicial.<\/p>\n\n

A ideia \u00e9 que testes automatizados estejam presentes em cada etapa do pipeline, n\u00e3o s\u00f3 na integra\u00e7\u00e3o. Testes unit\u00e1rios rodam no commit<\/em>. Testes de integra\u00e7\u00e3o rodam quando o c\u00f3digo chega ao ambiente de homologa\u00e7\u00e3o. Testes de aceita\u00e7\u00e3o verificam se o comportamento do sistema atende aos crit\u00e9rios definidos pelo neg\u00f3cio. Testes de performance detectam regress\u00f5es antes que cheguem \u00e0 produ\u00e7\u00e3o.<\/p>\n\n

O Continuous Testing muda a mentalidade do time: qualidade deixa de ser uma fase no final do processo e passa a ser uma propriedade verificada continuamente ao longo de todo o pipeline. Isso tem uma consequ\u00eancia pr\u00e1tica importante \u2014 quanto mais cedo um tipo de falha \u00e9 detectado, mais barato \u00e9 corrigi-la. Um teste de integra\u00e7\u00e3o que falha em homologa\u00e7\u00e3o \u00e9 muito menos custoso do que um problema de integra\u00e7\u00e3o descoberto em produ\u00e7\u00e3o.<\/p>\n\n

A cobertura de testes tamb\u00e9m entra aqui. Um servidor de CI bem configurado monitora a porcentagem de c\u00f3digo coberta por testes e alerta quando um commit<\/em> reduz essa cobertura. Com o tempo, ver a cobertura crescendo vira um motivador natural para o time escrever mais testes.<\/p>\n\n

Continuous Delivery \u2014 sempre pronto para ir a produ\u00e7\u00e3o<\/h2>\n\n

A Entrega Cont\u00ednua<\/strong> \u2014 CD<\/strong>, de Continuous Delivery<\/em> \u2014 \u00e9 o passo seguinte \u00e0 Integra\u00e7\u00e3o Cont\u00ednua. A ideia central \u00e9 que o software esteja sempre em um estado deploy\u00e1vel<\/em> \u2014 ou seja, que a qualquer momento seja poss\u00edvel colocar a vers\u00e3o atual em produ\u00e7\u00e3o com confian\u00e7a.<\/p>\n\n

Para isso, al\u00e9m de compilar e testar o c\u00f3digo, o pipeline de Continuous Delivery automatiza tamb\u00e9m a entrega at\u00e9 ambientes de pr\u00e9-produ\u00e7\u00e3o: homologa\u00e7\u00e3o, staging<\/em>, ambientes de teste de aceita\u00e7\u00e3o. O c\u00f3digo passa por todas essas etapas de forma autom\u00e1tica. O que n\u00e3o \u00e9 autom\u00e1tico no Continuous Delivery \u00e9 o deploy<\/em> final em produ\u00e7\u00e3o \u2014 esse passo \u00e9 deliberadamente manual e acionado por uma decis\u00e3o humana.<\/p>\n\n

Isso pode parecer uma limita\u00e7\u00e3o, mas \u00e9 uma escolha estrat\u00e9gica. Nem toda empresa tem condi\u00e7\u00f5es de ou interesse em colocar c\u00f3digo em produ\u00e7\u00e3o dezenas de vezes por dia. O Continuous Delivery garante que quando a decis\u00e3o de ir a produ\u00e7\u00e3o for tomada \u2014 seja por uma janela de manuten\u00e7\u00e3o, por uma aprova\u00e7\u00e3o de neg\u00f3cio ou por qualquer outro crit\u00e9rio \u2014 o processo seja r\u00e1pido, confi\u00e1vel e sem surpresas. O bot\u00e3o existe. Algu\u00e9m tem que apertar.<\/p>\n\n

Continuous Deployment \u2014 do commit ao usu\u00e1rio sem interven\u00e7\u00e3o humana<\/h2>\n\n

O Deployment Cont\u00ednuo<\/strong> \u2014 tamb\u00e9m abreviado como CD, de Continuous Deployment<\/em> \u2014 \u00e9 a evolu\u00e7\u00e3o natural do Continuous Delivery. A diferen\u00e7a \u00e9 uma s\u00f3, mas \u00e9 fundamental: n\u00e3o existe o passo manual de aprova\u00e7\u00e3o para produ\u00e7\u00e3o. Todo commit<\/em> que passa por todas as etapas do pipeline vai automaticamente para produ\u00e7\u00e3o.<\/p>\n\n\"Diagrama\n\n

No Continuous Delivery, a implanta\u00e7\u00e3o em produ\u00e7\u00e3o requer aprova\u00e7\u00e3o manual \u2014 representada pela etiqueta vermelha no diagrama. No Continuous Deployment, todas as etapas s\u00e3o autom\u00e1ticas, do teste unit\u00e1rio at\u00e9 os testes p\u00f3s-implanta\u00e7\u00e3o em produ\u00e7\u00e3o.<\/p>\n\n

Isso significa que em um time que pratica Continuous Deployment, um desenvolvedor pode fazer um commit<\/em> \u00e0s 9h e ver aquela mudan\u00e7a rodando em produ\u00e7\u00e3o para usu\u00e1rios reais \u00e0s 9h05, sem precisar falar com ningu\u00e9m. Isso s\u00f3 \u00e9 poss\u00edvel porque a confian\u00e7a no pipeline de testes \u00e9 alta o suficiente para que a automa\u00e7\u00e3o substitua a aprova\u00e7\u00e3o humana.<\/p>\n\n

Continuous Deployment n\u00e3o \u00e9 para todo mundo. Exige maturidade t\u00e9cnica elevada, cobertura de testes robusta e uma cultura de times que aceita a responsabilidade de que cada commit<\/em> pode ir a produ\u00e7\u00e3o. Mas para quem chega l\u00e1, o ganho em velocidade de entrega de valor para o usu\u00e1rio \u00e9 substancial.<\/p>\n\n

O pipeline completo na pr\u00e1tica<\/h2>\n\n

Juntando tudo, o pipeline de um time maduro em CI\/CD tem mais ou menos essa progress\u00e3o:<\/p>\n\n

Um desenvolvedor faz um commit<\/em> no reposit\u00f3rio. O servidor de CI detecta a mudan\u00e7a, compila o c\u00f3digo e executa os testes unit\u00e1rios \u2014 isso \u00e9 Continuous Integration<\/strong>. Se passar, testes de integra\u00e7\u00e3o e de aceita\u00e7\u00e3o s\u00e3o executados automaticamente em ambientes controlados \u2014 isso \u00e9 Continuous Testing<\/strong>. O c\u00f3digo \u00e9 automaticamente promovido para homologa\u00e7\u00e3o e validado l\u00e1 \u2014 isso \u00e9 Continuous Delivery<\/strong>. Se o time pratica Continuous Deployment<\/strong>, a pr\u00f3xima etapa \u00e9 produ\u00e7\u00e3o, tamb\u00e9m autom\u00e1tica. Se pratica Continuous Delivery, algu\u00e9m aperta o bot\u00e3o quando o momento \u00e9 certo.<\/p>\n\n

Cada etapa tem um prop\u00f3sito e um custo diferente de falha. Quanto mais cedo um problema \u00e9 detectado no pipeline, mais barato \u00e9 corrigi-lo. A l\u00f3gica de todo esse investimento em automa\u00e7\u00e3o \u00e9 exatamente essa: deslocar a descoberta de problemas para o mais pr\u00f3ximo poss\u00edvel do momento em que o c\u00f3digo foi escrito.<\/p>\n\n

Continuous Delivery ou Continuous Deployment \u2014 qual escolher?<\/h2>\n\n

A resposta depende do contexto do seu produto e da maturidade do seu time.<\/p>\n\n

Continuous Delivery faz sentido quando existe uma necessidade real de controle sobre o que vai para produ\u00e7\u00e3o e quando \u2014 seja por requisitos regulat\u00f3rios, por janelas de manuten\u00e7\u00e3o acordadas com clientes, ou simplesmente porque o produto ainda est\u00e1 em um est\u00e1gio onde a valida\u00e7\u00e3o humana agrega valor real antes de cada deploy<\/em>.<\/p>\n\n

Continuous Deployment faz sentido quando o time tem confian\u00e7a alta no pipeline de testes, quando o produto suporta deploys<\/em> frequentes sem impacto negativo para o usu\u00e1rio e quando a velocidade de entrega de valor \u00e9 uma vantagem competitiva real para o neg\u00f3cio.<\/p>\n\n

O que n\u00e3o faz sentido \u00e9 confundir os dois conceitos e achar que est\u00e1 praticando Continuous Deployment quando na verdade est\u00e1 fazendo Continuous Delivery \u2014 ou vice-versa. S\u00e3o estrat\u00e9gias diferentes, com implica\u00e7\u00f5es diferentes para processos, ferramentas e cultura de time.<\/p>\n\n

O mais importante \u00e9 que qualquer um dos dois \u00e9 infinitamente melhor do que nenhum. Um time que pratica Continuous Delivery consistentemente entrega software com mais qualidade, mais previsibilidade e menos estresse do que um time que ainda faz deploys<\/em> manuais, pontuais e cheios de cerim\u00f4nia.<\/p>\n\n

Treinamentos relacionados com essa postagem<\/h2>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n \n<\/a>\n\n\n","protected":false},"excerpt":{"rendered":"

Se voc\u00ea trabalha com desenvolvimento de software h\u00e1 algum tempo, j\u00e1 ouviu falar em CI\/CD. O problema \u00e9 que esse termo agrupa conceitos distintos que muita gente confunde \u2014 e a confus\u00e3o come\u00e7a j\u00e1 na sigla. CI\/CD pode significar coisas diferentes dependendo de quem est\u00e1 falando: \u00e0s vezes \u00e9 Continuous Integration com Continuous Delivery, \u00e0s […]<\/p>\n","protected":false},"author":1,"featured_media":1936,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[354,295,30],"tags":[310,416,417,415,418,421,419,302,420,300],"_links":{"self":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1901"}],"collection":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1901"}],"version-history":[{"count":4,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1901\/revisions"}],"predecessor-version":[{"id":1935,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/posts\/1901\/revisions\/1935"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media\/1936"}],"wp:attachment":[{"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1901"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1901"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.erudio.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1901"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}