Dev, staging e production: o que é cada ambiente e como separá-los na AWS

1. O que é cada ambiente#

Um ambiente é uma cópia da sua aplicação com configuração, dados e acessos próprios. Quase todas as equipes usam três: development (dev), staging e production. Os nomes importam menos que a pergunta que cada um responde.

Development é onde você testa a sua mudança; staging é o ensaio geral com uma configuração o mais parecida possível com a de produção; production é o que os clientes usam. Se dois ambientes respondem à mesma pergunta, um sobra.

2. No que realmente diferem#

Além do nome, quatro coisas separam um ambiente do outro.

• Dados: dev usa dados sintéticos; staging, uma cópia reduzida e anonimizada; production, dados reais. Nunca copie dados pessoais reais para o staging sem anonimizá-los.
• Acesso: quanto mais usuários reais, menos acesso humano. Em production entra-se pelo processo de implantação, não pelo console.
• Tamanho e custo: o staging costuma ser uma versão menor da produção com o mesmo código de infraestrutura e outras variáveis.
• Alertas: uma falha em dev não acorda ninguém; uma em production acorda. Configure os alertas por ambiente.

A regra útil é que o staging deve falhar pelas mesmas razões que a produção: se a configuração é diferente, o que você vê ali não prevê o que vai acontecer.

3. Como separá-los na AWS#

Segundo o guia oficial da AWS sobre organização com várias contas, uma conta da AWS atua como limite de isolamento para a gestão de identidade e acesso, e por padrão não há acesso entre contas: se você usa contas separadas para produção e não produção, elas permanecem isoladas a menos que você habilite a comunicação. A AWS cobra pelo uso de recursos, não pelo número de contas, então separar não acrescenta tarifa.

Isso faz de uma conta por ambiente a opção mais sólida. A tabela compara as alternativas habituais. Se você já tem uma única conta, o guia da Codifly sobre como separar ambientes na AWS explica a passagem para contas com unidades organizacionais.

Para se aprofundarComo separar ambientes (dev, staging e produção) na AWS

Documentação: AWS: organizar seu ambiente com várias contas ↗ · AWS Organizations: introdução ↗ · AWS: Well-Architected Framework ↗

4. Uma regra para não mexer em produção por engano#

Os erros mais caros acontecem ao executar o comando certo no ambiente errado. Uma pequena verificação antes de cada ação evita isso: confirme que a conta atual é a do ambiente e exija confirmação para ações destrutivas em production.

CONTAS = {"dev": "111111111111", "staging": "222222222222", "production": "333333333333"}  # IDs de exemplo

def validar(ambiente: str, conta_atual: str, destrutiva: bool, confirmado: bool) -> str:
    esperada = CONTAS.get(ambiente)
    if esperada is None:
        return f"BLOQUEADO: ambiente desconhecido ({ambiente})"
    if conta_atual != esperada:
        return f"BLOQUEADO: a conta {conta_atual} não é a de {ambiente}"
    if ambiente == "production" and destrutiva and not confirmado:
        return "BLOQUEADO: em production as ações destrutivas exigem confirmação"
    return "OK"

print("1:", validar("staging", "222222222222", True, False))
print("2:", validar("production", "222222222222", False, False))
print("3:", validar("production", "333333333333", True, False))
print("4:", validar("production", "333333333333", True, True))

Chame uma função assim nos seus scripts de implantação e no seu pipeline. Ela não substitui as permissões do IAM, que são a defesa real, mas pega o erro humano antes de chegar à API.

5. Como promover mudanças entre ambientes#

Uma mudança deveria viajar de dev para staging e para production sem ser reconstruída.

• Construa o artefato uma única vez e promova-o: o que você testou no staging é o mesmo que chega à production.
• Use o mesmo código de infraestrutura em todos os ambientes e mude só as variáveis.
• Teste as migrações de banco de dados no staging com um volume parecido com o real.
• Exija aprovação antes da production e deixe um plano de reversão pronto.
• Guarde os segredos por ambiente em um gerenciador, nunca no repositório.

Para se aprofundarVariáveis de ambiente e DATABASE_URL em produção: guia completo

6. Checklist#

Antes de considerar seus ambientes separados, verifique o seguinte.

• Cada ambiente tem a sua própria conta ou, no mínimo, a sua própria VPC e os seus próprios papéis.
• O staging usa dados anonimizados e a produção é a única com dados reais.
• A implantação em production exige aprovação e deixa registro.
• Alertas e orçamentos estão configurados por ambiente.
• Ninguém usa credenciais de production na própria máquina para o trabalho diário.

Para se aprofundarQual é a melhor estrutura organizacional para sua conta AWS?