Desenvolvimento, homologação e produção: como separar ambientes

Ambientes devem ser semelhantes o suficiente para revelar problemas e separados o suficiente para limitar impacto, dados e privilégios.

Iguais, parecidos ou obrigatoriamente diferentes? Separar ambientes não significa criar três cópias idênticas da infraestrutura. Também não significa permitir que cada ambiente se torne um sistema diferente. A decisão correta varia por aspecto. Aspecto Relação recomendada Código e artefato Igual Runtime e serviços principais O mais parecido possível Escala Pode ser diferente Dados Obrigatoriamente separados Credenciais Obrigatoriamente separadas Acesso Mais restrito em produção Configuração Mesma estrutura, valores diferentes Monitoramento Presente em todos, mais rigoroso em produção Aprovação Proporcional ao risco Integrações externas Sandbox ou isolamento quando disponível A finalidade dos ambientes é reduzir incerteza sem ampliar desnecessariamente o alcance das mudanças. Desenvolvimento: velocidade e diagnóstico O ambiente de desenvolvimento existe para criar e ajustar mudanças. Características esperadas: feedback rápido; logs detalhados; dados sintéticos; ferramentas de diagnóstico; acesso da equipe; reinicialização frequente; possibilidade de descarte; experimentos controlados. Desenvolvimento não deve: possuir credenciais de produção; enviar mensagens reais para clientes; processar pagamentos reais; compartilhar banco de produção; funcionar como rota alternativa de produção; armazenar cópia indiscriminada de dados pessoais. Um ambiente flexível não precisa ser inseguro. Homologação: ensaio da entrega Homologação — também chamada de staging ou pre production em alguns contextos — existe para validar a integração e o procedimento de publicação. Ela precisa responder: o artefato inicia; a migração funciona; o proxy encaminha; o certificado está correto; a autenticação integra; os jobs executam; os logs chegam; o healthcheck funciona; o rollback é possível; os fluxos críticos completam. Homologação não é apenas uma demonstração visual. Uma página que “parece certa” pode falhar em: envio de e mail; DNS; permissões; armazenamento; concorrência; fila; timeouts; migração; monitoramento. Produção: serviço real e mudança controlada Produção atende usuários, dados e processos reais. Ela precisa de: privilégios mínimos; contas individuais; monitoramento; backup; restauração; logs controlados; histórico de deploy; rollback; suporte; resposta a incidentes; hardening; manutenção. Acesso direto a produção deve ser exceção operacional, não rotina de desenvolvimento. Corrigir um arquivo manualmente em produção cria divergência entre: repositório; artefato; servidor; histórico; próxima release. Mudanças emergenciais precisam voltar ao fluxo versionado depois da contenção. 1. Código: igual O mesmo commit deve originar o artefato promovido. Fluxo inadequado: Fluxo recomendado: Cada reconstrução pode escolher dependências diferentes. O ambiente deve injetar: endpoint; credencial; hostname; capacidade; flags; política. Não deve alterar silenciosamente o código do artefato. Esse princípio é detalhado no fluxo DevOps confiável. 2. Runtime: parecido A paridade dev/prod do Twelve Factor App recomenda reduzir diferenças de tempo, pessoas e ferramentas. Exemplo de divergência perigosa: A aplicação pode passar localmente e falhar em: SQL; transações; concorrência; permissões; headers; arquivos; proxy; sinais. Não é necessário reproduzir a escala inteira no notebook. É necessário preservar características que alteram comportamento. Uma alternativa: 3. Escala: pode ser diferente Duplicar integralmente produção pode ser caro. Homologação pode usar: menos réplicas; banco menor; retenção reduzida; menos nós; limites inferiores. Ela precisa manter capacidade suficiente para validar: topologia; deploy; migração; compatibilidade; comportamento de rede; testes de carga específicos. Não use um ambiente minúsculo para concluir que um teste de desempenho representa produção. Performance pode exigir: ambiente dedicado; carga controlada; dados representativos; isolamento; monitoramento detalhado. 4. Configuração: mesma forma, valores diferentes A página Config do Twelve Factor App define configuração como valores que variam entre deploys, como credenciais, recursos e hostname. Exemplo: Produção: A estrutura deve permanecer consistente. Não espalhe decisões em: constantes; arquivos manuais; parâmetros desconhecidos; scripts locais; interface do servidor sem documentação. Valide configuração no início: Falhar ao iniciar é melhor do que operar parcialmente com valor incorreto. 5. Segredos: diferentes e não copiáveis Cada ambiente deve possuir: identidade; cofre; permissões; banco; token; certificado; credencial externa. Nunca use a mesma senha de banco em desenvolvimento e produção. Se uma credencial de desenvolvimento for exposta, o incidente não deve alcançar produção. Matriz: Identidade Dev HML Prod Pipeline escrita em dev escrita em hml deploy limitado Aplicação recursos dev recursos hml recursos prod Desenvolvedor acesso amplo controlado acesso conforme função acesso restrito Suporte dados sintéticos diagnóstico acesso auditado quando necessário Prefira identidades temporárias e específicas, conforme o artigo sobre segredos no CI/CD. 6. Dados: separados Copiar banco de produção para homologação sem tratamento pode expor: nomes; e mails; documentos; endereços; pedidos; tokens; mensagens; arquivos. Alternativas: dados sintéticos; geração de fixtures; anonimização; mascaramento; subconjuntos; ambientes efêmeros. Anonimizar não significa trocar apenas o nome. Relacionamentos e campos indiretos podem reidentificar pessoas. Defina: finalidade; campos permitidos; retenção; acesso; descarte; validação; owner. Não use produção como ambiente de teste porque “é onde há dados bons”. 7. Integrações: sandbox ou barreira técnica Desenvolvimento e homologação precisam testar integrações sem efeitos reais. Exemplos: E mail servidor sandbox; domínio não roteável; allowlist; assunto marcado; bloqueio de destinatários externos. Pagamento credenciais sandbox; cartões de teste; webhook separado; conta distinta. SMS e mensageria mock; número de teste; limite; aprovação; fila isolada. Armazenamento bucket diferente; política diferente; retenção curta; prefixo isolado. Uma variável ENV=hml não impede envio real. Crie barreiras no provedor, na rede e nas permissões. 8. Rede: segmentada Ambientes devem possuir fronteiras de rede. Exemplo: Homologação pode ser acessível somente por: VPN; identidade; allowlist; autenticação adicional. Não publique painéis, bancos e ambientes de teste indiscriminadamente. 9. Logs: detalhe diferente, proteção igual Desenvolvimento pode registrar mais contexto. Produção precisa evitar: debug permanente; stack trace ao usuário; SQL sensível; tokens; corpos completos; dados pessoais. A estrutura deve permanecer: Isso permite testar dashboards e alertas antes de produção. 10. Domínio e identidade visual: diferentes Padrão possível: Inclua sinais visíveis: Isso reduz ações no ambiente errado. Painéis administrativos podem exibir: ambiente; versão; região; commit; configuração ativa sem segredos. Não dependa apenas da cor. Use texto. 11. Acesso: progressivamente restrito Dev equipe técnica; permissões para experimentar; dados sintéticos. HML equipe técnica; QA; produto; clientes de validação quando necessário. Prod aplicação; pipeline; plantão; administradores autorizados. Acesso de produção deve possuir: identidade individual; MFA; auditoria; prazo; justificativa; menor privilégio. Ambientes separados no mesmo servidor ainda compartilham risco de kernel, disco, rede e administração. Para isolamento forte, use VMs, contas, projetos ou clusters separados conforme o impacto. 12. Aprovação: proporcional ao impacto A documentação de environments do GitHub Actions oferece: reviewers; restrições de branch; tempo de espera; secrets por ambiente; regras de proteção. Workflow simplificado: Os detalhes de disponibilidade dos recursos variam por plano e visibilidade do repositório. O job de homologação não deve receber segredo de produção. O CI/CD seguro deve separar jobs, runners e identidades. 13. Promoção: uma sequência explícita Não promova por cópia manual entre diretórios sem identificar versão. Registre: commit; artefato; digest; configuração; migration head; aprovador; resultado. Preview environments não substituem homologação Um ambiente efêmero por pull request pode ajudar a revisar: interface; fluxo; conteúdo; integração isolada. Ele não necessariamente representa: topologia; dados; proxy; volume; migração; rede; serviço externo; rollback. Use preview para feedback rápido e homologação para ensaio operacional. Ambiente que ninguém mantém vira uma falsa garantia Homologação pode estar: meses desatualizada; com banco incompatível; sem monitoramento; com DNS diferente; usando segredo expirado; sem carga; sem dados representativos. A equipe acredita que validou, mas testou outro sistema. Crie checks: A infraestrutura pode ser declarada com Terraform ou outra ferramenta, mas IaC não garante que os ambientes estejam atualizados sem aplicação e detecção de drift. Quantos ambientes são necessários? Uma equipe pequena pode começar com: Outra pode precisar de: integração; QA; performance; segurança; treinamento; demo; preview; disaster recovery. Cada ambiente cria custo: infraestrutura; dados; atualização; suporte; credenciais; observabilidade. Não crie um ambiente apenas porque o nome parece padrão. Defina uma pergunta que ele responde. Critério de aceite Desenvolvimento mudanças podem ser testadas rapidamente; dados são sintéticos; não existe acesso a produção; erros são diagnosticáveis. Homologação mesmo artefato candidato; runtime compatível; migrações executadas; integrações controladas; deploy e rollback testados; fluxos críticos validados. Produção acesso restrito; backup e restauração; monitoramento; identidade exclusiva; histórico; suporte; resposta a incidente. A meta não é tornar todos os ambientes idênticos. É manter iguais as características que determinam comportamento e separar aquelas que determinam risco. Essa é a fronteira prática: