Como você gerencia configurações em diferentes ambientes?

Question

Accepted Answer

A configuração do Django fica em `settings.py`, mas aplicações reais precisam de **diferentes configurações por ambiente** (desenvolvimento, staging, produção) e devem manter **segredos fora do código**. Gerenciar isso corretamente é tanto uma necessidade operacional quanto um requisito de segurança.

## O problema com um único settings.py

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

Codificar valores mistura ambientes e — crucialmente — commita segredos (SECRET_KEY, senhas de banco de dados, chaves de API) no controle de versão, uma séria falha de segurança.

## Solução 1: ler configuração de variáveis de ambiente

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

Ler configuração (especialmente segredos) de **variáveis de ambiente** mantém fora do código — a mesma base de código roda em qualquer ambiente com diferentes valores injetados (a abordagem twelve-factor).

## Solução 2: dividir arquivos de configuração por ambiente

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

Dividir configurações em um `base.py` compartilhado mais arquivos por ambiente (selecionado via `DJANGO_SETTINGS_MODULE`) separa claramente a configuração específica de cada ambiente enquanto compartilha configurações comuns.

## Configurações críticas de produção

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

## Por que isso importa

Gerenciar configurações em diferentes ambientes é tanto uma **necessidade operacional** quanto uma **prática crítica de segurança** para qualquer aplicação Django real.

Aplicações devem se comportar diferentemente em ambientes — desenvolvimento precisa de `DEBUG=True` e configurações locais convenientes, enquanto produção requer `DEBUG=False`, endurecimento de segurança, bancos de dados reais e hosts apropriados — e um único `settings.py` codificado não pode servir a todos esses casos.

Mais importante ainda, esta é uma **questão séria de segurança**: codificar segredos (a SECRET_KEY, senhas de banco de dados, chaves de API) commita-os no controle de versão, uma das falhas de segurança mais comuns e sérias (qualquer pessoa com acesso ao repositório, ou em um repositório público, consegue as chaves da sua aplicação e dados).

Entender as soluções — ler configuração e segredos de **variáveis de ambiente** (mantendo-os fora do código, a abordagem twelve-factor, geralmente com ferramentas como django-environ e arquivos `.env` ignorados) e **dividir configurações** em um base compartilhado mais arquivos por ambiente — é essencial para implantar Django com segurança e corretamente.

Conhecer as **configurações críticas de produção** (especialmente que `DEBUG` deve ser `False` em produção, já que `DEBUG=True` vaza stack traces, caminhos de código-fonte e configurações para atacantes, além de `ALLOWED_HOSTS` e endurecimento de segurança) é conhecimento de produção inegociável.

Acertar o gerenciamento de configurações — segredos no ambiente, configuração apropriada para cada ambiente, padrões de segurança em produção — é fundamental para executar aplicações Django profissionalmente e evitar as vulnerabilidades sérias que vêm de segredos vazados ou ambientes de produção mal configurados, tornando isso um conhecimento importante e praticamente crítico para qualquer implantação real.