Continuous Delivery (CD): o que é, diferença do Continuous Deployment

O que é Continuous Delivery

Continuous Delivery (CD) é uma extensão da Continuous Integration que adiciona automação para todas as etapas de preparação de lançamento: compilação da versão de lançamento, assinatura com certificados, ofuscação, verificação de metadados da loja de aplicativos e deploy em staging. O termo foi introduzido por Jez Humble e David Farley no livro “Continuous Delivery” (2010), onde formalizaram a prática que permite às equipes tornar os lançamentos previsíveis e de baixo risco.

Evolução da entrega de software

Antes da adoção de CD, os lançamentos eram um evento: a equipe se reunia em uma sala, seguia uma lista de verificação de 20 pontos, executava scripts manualmente e torcia para que nada quebrasse. Continuous Delivery transforma um lançamento de evento em processo: uma pequena alteração no código pode ser enviada aos usuários em minutos, não semanas. Amazon, Netflix e Etsy foram os primeiros a adotar CD nos anos 2010 — hoje é o padrão para equipes de produto.

Valor comercial do CD

A entrega rápida de funcionalidades é uma vantagem competitiva. Se um concorrente lança novas funcionalidades em dias enquanto você leva meses, o mercado escolhe o concorrente. As métricas DORA mostram: equipes elite (com CD) têm tempo de deploy inferior a 1 hora, equipes baixas (sem CD) — de 1 semana a 1 mês. O CD também reduz radicalmente o risco: mudanças pequenas são mais difíceis de quebrar coisas do que um grande lançamento trimestral.

CD vs CI vs Continuous Deployment

Os termos CI, CD e Continuous Deployment são frequentemente confundidos, mas há um limite claro entre eles. Entender as diferenças ajuda a projetar o pipeline corretamente e escolher o nível de automação que corresponde à maturidade da equipe e aos requisitos de negócio.

Continuous Integration

CI é a base sobre a qual o CD é construído. O CI garante que cada commit passe por compilação e testes. Sem CI, o CD é impossível: se o código não for verificado, não pode ser lançado. CI verifica a correção, o CD verifica a prontidão para uso comercial.

Continuous Delivery

O CD adiciona ao CI os estágios de compilação da versão de lançamento, verificação de metadados, assinatura e deploy em staging ou na loja de aplicativos para teste beta. A diferença chave — a decisão de lançar em produção é tomada por uma pessoa (gerente, product owner). O CD torna o lançamento “a um clique de distância” — simples e seguro.

Continuous Deployment

Continuous Deployment é automação completa: cada mudança que passa por todos os estágios do pipeline CD é enviada automaticamente para produção sem aprovação manual. Continuous Deployment é aplicável para produtos SaaS e serviços web, mas raramente é usado no desenvolvimento móvel devido às políticas das lojas de aplicativos (App Store Review, Google Play Review exige envio manual).

Continuous Delivery para aplicações móveis

CD para aplicações móveis tem características que o distinguem dos pipelines web e backend. Os lançamentos móveis passam por lojas de aplicativos (App Store Review, Google Play Review), o que adiciona uma barreira de tempo e processo. O CD automatiza tudo que pode ser automatizado antes do envio para revisão para maximizar a chance de passar na verificação na primeira tentativa.

Preparação para publicação no Google Play

O pipeline CD Android inclui: compilação de AAB (Android App Bundle), assinatura com chave de lançamento, ofuscação via R8/ProGuard, verificação de tamanho do APK e classes multidex, geração de notas de lançamento. O uso de product flavors do Gradle (free/paid, dev/staging/prod) permite gerenciar múltiplas configurações a partir de um único pipeline.

Preparação para publicação na App Store

O CD iOS requer assinatura com certificados via Fastlane match, verificação de conformidade dos ícones (exigência da App Store — 1024×1024 px), validação de metadados (nome, descrição, palavras-chave), verificação de ausência de APIs privadas. A validação técnica é realizada via altool --validate-app sem upload para o App Store Connect, o que fornece feedback rápido.

# Fastfile — pipeline CD completo para iOS e Android
platform :ios do
  desc "CD iOS — preparação do lançamento e upload para o TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "CD Android — compilação de AAB e upload para o Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight coleta capturas de tela, obtém certificados via match, compila IPA e envia para o TestFlight. A lane deliver_to_internal para Android compila Release AAB via Gradle e o envia para a trilha interna do Google Play Console. Ambos os pipelines são executados a partir do CI após a aprovação nos testes.

Componentes do pipeline CD

