Continuous Delivery (CD) e Continuous Deployment são práticas essenciais em DevOps que automatizam o processo de entrega de software, mas com diferenças cruciais no momento da liberação para produção. Enquanto a Entrega Contínua garante que o software esteja sempre pronto para ser implantado, a Implantação Contínua leva essa automação ao extremo, promovendo cada mudança aprovada diretamente para produção. Nesta aula, vamos explorar essas diferenças, os gates manuais envolvidos e como decidir qual abordagem adotar.

Continuous Delivery vs Deployment

Continuous Delivery (Entrega Contínua) é uma prática onde o código é automaticamente construído, testado e preparado para lançamento em produção, mas a implantação final requer aprovação manual. O pipeline produz artefatos prontos para deploy, que podem ser liberados a qualquer momento com um clique. Isso combina automação com controle humano, permitindo que as equipes decidam quando liberar novas funcionalidades.

Continuous Deployment (Implantação Contínua) vai um passo além: toda alteração que passa nos testes automatizados é automaticamente implantada em produção. Não há intervenção manual; o pipeline é totalmente automatizado. Isso acelera o feedback e reduz o tempo de entrega, mas exige uma suíte de testes robusta e monitoramento constante para evitar que bugs cheguem aos usuários.

Exemplo de pipeline para Continuous Delivery:

# Pipeline CI/CD simplificado (Entrega Contínua)
1. Commit -> Build -> Testes unitários -> Testes de integração -> Testes de aceitação
2. Artefato gerado e armazenado (ex: imagem Docker)
3. Gate manual: aprovação para deploy em produção
4. Deploy automatizado (após aprovação)

Exemplo de pipeline para Continuous Deployment:

# Pipeline CI/CD (Implantação Contínua)
1. Commit -> Build -> Testes unitários -> Testes de integração -> Testes de aceitação
2. Deploy automatizado para produção (sem gates manuais)

Diferenças

As principais diferenças entre as duas práticas estão no nível de automação e no controle sobre o lançamento. No Continuous Delivery, a implantação em produção requer uma decisão manual, geralmente após validações adicionais (como testes manuais ou aprovação de negócios). Já no Continuous Deployment, a implantação é automática, confiando totalmente nos testes automatizados.

Outra diferença é o risco percebido: Continuous Deployment é mais arriscado, pois qualquer falha nos testes pode ir para produção rapidamente. Continuous Delivery oferece uma camada extra de segurança, permitindo que as equipes revisem mudanças antes de liberá-las. No entanto, Continuous Deployment reduz o tempo de entrega e força a equipe a ter testes de alta qualidade.

Comparação em tabela conceitual:

+----------------------------+----------------------+------------------------+
| Característica             | Continuous Delivery  | Continuous Deployment |
+----------------------------+----------------------+------------------------+
| Implantação automática?    | Sim, mas com gate    | Sim, total            |
| Aprovação manual?          | Sim (antes do deploy)| Não                   |
| Risco de bugs em produção? | Menor (com revisão)  | Maior (automatizado)  |
| Velocidade de entrega      | Moderada             | Alta                  |
| Exigência de testes        | Alta                 | Muito alta            |
+----------------------------+----------------------+------------------------+

Gates manuais

Gates manuais são pontos de verificação onde uma decisão humana interrompe o pipeline. No Continuous Delivery, o gate principal é antes da implantação em produção. Pode ser uma aprovação de um líder técnico, product owner ou equipe de QA. Esses gates permitem:

  • Revisão de mudanças em ambientes de staging
  • Testes manuais exploratórios
  • Verificação de conformidade com políticas de negócio
  • Coordenação com lançamentos de marketing

Exemplo de implementação de gate manual com Jenkins:

# Estágio do pipeline com input manual
pipeline {
    agent any
    stages {
        stage('Build & Test') {
            steps {
                sh 'make build'
                sh 'make test'
            }
        }
        stage('Deploy to Staging') {
            steps {
                sh 'deploy staging'
            }
        }
        stage('Approval Gate') {
            input {
                message "Aprovar deploy para produção?"
                ok "Sim"
                submitter "admin,tech-lead"
            }
            steps {
                echo "Deploy aprovado"
            }
        }
        stage('Deploy to Production') {
            steps {
                sh 'deploy production'
            }
        }
    }
}

No Continuous Deployment, não há gates manuais; o pipeline é totalmente automatizado. No entanto, é comum ter gates automatizados, como testes de canary ou feature flags, que permitem reverter rapidamente se algo der errado.

Quando usar cada um

Continuous Delivery é ideal quando:

  • O negócio exige controle sobre o momento do lançamento (ex: versões sazonais)
  • Há requisitos regulatórios que exigem aprovação humana
  • A equipe ainda não tem confiança total na suíte de testes
  • O produto tem muitos stakeholders que precisam validar mudanças

Continuous Deployment é mais adequado quando:

  • A equipe tem maturidade em testes automatizados e monitoramento
  • O produto é digital e precisa de iterações rápidas (ex: SaaS)
  • O feedback do usuário é crítico e deve ser obtido rapidamente
  • A cultura DevOps está madura, com deploy frequente e reversões rápidas

Muitas equipes começam com Continuous Delivery e evoluem para Continuous Deployment conforme ganham confiança. Ferramentas como feature flags permitem implantar continuamente, mas liberar funcionalidades gradualmente, combinando benefícios de ambos.

Boas práticas

  • Invista em testes automatizados (unitários, integração, aceitação) para sustentar qualquer abordagem.
  • Implemente monitoramento e alertas para detectar problemas rapidamente.
  • Use deploy progressivo (canary, blue-green) para reduzir riscos.
  • Documente claramente os critérios para aprovação manual (se houver).
  • Reavalie periodicamente a estratégia conforme a equipe amadurece.

Referências

Exercícios

  1. Explique com suas palavras a principal diferença entre Continuous Delivery e Continuous Deployment.

    2. ✓ Resposta: A principal diferença é que no Continuous Delivery a implantação em produção requer uma aprovação manual (gate), enquanto no Continuous Deployment toda mudança aprovada nos testes é automaticamente implantada, sem intervenção humana.
  2. Cite duas situações em que o uso de Continuous Delivery é mais recomendado que o Continuous Deployment.

    3. ✓ Resposta: 1) Quando existem requisitos regulatórios que exigem aprovação humana antes de liberar software em produção. 2) Quando a equipe ainda não possui confiança total na suíte de testes automatizados.
  3. No contexto de um pipeline Jenkins, como você implementaria um gate manual para aprovação antes do deploy em produção? Escreva um trecho de código declarativo.

    4. ✓ Resposta: 
    stage('Approval Gate') {
    input {
        message "Aprovar deploy para produção?"
        ok "Sim"
        submitter "admin,tech-lead"
    }
    steps {
        echo "Deploy aprovado"
    }
}
  4. Por que o Continuous Deployment exige uma suíte de testes mais robusta que o Continuous Delivery?

    5. ✓ Resposta: Porque no Continuous Deployment não há revisão manual antes da implantação; qualquer falha nos testes pode ir diretamente para produção. Portanto, os testes precisam ser extremamente confiáveis, cobrindo cenários críticos e evitando falsos positivos.
  5. Descreva como feature flags podem ser usadas para combinar benefícios de ambas as abordagens.

    6. ✓ Resposta: Feature flags permitem implantar código continuamente (como no Continuous Deployment) mas controlar a ativação de funcionalidades por meio de chaves, permitindo liberar gradualmente para usuários, reverter rapidamente e realizar testes A/B, combinando automação com controle seletivo.