Dev, staging e produção: para que serve cada ambiente

Times costumam herdar uma estrutura de ambientes que ninguém decidiu: um ambiente de desenvolvimento que virou homologação, uma cópia criada para um projeto que terminou, e produção. A discussão que aparece depois é sobre quantidade. A pergunta mais útil é outra: o que cada ambiente precisa provar antes que uma mudança siga adiante.

Comece pelo papel de cada ambiente

Descreva, para cada ambiente existente, qual pergunta ele responde.

• Desenvolvimento costuma responder se o código compila, sobe e passa nas verificações automáticas.
• Homologação, ou staging, costuma responder se o comportamento se mantém com integrações e dados próximos dos reais.
• Produção atende ao uso efetivo do produto. O uso de dados de clientes em outros ambientes exige avaliação específica de necessidade e proteção.

Quando dois ambientes parecem cumprir o mesmo papel, vale verificar se há razões de isolamento, integração ou fluxo de trabalho para mantê-los. Quando uma pergunta importante fica sem ambiente que a responda, a verificação correspondente precisa acontecer de outra forma.

O que faz um ambiente representar o outro

Conhecer as diferenças em relação à produção ajuda a interpretar o que os testes conseguem demonstrar. As dimensões que mais costumam divergir:

• Configuração: variáveis, limites, versões de dependências e parâmetros de serviço.
• Dados: volume, distribuição e casos de borda. Um banco com cem registros não revela problemas que aparecem com milhões.
• Integrações: serviços externos substituídos por simulações, e o que isso deixa de exercitar.
• Infraestrutura: capacidade, rede, latência entre componentes e configuração de armazenamento.
• Acessos: permissões mais amplas que as de produção mudam o que o teste consegue provar.

Registrar as diferenças é um primeiro passo para avaliar quais precisam ser reduzidas. A lista também orienta quais riscos pedem outra forma de verificação.

Dados em ambientes que não são produção

Copiar dados de produção é uma possibilidade que exige avaliar necessidade, acesso, proteção e retenção. Entram nessa avaliação o tratamento de dados pessoais, quem alcança o ambiente, como a cópia é gerada e por quanto tempo permanece.

As alternativas envolvem anonimização, geração sintética e subconjuntos representativos. Cada uma tem um custo de manutenção e um limite de fidelidade. A escolha depende do que precisa ser testado e das obrigações aplicáveis aos dados envolvidos.

Criação e descarte

Ambientes criados manualmente tendem a divergir com o tempo, porque cada ajuste acontece em um deles. Definições em código ajudam a comparar configurações previstas. A correspondência com o ambiente em execução também precisa ser verificada.

Vale avaliar quanto esforço a criação exige hoje. Quando criar um ambiente leva dias, o time evita criar, e ambientes antigos acumulam. Quando a criação é previsível, ambientes temporários por mudança se tornam viáveis, com um custo de execução que precisa entrar na conta.

Custo e ciclo de uso

Ambientes de apoio costumam ficar disponíveis integralmente e ser usados em parte do tempo. Reduzir capacidade fora do uso é uma alternativa, e exige verificar tarefas agendadas, integrações que dependem de disponibilidade contínua, dados em memória e o procedimento de retomada.

A decisão precisa considerar o tempo de indisponibilidade aceitável para quem usa aquele ambiente.

Uma revisão em quatro passos

1. Liste os ambientes existentes e quem os usa.
2. Escreva a pergunta que cada um responde.
3. Registre as diferenças conhecidas em relação a produção.
4. Identifique os ambientes sem uso recente e os riscos sem verificação.

Esse levantamento costuma mostrar duplicação e lacunas na mesma lista.

A revisão de ambientes é uma das frentes da Consultoria DevOps e pode integrar um trabalho de Construção de plataforma. Quando faltam informações sobre o cenário atual, um Diagnóstico de plataforma pode apoiar o diagnóstico, conforme o recorte contratado.