Um pipeline CD consiste em estágios sequenciais, cada um adicionando confiança de que o lançamento está pronto para os usuários. Os estágios são divididos em técnicos (compilação, assinatura) e de produto (metadados, capturas de tela, verificação de descrições). Pular qualquer estágio aumenta o risco de o lançamento ser rejeitado pela loja de aplicativos.

Gerenciamento de versões

Um componente crítico do CD é o gerenciamento automático de versões. O incremento de versão (versionCode e versionName para Android, CFBundleVersion e CFBundleShortVersionString para iOS) é realizado com base em tags Git ou na versão anterior na loja. Fastlane increment_version_number e comandos do Gradle (versionCode auto-increment) automatizam esta etapa.

Metadados da loja

Google Play Console e App Store Connect exigem: descrição do aplicativo, palavras-chave, categoria, classificação, links para política de privacidade. O CD inclui a verificação da presença e correção dos metadados. Fastlane deliver e supply automatizam o upload de descrições, capturas de tela e ícones junto com a compilação.

Verificações de gate

Antes de enviar para revisão, o pipeline realiza verificações de gate: verificação de tamanho da compilação (APK > 200 MB é rejeitado pelo Google Play), presença de todas as localizações, ausência de símbolos de debug na compilação de lançamento, verificação do arquivo de mapeamento ProGuard para decodificar logs de crash. Se alguma verificação falhar — o pipeline bloqueia o lançamento.

Testes automatizados para CD

O nível de confiança no CD é diretamente proporcional à qualidade dos testes automatizados. Se os testes não detectarem regressões — o lançamento pode quebrar a produção e a equipe perde a confiança no CD. O CD móvel requer uma pirâmide de testes de três níveis adaptada às especificidades da plataforma.

Testes unitários

Os testes unitários verificam a lógica de negócio de forma isolada. A cobertura de código deve ser de pelo menos 70% para módulos críticos (autenticação, pagamentos, rede). O CI executa testes unitários a cada push, e se falharem — o pipeline CD é bloqueado até a correção.

Testes de integração

Verificam a interação de componentes: camada de rede com API real (ou servidor mock), banco de dados, sistema de arquivos. Os testes Room DAO para Android, testes Core Data para iOS são exemplos de testes de integração. São mais lentos que os testes unitários (1–5 minutos) e executados na etapa de CD, não no CI a cada commit.

Testes de UI e capturas de tela

Testes de capturas de tela (snapshot testing) comparam as telas do aplicativo com imagens de referência. Se uma alteração de código mudou a UI — o teste falha e o desenvolvedor verifica se a alteração é esperada. Android suporta Roborazzi e Paparazzi, iOS — SnapshotTesting da Point-Free. Testes de capturas de tela são executados antes do lançamento como parte do pipeline CD.

Melhores práticas de Continuous Delivery

A implementação de Continuous Delivery requer não apenas ferramentas, mas também uma mudança na cultura da equipe. As práticas abaixo são baseadas em anos de experiência de equipes móveis do Google, Spotify e Uber e são adaptadas para projetos de qualquer tamanho.

Feature Flags

O código de uma nova funcionalidade é enviado para produção, mas oculto por trás de uma flag. Os Feature flags permitem implantar código antes que a funcionalidade esteja pronta para os usuários e desativá-la instantaneamente em caso de problemas. Bibliotecas: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags são um requisito obrigatório para CD em projetos móveis.

Ambiente de staging

Antes de enviar para produção, a compilação é implantada em staging — um ambiente idêntico à produção, mas com dados de teste. Engenheiros de QA verificam a funcionalidade em uma compilação de staging instalada via TestFlight ou trilha de Internal Testing. Se o staging passar — a compilação recebe aprovação para envio para revisão na loja.

Notas de lançamento e changelog

O CD gera automaticamente notas de lançamento com base nas mensagens de commit. Conventional Commits (feat:, fix:, chore:) e tags Git no formato de versionamento semântico permitem analisar o histórico de alterações. Fastlane changelog_from_git_commits coleta as alterações entre as duas últimas tags e as formata para a loja de aplicativos.

Monitoramento pós-lançamento

O CD não termina com a publicação — após o lançamento, começa o monitoramento: taxa de crashes, taxa ANR para Android, tempo de inicialização, taxa de falhas em pagamentos. Se as métricas ultrapassarem os limites normais — o pipeline CD deve reverter automaticamente o lançamento ou notificar a equipe. Ferramentas: Firebase Crashlytics, Sentry, New Relic.

// Exemplo de Feature Flag com Firebase Remote Config para CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Uso no código
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}