Production em CI/CD — o que é, etapas e ambiente no desenvolvimento

O que é Production em CI/CD

Production no contexto de CI/CD é a fase final do ciclo de vida da aplicação, onde o código após passar por todas as etapas de compilação e teste fica disponível para os utilizadores finais. Ao contrário dos ambientes de desenvolvimento e staging, o ambiente de produção trabalha com dados e cargas reais, o que impõe requisitos especiais de fiabilidade e desempenho.

Papel do ambiente de produção

O ambiente de produção não é apenas um servidor, mas toda uma infraestrutura que inclui balanceadores de carga, bases de dados, camadas de cache, CDN e sistemas de monitorização. Cada componente deve ser tolerante a falhas e escalável. No desenvolvimento móvel, a produção também inclui serviços backend, gateways API e infraestrutura push que suportam a aplicação cliente.

Requisitos do ambiente de produção

O ambiente de produção deve cumprir critérios rigorosos: disponibilidade 99,9% ou superior, tempo de resposta da API não superior a 200 ms, suporte de recuperação de desastres (RTO e RPO dentro do SLA). Para aplicações móveis, são adicionalmente necessários relatórios de falhas, análise de utilização e plataformas A/B para experimentos. O pipeline CI/CD garante a conformidade com estes requisitos através de verificações automatizadas antes de cada deployment.

Etapas de deployment em produção

O deployment em produção é um processo de múltiplas etapas automatizado através do pipeline CI/CD. Cada etapa inclui verificações que impedem que código defeituoso chegue à produção. Vamos rever as etapas principais usando como exemplo um pipeline típico de aplicações móveis.

Pipeline CI/CD para produção

O pipeline começa com um commit no ramo principal do repositório. Após o push, são lançadas a compilação automática e os testes unitários, seguidos de testes de integração e verificações de qualidade do código. Após a conclusão bem-sucedida de todas as etapas, o artefacto é publicado no registo de compilações e implementado em staging para verificação final. Só após a confirmação em staging é que o pipeline prossegue para o deployment em produção.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

Automatização do deployment

O deployment automatizado em produção utiliza estratégias de deployment com zero tempo de inatividade: rolling update, blue-green deployment ou canary release. Com rolling update, as novas instâncias da aplicação substituem gradualmente as antigas sem parar o serviço. O blue-green deployment mantém dois ambientes idênticos e muda o tráfego instantaneamente, permitindo uma reversão rápida se surgirem problemas. A escolha da estratégia depende da criticidade do serviço e do tempo de inatividade aceitável. Para aplicações móveis, o deployment em produção inclui a publicação em lojas de aplicações (App Store Connect, Google Play Console) com lançamento gradual, o que requer integração adicional de CI/CD com as APIs das lojas para automatizar o processo de publicação, incluindo carregamento de binários, preenchimento de metadados e envio para revisão.

Verificações pós-deployment

Após o deployment bem-sucedido em produção, o pipeline CI/CD lança um conjunto de smoke tests que verificam a funcionalidade básica do serviço: disponibilidade de endpoints, correção das respostas da API, tempo de resposta dentro dos limites normais. Para aplicações móveis, são adicionalmente verificadas a capacidade de autorização, a sincronização de dados e o funcionamento correto das integrações de pagamento. Se os smoke tests falharem, o pipeline inicia automaticamente uma reversão para a versão estável anterior e envia uma notificação à equipa. A monitorização pós-deployment continua durante 30-60 minutos com um nível elevado de alertas — esta é a janela para detetar problemas não cobertos pelos testes automatizados.

Diferenças entre produção e ambientes de teste

A diferença chave entre produção e ambientes menos rigorosos é trabalhar com dados e cargas de utilizadores reais. O ambiente de staging é concebido para testes finais antes do lançamento, mas utiliza dados sintéticos ou anonimizados. A produção, por outro lado, processa transações ao vivo, dados pessoais e operações criticamente importantes, o que requer uma abordagem fundamentalmente diferente na gestão.

Configuração e infraestrutura

