---
term: 'CI/CD (Integração & Entrega Contínuas)'
seoTitle: 'O que é CI/CD? Integração e Entrega Contínuas Explicadas'
headline: 'O que é CI/CD?'
slug: ci-cd
category: cloud-architecture
shortDefinition: 'CI/CD é uma prática que automatiza build, testes e lançamento de código, para que cada mudança vá do commit à produção em pequenos passos.'
relatedTerms:
  - no-ops-development
  - containerization
  - kubernetes
  - backend-boilerplate-code
  - cloud-code-serverless-functions
contrastsWith:
  - no-ops-development
faq:
  - question: 'O que significa CI/CD?'
    answer: 'Continuous Integration e Continuous Delivery — integração contínua e entrega contínua — com uma ambiguidade embutida que todo praticante deveria conhecer: o "CD" também pode significar deploy contínuo (continuous deployment). A entrega mantém uma aprovação humana antes da produção; o deploy a remove. Quando alguém diz "fazemos CI/CD", a pergunta útil é sempre: qual dos dois CDs?'
  - question: 'O que é integração contínua?'
    answer: 'A prática de mesclar mudanças pequenas em uma mainline compartilhada com frequência — pelo menos diariamente, na definição canônica — com cada merge disparando build e testes automatizados. O ponto é feedback rápido: problemas de integração aparecem minutos depois de serem criados, e não semanas depois, no aperto de um release.'
  - question: 'Qual a diferença entre entrega contínua e deploy contínuo?'
    answer: 'Um passo de aprovação manual. Na entrega contínua, toda mudança é automaticamente construída, testada e mantida pronta para release, mas um humano decide quando a produção de fato atualiza. No deploy contínuo não há gate: toda mudança que passa pelo pipeline vai ao ar automaticamente, e só um teste falhando a detém.'
  - question: 'O que é um pipeline de CI/CD?'
    answer: 'O fluxo automatizado que uma mudança percorre do commit à produção: gatilho no código-fonte, build, testes automatizados, entrega a um ambiente de staging e deploy. Cada estágio precisa passar antes de o próximo rodar, então o pipeline age como um gate de qualidade que toda mudança atravessa do mesmo jeito — sem casos especiais, sem heroísmo de deploy.'
  - question: 'O que são as métricas DORA?'
    answer: 'O jeito padrão da indústria de medir performance de entrega, vindo do programa de pesquisa DORA: frequência de deploy, lead time das mudanças, taxa de falha das mudanças, tempo de recuperação de deploys falhos e — adicionada mais recentemente — taxa de retrabalho de deploy. O achado mais citado da pesquisa é que velocidade e estabilidade não são um trade-off: os melhores times pontuam alto nas duas.'
  - question: 'CI/CD é a mesma coisa que DevOps?'
    answer: 'Não — DevOps é a cultura mais ampla de unificar desenvolvimento e operações; CI/CD é sua espinha dorsal de automação. Dá para adotar o ferramental de CI/CD sem a cultura (ajuda menos do que se espera) e pregar a cultura sem a automação (muda menos do que se promete). As práticas se reforçam, mas nomeiam coisas diferentes.'
  - question: 'Quais testes rodam em um pipeline de CI/CD?'
    answer: 'Em camadas, por velocidade: testes unitários e análise estática rodam a cada commit porque são rápidos; testes de integração verificam componentes contra dependências reais; end-to-end, performance e varreduras de segurança rodam em estágios posteriores ou agendados, porque são lentos. A regra de projeto: quanto mais rápido o feedback, mais cedo o estágio.'
  - question: 'Times pequenos precisam de CI/CD?'
    answer: 'Precisam mais da prática do que do encanamento. Até um time de duas pessoas se beneficia de testes automatizados a cada mudança e de deploys de um comando — isso já é CI/CD em substância. O que times pequenos devem evitar é operar infraestrutura pesada de pipeline; runners hospedados ou plataformas com deploy embutido reduzem a prática a configuração.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Continuous Integration — Martin Fowler (updated 2024)'
    url: 'https://martinfowler.com/articles/continuousIntegration.html'
  - name: 'Continuous Delivery — Martin Fowler'
    url: 'https://martinfowler.com/bliki/ContinuousDelivery.html'
  - name: 'DORA metrics guide (dora.dev)'
    url: 'https://dora.dev/guides/dora-metrics-four-keys/'
  - name: 'CI/CD (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/CI/CD'
