O que é 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

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:

# 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 / 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 — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}

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

// 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

A linhagem merece uma frase: o artigo canônico de Martin Fowler 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 — 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

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ó.