A configuração do ambiente de produção deve estar estritamente isolada de outros ambientes. Isto aplica-se a variáveis de ambiente, cadeias de conexão a bases de dados, chaves API e certificados. A infraestrutura de produção é geralmente duplicada em múltiplas zonas de disponibilidade para garantir tolerância a falhas. Para aplicações móveis, a produção também inclui configurações da Apple App Store e Google Play que estão ausentes nas compilações de teste.

Gestão de dados

Em produção, é estritamente proibido usar dados reais para testes — para isso existem os ambientes de staging e desenvolvimento. Todas as alterações na estrutura da base de dados devem passar por migrações que o pipeline CI/CD aplica automaticamente. A cópia de segurança dos dados de produção é realizada conforme um calendário com verificação automática de integridade. A política de retenção determina o período de armazenamento das cópias de segurança de acordo com os requisitos do RGPD e outros regulamentos.

Monitorização da infraestrutura de produção

A monitorização de produção é um processo contínuo de recolha e análise de métricas, registos e rastreios. Sem uma monitorização abrangente, é impossível garantir o SLA e detetar incidentes de forma atempada. A abordagem moderna à monitorização baseia-se em três pilares: métricas (indicadores numéricos), registos (registos estruturados de eventos) e rastreios (seguimento de pedidos).

Métricas chave

As métricas chave do ambiente de produção incluem: uptime (disponibilidade do serviço), latência (atraso de resposta), taxa de erro (percentagem de erros), throughput (largura de banda) e saturação (nível de carga de recursos). Para aplicações móveis, são críticas as métricas de tempo de inicialização, taxa livre de falhas e tempo de sincronização de dados. Os alertas são configurados com base em SLO (Service Level Objectives) para que a equipa receba notificações antes de o SLA ser violado.

Ferramentas de monitorização

Para a monitorização da infraestrutura de produção, são utilizadas plataformas especializadas: Datadog, New Relic, Grafana + Prometheus para recolha de métricas, Sentry e Crashlytics para rastreio de erros em aplicações móveis. Os registos são centralizados através da stack ELK (Elasticsearch, Logstash, Kibana) ou Splunk. O rastreio de pedidos é implementado com Jaeger ou Zipkin. Todas as ferramentas são integradas com o pipeline CI/CD para criação automática de painéis ao implementar um novo serviço. O sistema de resposta a incidentes (PagerDuty, Opsgenie) recebe alertas de todas as ferramentas de monitorização e atribui automaticamente um responsável de plantão com base em regras de rotação e escalada. Um runbook para cada tipo de incidente é armazenado no repositório e versionado juntamente com o código, garantindo a relevância das instruções de recuperação.

Segurança do ambiente de produção

A segurança do ambiente de produção é um sistema de proteção de múltiplas camadas que cobre a infraestrutura, os dados, o acesso e o processo de deployment. Cada camada deve ser configurada de modo que o compromisso de uma não conduza ao compromisso de todo o sistema. O pipeline CI/CD desempenha um papel chave na garantia da segurança através de verificações automatizadas, digitalização de vulnerabilidades e controlo de conformidade em cada etapa do pipeline.

Acesso e funções

O acesso ao ambiente de produção é estritamente limitado pelo princípio do menor privilégio. Os programadores não têm acesso direto aos servidores de produção — todas as alterações passam pelo pipeline CI/CD com um mecanismo de aprovação. Para acesso de emergência, são utilizadas credenciais temporárias com rotação automática e registo completo de ações. O princípio de quatro olhos (qualquer operação requer a aprovação de duas pessoas) é o padrão para operações de produção.

Auditoria de alterações

Cada alteração em produção é registada no sistema de auditoria: quem iniciou o deployment, qual commit foi implementado, quais verificações foram aprovadas, quanto tempo demorou o deployment. A integração de CI/CD com sistemas de gestão de incidentes (PagerDuty, Opsgenie) permite a criação automática de tickets quando o deployment falha ou o SLO é violado. Todos os registos de produção são armazenados num repositório imutável com uma retenção de pelo menos 90 dias de acordo com os requisitos da SOC2 e ISO 27001.