cta:
  title: 'Deploy sem o encanamento do pipeline'
  text: 'O Back4app colapsa a metade de entrega do CI/CD: funções de Cloud Code entram no ar com um comando de CLI ou direto de um repositório Git, com banco de dados, autenticação e APIs já em produção. Mantenha seus testes; dispense a fazenda de runners.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-24'
translationKey: ci-cd
---

**CI/CD é uma prática que automatiza build, testes e lançamento de código, para que cada mudança vá do commit à produção em pequenos passos.** O nome comprime duas ideias — integração contínua (mesclar e verificar constantemente) e entrega contínua (manter cada mudança pronta para lançar) — mais uma ambiguidade famosa: o segundo "D" também pode significar *deploy* contínuo, em que nada além de um teste falhando separa um commit da produção.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O que é | Automação que transforma o "dia do release" em um não-evento que acontece o tempo todo |
| CI | Mesclar mudanças pequenas diariamente; cada merge dispara build e testes automaticamente |
| Os dois CDs | A entrega mantém uma aprovação humana antes da produção; o deploy a remove |
| Por que funciona | Mudanças pequenas falham pequeno; feedback rápido pega bugs minutos após serem criados |
| Como se mede | As cinco métricas DORA — e velocidade e estabilidade sobem juntas |

## Como é um pipeline na prática

A prática inteira cabe em um arquivo de configuração — este é o artefato que toda página de "CI/CD explicado" descreve e quase nenhuma mostra:

```yaml
# pipeline.yml — a automação que substitui o "dia do deploy"
on: push to main

jobs:
  build:
    steps:
      - checkout
      - run: npm ci && npm run build
  test:
    needs: build
    steps:
      - run: npm test            # unitários + integração, a cada commit
      - run: npm run lint        # análise estática
  deploy:
    needs: test
    approval: manual             # apague esta linha → deploy contínuo
    steps:
      - run: npm run deploy
```

Minutos depois de aquele último passo rodar, todos os clientes já estão chamando a nova versão do backend — que é exatamente o ponto:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
  if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}
```

## CI vs. entrega contínua vs. deploy contínuo

| Dimensão | Integração contínua | Entrega contínua | Deploy contínuo |
| --- | --- | --- | --- |
| Escopo | Merge + build + testes | …mais artefatos sempre prontos para release | …mais release automático |
| Gatilho | Cada commit na mainline | Cada build que passa | Cada build que passa |
| Gate humano | Nenhum (os testes são o gate) | **Sim — uma aprovação de release** | **Nenhum** |
| Produção atualiza | Quando alguém lança | Quando alguém clica | Continuamente |
| Melhor para | Todo mundo | Releases regulados, lançamentos com data de marketing | Backends web, SaaS, suítes de teste de alta confiança |

```mermaid
flowchart LR
  accTitle: Um pipeline de CI/CD
  accDescr: Commits disparam estágios automatizados de build e teste; mudanças aprovadas chegam ao staging e então cruzam um gate de aprovação manual, na entrega contínua, ou nenhum gate, no deploy contínuo, até a produção.
  A[Commit] --> B[Build] --> C[Testes automatizados] --> D[Staging]
  D --> E{Aprovação manual?}
  E -- "sim — entrega contínua" --> F[Produção]
  E -- "sem gate — deploy contínuo" --> F
```

A linhagem merece uma frase: o [artigo canônico de Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html) definiu a CI em 2000, o livro de 2010 *Continuous Delivery* estendeu a ideia ao processo de release, e o DevOps fez do par sua espinha dorsal de automação. Uma aresta afiada de Fowler ainda corta hoje: rodar um servidor de build contra feature branches de vida longa é "semi-integração" — CI de verdade significa a mainline integrando o trabalho de todo mundo pelo menos uma vez por dia.

## O pipeline, estágio por estágio

- **Fonte.** Um commit ou merge dispara tudo. Nunca builds manuais — se não foi disparado, não é CI.
- **Build.** Compilar, resolver dependências, produzir o artefato (bundle, imagem de contêiner) que todos os estágios seguintes reutilizam — build uma vez, promova em todo lugar.
- **Teste.** Checagens rápidas primeiro: testes unitários e lint a cada commit; testes de integração contra dependências reais em seguida; end-to-end, performance e varreduras de segurança em execuções posteriores ou agendadas. A velocidade do feedback decide a ordem dos estágios.
- **Entrega.** O artefato pousa em um ambiente de staging parecido com produção. Na entrega contínua, ele espera ali — pronto para release — por um sim humano.
- **Deploy.** Produção. Pipelines maduros fazem deploy gradual — uma fatia canário ou um ambiente blue/green paralelo — para que uma mudança ruim seja um rollback contido, não uma indisponibilidade.

## Como medir: as métricas DORA

"Somos bons em entrega?" tem uma resposta padrão: as [cinco métricas do programa de pesquisa DORA](https://dora.dev/guides/dora-metrics-four-keys/) — frequência de deploy, lead time das mudanças, taxa de falha das mudanças, tempo de recuperação de deploys falhos e taxa de retrabalho de deploy. O achado mais citado da pesquisa é que o clássico trade-off velocidade-versus-estabilidade é falso: os times que mais fazem deploy são também os que menos quebram, porque mudanças pequenas e frequentes são individualmente de baixo risco e rápidas de diagnosticar. Se o seu trabalho no pipeline não move uma das cinco, é encanamento, não progresso.

## Casos de uso comuns

- **Backends web e de API** — o lar natural do deploy contínuo pleno: alto volume de mudanças, rollback instantâneo, nenhum passo de instalação.
- **Apps mobile** — CI mais *entrega* contínua: o pipeline constrói, testa e prepara cada mudança, enquanto a revisão das lojas torna o empurrão final inerentemente gateado.
- **Times crescendo além de um único deployer** — o pipeline substitui a única pessoa que "sabe fazer o release" por um processo que qualquer um executa.
- **Ambientes regulados** — o gate de aprovação vira uma feature: automação total até a linha, uma decisão humana auditável sobre ela.
- **Projetos open source** — cada pull request construído e testado automaticamente é a CI servindo de porta de entrada do projeto.

## Você deveria manter um gate antes da produção? Matriz de decisão

| Escolha deploy contínuo quando… | Mantenha o gate de entrega quando… |
| --- | --- |
| A suíte de testes tem a confiança da produção | A cobertura de testes ainda está crescendo até merecer essa confiança |
| Rollback é um comando | Rollback é um projeto |
| Usuários esperam atualizações invisíveis e constantes | Releases se alinham a datas de marketing ou de contrato |
| O produto é um backend web ou SaaS | O produto passa pela revisão das lojas de aplicativos |
| Falhas degradam graciosamente atrás de feature flags | Um release ruim tem consequências regulatórias |

O sequenciamento honesto: conquiste o deploy praticando a entrega — automatize tudo até o gate, observe a taxa de falhas e remova o gate quando ele não estiver mais fazendo nada.

## Limitações e trade-offs

- **O pipeline é código seu.** Runners, YAML, caches, secrets — tudo isso precisa de manutenção, e em certos tamanhos de time o pipeline vira um produto próprio, com plantão próprio.
- **Testes flaky envenenam tudo.** Uma suíte que falha aleatoriamente treina as pessoas a clicar em "retry", o que converte silenciosamente o deploy contínuo de volta em deploy manual com passos extras.
- **Cultura é pré-requisito, não subproduto.** Merges pequenos, desenvolvimento na mainline e consertar builds vermelhos imediatamente são hábitos; comprar um pipeline não os instala.
- **Velocidade sem observabilidade é aposta.** Fazer deploy o tempo todo só é seguro se você enxerga falhas rápido — monitoramento e alertas fazem parte da prática, não são um adendo.
- **A última milha varia.** Bancos de dados, migrações e serviços stateful resistem ao "é só redeployar"; o pipeline precisa de estratégias (migrações expand-contract, feature flags) que nenhum YAML escreve por você.

## CI/CD no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seu efeito sobre o CI/CD é subtração no lado da entrega: o Cloud Code faz deploy em um comando de CLI ou direto de um repositório Git, e o backend padrão — banco de dados, autenticação, APIs — nunca aparece no seu pipeline, porque não há nada para buildar ou lançar. O que sobra é a metade que você deveria manter: seus testes, rodando a cada commit, na frente de um passo de deploy que agora tem uma linha só.