Qual é a maneira recomendada de lidar com as configurações do desenvolvimento local e do servidor de produção? Alguns deles (como constantes, etc.) podem ser alterados / acessados ​​em ambos, mas alguns deles (como caminhos para arquivos estáticos) precisam permanecer diferentes e, portanto, não devem ser substituídos toda vez que o novo código for implantado.

Atualmente, estou adicionando todas as constantes a settings.py. Mas sempre que altero alguma constante localmente, tenho que copiá-la para o servidor de produção e editar o arquivo para alterações específicas de produção ... :(

Edit: parece que não há resposta padrão para esta pergunta, eu aceitei o método mais popular.

Em settings.py:

try:
    from local_settings import *
except ImportError as e:
    pass

Você pode substituir o que é necessário local_settings.py; deve ficar fora do seu controle de versão. Mas desde que você mencionou a cópia, acho que você não usa nenhuma;)

Duas dicas do Django: Práticas recomendadas para o Django 1.5 sugerem o uso de controle de versão para seus arquivos de configurações e o armazenamento em um diretório separado:

project/
    app1/
    app2/
    project/
        __init__.py
        settings/
            __init__.py
            base.py
            local.py
            production.py
    manage.py

O base.pyarquivo contém as definições comuns (como MEDIA_ROOT ou ADMIN), enquanto local.pye production.pytem configurações específicas do local:

No arquivo base settings/base.py:

INSTALLED_APPS = (
    # common apps...
)

No arquivo de configurações de desenvolvimento local settings/local.py:

from project.settings.base import *

DEBUG = True
INSTALLED_APPS += (
    'debug_toolbar', # and other apps for local development
)

No arquivo de configurações de produção de arquivo settings/production.py:

from project.settings.base import *

DEBUG = False
INSTALLED_APPS += (
    # other apps for production site
)

Então, quando você executa o django, você adiciona a --settingsopção:

# Running django for local development
$ ./manage.py runserver 0:8000 --settings=project.settings.local

# Running django shell on the production site
$ ./manage.py shell --settings=project.settings.production

Os autores do livro também colocaram um modelo de layout de projeto de amostra no Github.

Em vez de settings.py, use este layout:

.
└── settings/
    ├── __init__.py  <= not versioned
    ├── common.py
    ├── dev.py
    └── prod.py

common.py é onde vive a maior parte de sua configuração.

prod.py importa tudo de comum e substitui o que for necessário para substituir:

from __future__ import absolute_import # optional, but I like it
from .common import *

# Production overrides
DEBUG = False
#...

Da mesma forma, dev.pyimporta tudo common.pye substitui o que for necessário para substituir.

Por fim, __init__.pyé onde você decide quais configurações carregar e também onde armazena segredos (portanto, esse arquivo não deve ser versionado):

from __future__ import absolute_import
from .prod import *  # or .dev if you want dev

##### DJANGO SECRETS
SECRET_KEY = '(3gd6shenud@&57...'
DATABASES['default']['PASSWORD'] = 'f9kGH...'

##### OTHER SECRETS
AWS_SECRET_ACCESS_KEY = "h50fH..."

O que eu gosto nesta solução é:

1. Tudo está no seu sistema de versões, exceto segredos
2. A maioria de configuração está em um lugar: common.py.
3. Coisas específicas do Prod entram prod.py, coisas específicas do Dev entram dev.py. É simples.
4. Você pode substituir itens de common.pydentro de prod.pyou ou dev.pysubstituir qualquer item __init__.py.
5. É python simples. Não há reimportação de hacks.

Eu uso uma versão ligeiramente modificada do estilo "if Debug" das configurações que Harper Shelby postou. Obviamente, dependendo do ambiente (win / linux / etc.), O código pode precisar ser ajustado um pouco.

Eu estava usando o "if DEBUG" no passado, mas descobri que ocasionalmente precisava fazer testes com o DEUBG definido como False. O que eu realmente queria distinguir se o ambiente fosse produção ou desenvolvimento, o que me deu a liberdade de escolher o nível DEBUG.

PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG

# ...

if PRODUCTION:
    DATABASE_HOST = '192.168.1.1'
else:
    DATABASE_HOST = 'localhost'

Eu ainda consideraria esse modo de configuração um trabalho em andamento. Eu não vi nenhuma maneira de lidar com as configurações do Django que cobriam todas as bases e, ao mesmo tempo, não era um aborrecimento total para configurar (eu não conheço os métodos dos arquivos de configurações de 5x).

Eu uso um settings_local.py e um settings_production.py. Depois de tentar várias opções, descobri que é fácil perder tempo com soluções complexas quando simplesmente ter dois arquivos de configuração é fácil e rápido.

Quando você usa mod_python / mod_wsgi para o seu projeto Django, você precisa apontar para o seu arquivo de configurações. Se você apontar para app / settings_local.py no servidor local e app / settings_production.py no servidor de produção, a vida se tornará fácil. Apenas edite o arquivo de configurações apropriado e reinicie o servidor (o servidor de desenvolvimento do Django será reiniciado automaticamente).

TL; DR: O truque é modificar os.environmentantes de importar settings/base.pyem qualquer settings/<purpose>.py, isso vai simplificar muito as coisas.

Só de pensar em todos esses arquivos entrelaçados me dá dor de cabeça. Combinando, importando (às vezes condicionalmente), substituindo, corrigindo o que já foi definido, caso a DEBUGconfiguração seja alterada posteriormente. Que pesadelo!

Ao longo dos anos, passei por todas as soluções diferentes. Todos eles funcionam um pouco , mas são tão difíceis de gerenciar. WTF! Realmente precisamos de todo esse aborrecimento? Começamos com apenas um settings.pyarquivo. Agora precisamos de uma documentação apenas para combinar corretamente tudo isso em uma ordem correta!

Espero finalmente chegar ao (meu) ponto ideal com a solução abaixo.

Vamos recapitular os objetivos (alguns comuns, outros meus)

1. Mantenha segredos em segredo - não os guarde em um repositório!

2. Defina / leia chaves e segredos através das configurações do ambiente, estilo de 12 fatores .

3. Tenha padrões de fallback sensatos. Idealmente para o desenvolvimento local, você não precisa de mais nada além dos padrões.

4. … Mas tente manter a produção dos padrões segura. É melhor perder uma substituição de configuração localmente do que lembrar de ajustar as configurações padrão seguras para produção.

5. Tem a capacidade de ligar DEBUG/ desligar de uma maneira que possa afetar outras configurações (por exemplo, usando javascript compactado ou não).

6. A alternância entre as configurações de finalidade, como local / teste / preparação / produção, deve basear-se apenas em DJANGO_SETTINGS_MODULEnada mais.

7. … Mas permita parametrização adicional por meio de configurações do ambiente como DATABASE_URL.

8. … Também permite que eles usem configurações de finalidade diferentes e as executem localmente lado a lado, por exemplo. configuração de produção na máquina local do desenvolvedor, para acessar o banco de dados de produção ou as folhas de estilo compactadas para teste de fumaça.

9. Falha se uma variável de ambiente não estiver definida explicitamente (exigindo um valor vazio no mínimo), especialmente na produção, por exemplo. EMAIL_HOST_PASSWORD.

10. Responda ao padrão DJANGO_SETTINGS_MODULEdefinido em manage.py durante o django-admin startproject

11. Mantenha as condições mínimas, se a condição for o tipo de ambiente proposto (por exemplo, para o arquivo de log do conjunto de produção e sua rotação), substitua as configurações no arquivo de configurações propostas associado.

Não

1. Não permita que o django leia a configuração DJANGO_SETTINGS_MODULE de um arquivo.
   Ugh! Pense em como isso é meta. Se você precisar de um arquivo (como o docker env), leia-o no ambiente antes de iniciar um processo de django.

2. Não substitua DJANGO_SETTINGS_MODULE no código do seu projeto / aplicativo, por exemplo. com base no nome do host ou no nome do processo.
   Se você tem preguiça de definir variáveis ​​de ambiente (como para setup.py test), faça-o em ferramentas imediatamente antes de executar o código do projeto.

3. Evite magia e correções de como o django lê suas configurações, pré-processe as configurações, mas não interfira posteriormente.

4. Nenhuma lógica complicada baseada em lógica. A configuração deve ser fixa e materializada, não computada em tempo real. Fornecer padrões de fallback é apenas lógica suficiente aqui.
   Deseja realmente depurar, por que localmente você tem um conjunto correto de configurações, mas em produção em um servidor remoto, em uma das cem máquinas, algo calculado de maneira diferente? Oh! Testes unitários? Para configurações? Seriamente?

Solução

Minha estratégia consiste no excelente django-environment usado com iniarquivos de estilo, fornecendo os.environmentpadrões para o desenvolvimento local, alguns settings/<purpose>.pyarquivos mínimos e curtos que possuem um import settings/base.py APÓS o os.environmentconjunto foi definido a partir de um INIarquivo. Isso efetivamente nos dá um tipo de injeção de configurações.

O truque aqui é modificar os.environmentantes de importar settings/base.py.

Para ver o exemplo completo, faça o repo: https://github.com/wooyek/django-settings-strategy

.
│   manage.py
├───data
└───website
    ├───settings
    │   │   __init__.py   <-- imports local for compatibility
    │   │   base.py       <-- almost all the settings, reads from proces environment 
    │   │   local.py      <-- a few modifications for local development
    │   │   production.py <-- ideally is empty and everything is in base 
    │   │   testing.py    <-- mimics production with a reasonable exeptions
    │   │   .env          <-- for local use, not kept in repo
    │   __init__.py
    │   urls.py
    │   wsgi.py

configurações / .env

Um padrão para o desenvolvimento local. Um arquivo secreto, para definir principalmente as variáveis ​​de ambiente necessárias. Configure-os para valores vazios se não forem necessários no desenvolvimento local. Nós fornecemos os padrões aqui e não settings/base.pyfalharemos em nenhuma outra máquina se eles estiverem ausentes no ambiente.

configurações / local.py

O que acontece aqui é carregar o ambiente de settings/.enve importar configurações comuns de settings/base.py. Depois disso, podemos substituir alguns para facilitar o desenvolvimento local.

import logging
import environ

logging.debug("Settings loading: %s" % __file__)

# This will read missing environment variables from a file
# We wan to do this before loading a base settings as they may depend on environment
environ.Env.read_env(DEBUG='True')

from .base import *

ALLOWED_HOSTS += [
    '127.0.0.1',
    'localhost',
    '.example.com',
    'vagrant',
    ]

# https://docs.djangoproject.com/en/1.6/topics/email/#console-backend
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
# EMAIL_BACKEND = 'django.core.mail.backends.dummy.EmailBackend'

LOGGING['handlers']['mail_admins']['email_backend'] = 'django.core.mail.backends.dummy.EmailBackend'

# Sync task testing
# http://docs.celeryproject.org/en/2.5/configuration.html?highlight=celery_always_eager#celery-always-eager

CELERY_ALWAYS_EAGER = True
CELERY_EAGER_PROPAGATES_EXCEPTIONS = True

settings / production.py

Para produção, não devemos esperar um arquivo de ambiente, mas é mais fácil ter um se estiver testando algo. De qualquer maneira, para que não forneça alguns padrões em linha, é settings/base.pypossível responder de acordo.

environ.Env.read_env(Path(__file__) / "production.env", DEBUG='False', ASSETS_DEBUG='False')
from .base import *

O principal ponto de interesse aqui são DEBUGe ASSETS_DEBUGsubstitui, eles serão aplicados ao python os.environSOMENTE se estiverem ausentes do ambiente e do arquivo.

Esses serão os padrões de produção, não é necessário colocá-los no ambiente ou no arquivo, mas podem ser substituídos, se necessário. Arrumado!

configurações / base.py

Essas são as configurações do seu baunilha, com alguns condicionais e muitas leituras do ambiente. Quase tudo está aqui, mantendo todos os ambientes propostos consistentes e o mais semelhante possível.

As principais diferenças estão abaixo (espero que sejam auto-explicativas):

import environ

# https://github.com/joke2k/django-environ
env = environ.Env()

# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))

# Where BASE_DIR is a django source root, ROOT_DIR is a whole project root
# It may differ BASE_DIR for eg. when your django project code is in `src` folder
# This may help to separate python modules and *django apps* from other stuff
# like documentation, fixtures, docker settings
ROOT_DIR = BASE_DIR

# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.11/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = env('SECRET_KEY')

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = env('DEBUG', default=False)

INTERNAL_IPS = [
    '127.0.0.1',
]

ALLOWED_HOSTS = []

if 'ALLOWED_HOSTS' in os.environ:
    hosts = os.environ['ALLOWED_HOSTS'].split(" ")
    BASE_URL = "https://" + hosts[0]
    for host in hosts:
        host = host.strip()
        if host:
            ALLOWED_HOSTS.append(host)

SECURE_SSL_REDIRECT = env.bool('SECURE_SSL_REDIRECT', default=False)

# Database
# https://docs.djangoproject.com/en/1.11/ref/settings/#databases

if "DATABASE_URL" in os.environ:  # pragma: no cover
    # Enable database config through environment
    DATABASES = {
        # Raises ImproperlyConfigured exception if DATABASE_URL not in os.environ
        'default': env.db(),
    }

    # Make sure we use have all settings we need
    # DATABASES['default']['ENGINE'] = 'django.contrib.gis.db.backends.postgis'
    DATABASES['default']['TEST'] = {'NAME': os.environ.get("DATABASE_TEST_NAME", None)}
    DATABASES['default']['OPTIONS'] = {
        'options': '-c search_path=gis,public,pg_catalog',
        'sslmode': 'require',
    }
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            # 'ENGINE': 'django.contrib.gis.db.backends.spatialite',
            'NAME': os.path.join(ROOT_DIR, 'data', 'db.dev.sqlite3'),
            'TEST': {
                'NAME': os.path.join(ROOT_DIR, 'data', 'db.test.sqlite3'),
            }
        }
    }

STATIC_ROOT = os.path.join(ROOT_DIR, 'static')

# django-assets
# http://django-assets.readthedocs.org/en/latest/settings.html

ASSETS_LOAD_PATH = STATIC_ROOT
ASSETS_ROOT = os.path.join(ROOT_DIR, 'assets', "compressed")
ASSETS_DEBUG = env('ASSETS_DEBUG', default=DEBUG)  # Disable when testing compressed file in DEBUG mode
if ASSETS_DEBUG:
    ASSETS_URL = STATIC_URL
    ASSETS_MANIFEST = "json:{}".format(os.path.join(ASSETS_ROOT, "manifest.json"))
else:
    ASSETS_URL = STATIC_URL + "assets/compressed/"
    ASSETS_MANIFEST = "json:{}".format(os.path.join(STATIC_ROOT, 'assets', "compressed", "manifest.json"))
ASSETS_AUTO_BUILD = ASSETS_DEBUG
ASSETS_MODULES = ('website.assets',)

O último bit mostra o poder aqui. ASSETS_DEBUGpossui um padrão sensato, que pode ser substituído settings/production.pye mesmo aquele que pode ser substituído por uma configuração de ambiente! Yay!

Com efeito, temos uma hierarquia mista de importância:

1. settings / .py - define padrões com base na finalidade, não armazena segredos
2. settings / base.py - é principalmente controlado pelo ambiente
3. configurações do ambiente de processo - bebê de 12 fatores!
4. settings / .env - padrões locais para inicialização fácil

Eu gerencio minhas configurações com a ajuda de django-split-settings .

É um substituto para as configurações padrão. É simples, mas configurável. E a refatoração das configurações existentes não é necessária.

Aqui está um pequeno exemplo (arquivo example/settings/__init__.py):

from split_settings.tools import optional, include
import os

if os.environ['DJANGO_SETTINGS_MODULE'] == 'example.settings':
    include(
        'components/default.py',
        'components/database.py',
        # This file may be missing:
        optional('local_settings.py'),

        scope=globals()
    )

É isso aí.

Atualizar

Eu escrevi um post sobre djangoas configurações de gerenciamento com django-split-sttings. Dar uma olhada!

O problema com a maioria dessas soluções é que você tem suas configurações locais aplicadas antes das comuns ou depois delas.

Portanto, é impossível substituir coisas como

• as configurações específicas do ambiente definem os endereços para o pool memcached e, no arquivo de configurações principais, esse valor é usado para configurar o back-end do cache
• as configurações específicas do ambiente adicionam ou removem apps / middleware ao padrão

ao mesmo tempo.

Uma solução pode ser implementada usando arquivos de configuração no estilo "ini" com a classe ConfigParser. Ele suporta vários arquivos, interpolação lenta de cadeias, valores padrão e muitas outras vantagens. Depois que vários arquivos forem carregados, mais arquivos poderão ser carregados e seus valores substituirão os anteriores, se houver.

Você carrega um ou mais arquivos de configuração, dependendo do endereço da máquina, variáveis ​​de ambiente e valores pares nos arquivos de configuração carregados anteriormente. Depois, basta usar os valores analisados ​​para preencher as configurações.

Uma estratégia que usei com sucesso foi:

• Carregar um defaults.iniarquivo padrão
• Verifique o nome da máquina e carregue todos os arquivos que correspondam ao FQDN invertido, da correspondência mais curta à mais longa (então, carreguei net.inie net.domain.ini, em seguida net.domain.webserver01.ini, cada um possivelmente substituindo os valores do anterior). Essa conta também se aplica às máquinas dos desenvolvedores, para que cada um possa configurar seu driver de banco de dados preferido, etc. para desenvolvimento local
• Verifique se existe um "nome de cluster" declarado e, nesse caso cluster.cluster_name.ini, carregue , o que pode definir coisas como IPs de banco de dados e cache

Como um exemplo de algo que você pode conseguir com isso, você pode definir um valor de "subdomínio" por env, que é usado nas configurações padrão (as hostname: %(subdomain).whatever.net) para definir todos os nomes de host e cookies necessários que o django precisa para funcionar.

É o DRY que eu pude obter, a maioria dos arquivos (existentes) tinha apenas 3 ou 4 configurações. Além disso, eu tinha que gerenciar a configuração do cliente, para que existisse um conjunto adicional de arquivos de configuração (com nomes de banco de dados, usuários e senhas, subdomínio designado etc.), um ou mais por cliente.

Pode-se dimensionar isso para baixo ou alto, conforme necessário, basta colocar no arquivo de configuração as chaves que você deseja configurar por ambiente e, quando houver necessidade de uma nova configuração, colocar o valor anterior na configuração padrão e substituí-lo onde necessário.

Este sistema provou ser confiável e funciona bem com o controle de versão. Ele é usado há muito tempo no gerenciamento de dois clusters de aplicativos separados (15 ou mais instâncias separadas do site django por máquina), com mais de 50 clientes, nos quais os clusters estavam mudando de tamanho e membros, dependendo do humor do administrador do sistema. .

Também estou trabalhando com o Laravel e gosto da implementação lá. Tentei imitá-lo e combiná-lo com a solução proposta por T. Stone (veja acima):

PRODUCTION_SERVERS = ['*.webfaction.com','*.whatever.com',]

def check_env():
    for item in PRODUCTION_SERVERS:
        match = re.match(r"(^." + item + "$)", socket.gethostname())
        if match:
            return True

if check_env():
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION

Talvez algo assim possa ajudá-lo.

Lembre-se de que settings.py é um arquivo de código ativo. Supondo que você não tenha DEBUG definido na produção (que é uma prática recomendada), você pode fazer algo como:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

Bastante básico, mas você poderia, em teoria, subir para qualquer nível de complexidade com base apenas no valor de DEBUG - ou em qualquer outra verificação de variável ou código que desejasse usar.

Para a maioria dos meus projetos, utilizo o seguinte padrão:

1. Crie settings_base.py onde armazeno configurações comuns a todos os ambientes
2. Sempre que preciso usar um novo ambiente com requisitos específicos, crio um novo arquivo de configurações (por exemplo, settings_local.py) que herda o conteúdo de settings_base.py e substitui / adiciona variáveis ​​de configurações apropriadas ( from settings_base import *)

(Para executar manage.py com configurações personalizadas arquivo que você simplesmente usar --settings opção de comando: manage.py <command> --settings=settings_you_wish_to_use.py)

Minha solução para esse problema também é uma mistura de algumas soluções já declaradas aqui:

• Eu mantenho um arquivo chamado local_settings.pyque tem o conteúdo USING_LOCAL = Trueem dev e USING_LOCAL = Falseem prod
• Em settings.pyfaço uma importação nesse arquivo para obter a USING_LOCALconfiguração

Baseei todas as minhas configurações dependentes do ambiente nessa:

DEBUG = USING_LOCAL
if USING_LOCAL:
    # dev database settings
else:
    # prod database settings

Prefiro isso a ter dois arquivos settings.py separados que preciso manter, pois posso manter minhas configurações estruturadas em um único arquivo mais fácil do que tê-las espalhadas por vários arquivos. Assim, quando atualizo uma configuração, não esqueço de fazê-lo nos dois ambientes.

É claro que todo método tem suas desvantagens e este não é uma exceção. O problema aqui é que não posso sobrescrever o local_settings.pyarquivo sempre que coloco minhas alterações em produção, o que significa que não posso copiar todos os arquivos às cegas, mas é algo com o qual posso conviver.

Eu uso uma variação do que jpartogi mencionado acima, que acho um pouco mais curto:

import platform
from django.core.management import execute_manager 

computername = platform.node()

try:
  settings = __import__(computername + '_settings')
except ImportError: 
  import sys
  sys.stderr.write("Error: Can't find the file '%r_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % (computername, __file__))
  sys.exit(1)

if __name__ == "__main__":
  execute_manager(settings)

Basicamente, em cada computador (desenvolvimento ou produção), tenho o arquivo hostname_settings.py apropriado que é carregado dinamicamente.

Há também as configurações elegantes do Django. Eu pessoalmente sou um grande fã disso. Foi construído por uma das pessoas mais ativas no Django IRC. Você usaria vários ambientes para definir as coisas.

http://django-classy-settings.readthedocs.io/en/latest/

1 - Crie uma nova pasta dentro do seu aplicativo e defina as configurações de nome para ele.

2 - Agora crie um novo __init__.pyarquivo nele e dentro dele escreva

from .base import *

try:
    from .local import *
except:
    pass

try:
    from .production import *
except:
    pass

3 - Crie três novos arquivos no nome da pasta de configurações local.pye production.pye base.py.

4 - No interior base.py, copie todo o conteúdo da settings.pypasta anterior e renomeie-o com algo diferente, digamos old_settings.py.

5 - Em base.py, altere o caminho BASE_DIR para apontar para o novo caminho de configuração

Caminho antigo-> BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Novo caminho -> BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

Dessa forma, o diretório do projeto pode ser estruturado e gerenciável entre produção e desenvolvimento local.

Para usar settingsconfigurações diferentes em ambientes diferentes, crie um arquivo de configurações diferentes. E no seu script de implementação, inicie o servidor usando o --settings=<my-settings.py>parâmetro, através do qual você pode usar diferentes configurações em diferentes ambientes.

Benefícios do uso dessa abordagem :

1. Suas configurações serão modulares com base em cada ambiente

2. Você pode importar o que master_settings.pycontém a configuração básica environmnet_configuration.pye substituir os valores que deseja alterar nesse ambiente.

3. Se você possui uma equipe enorme, cada desenvolvedor pode ter o seu, o local_settings.pyqual pode adicionar ao repositório de códigos sem nenhum risco de modificar a configuração do servidor. Você pode adicionar essas configurações locais .gitnorese usar o git ou .hginorese usar o Mercurial for Version Control (ou qualquer outro). Dessa forma, as configurações locais nem farão parte da base de código real, mantendo-a limpa.

Eu dividi minhas configurações da seguinte maneira

settings/
     |
     |- base.py
     |- dev.py
     |- prod.py  

Temos 3 ambientes

• dev
• encenação
• Produção

Agora, obviamente, a preparação e a produção devem ter o ambiente semelhante máximo possível. Então ficamos prod.pycom os dois.

Mas houve um caso em que eu tive que identificar o servidor em execução é um servidor de produção. @T. A resposta de Stone me ajudou a escrever o cheque da seguinte forma.

from socket import gethostname, gethostbyname  
PROD_HOSTS = ["webserver1", "webserver2"]

DEBUG = False
ALLOWED_HOSTS = [gethostname(), gethostbyname(gethostname()),]


if any(host in PROD_HOSTS for host in ALLOWED_HOSTS):
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True  

Eu o diferencio em manage.py e criei dois arquivos de configurações separados: local_settings.py e prod_settings.py.

No manage.py, verifico se o servidor é servidor local ou servidor de produção. Se for um servidor local, ele carregaria local_settings.py e, como servidor de produção, carregaria prod_settings.py. Basicamente, é assim que ficaria:

#!/usr/bin/env python
import sys
import socket
from django.core.management import execute_manager 

ipaddress = socket.gethostbyname( socket.gethostname() )
if ipaddress == '127.0.0.1':
    try:
        import local_settings # Assumed to be in the same directory.
        settings = local_settings
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'local_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:
    try:
        import prod_settings # Assumed to be in the same directory.
        settings = prod_settings    
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'prod_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file prod_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

Achei mais fácil separar o arquivo de configurações em dois arquivos separados, em vez de fazer muitos ifs dentro do arquivo de configurações.

Como alternativa para manter um arquivo diferente, se você quiser: Se você estiver usando o git ou qualquer outro VCS para enviar códigos do local para o servidor, o que você pode fazer é adicionar o arquivo de configurações ao .gitignore.

Isso permitirá que você tenha conteúdo diferente nos dois lugares, sem nenhum problema. SO no servidor, você pode configurar uma versão independente do settings.py e quaisquer alterações feitas no local não refletirão no servidor e vice-versa.

Além disso, ele removerá o arquivo settings.py do github também, a grande falha, que eu já vi muitos novatos fazendo.

Criar várias versões do settings.py é um antipadrão para a metodologia do 12 Factor App . use python-desacoplamento ou django-environ .

Eu acho que a melhor solução é sugerida por @T. Stone, mas não sei por que simplesmente não use a flag DEBUG no Django. Escreva o código abaixo para o meu site:

if DEBUG:
    from .local_settings import *

Sempre as soluções simples são melhores que as complexas.

Eu achei as respostas aqui muito úteis. (Isso foi resolvido de forma mais definitiva? A última resposta foi um ano atrás.) Depois de considerar todas as abordagens listadas, criei uma solução que não vi listada aqui.

Meus critérios foram:

• Tudo deve estar no controle de origem. Eu não gosto de pedaços complicados por aí.
• Idealmente, mantenha as configurações em um arquivo. Eu esqueço as coisas se eu não estiver olhando direito para elas :)
• Não há edições manuais para implantar. Deve poder testar / enviar por push / implantar com um único comando de malha.
• Evite vazar configurações de desenvolvimento para a produção.
• Mantenha o mais próximo possível do layout Django "padrão" (* tosse *) possível.

Eu pensei que ligar a máquina host fazia algum sentido, mas depois percebi que o problema real aqui é configurações diferentes para ambientes diferentes , e tive um momento aha. Coloquei esse código no final do meu arquivo settings.py:

try:
    os.environ['DJANGO_DEVELOPMENT_SERVER'] # throws error if unset
    DEBUG = True
    TEMPLATE_DEBUG = True
    # This is naive but possible. Could also redeclare full app set to control ordering. 
    # Note that it requires a list rather than the generated tuple.
    INSTALLED_APPS.extend([
        'debug_toolbar',
        'django_nose',
    ])
    # Production database settings, alternate static/media paths, etc...
except KeyError: 
    print 'DJANGO_DEVELOPMENT_SERVER environment var not set; using production settings'

Dessa forma, o aplicativo padroniza as configurações de produção, o que significa que você está explicitamente na "lista de permissões" de seu ambiente de desenvolvimento. É muito mais seguro esquecer de definir a variável de ambiente localmente do que se fosse o contrário e você esqueceu de definir algo na produção e permitir que algumas configurações de desenvolvimento sejam usadas.

Ao desenvolver localmente, a partir do shell ou em um .bash_profile ou em qualquer outro lugar:

$ export DJANGO_DEVELOPMENT_SERVER=yep

(Ou, se você estiver desenvolvendo no Windows, defina através do Painel de Controle ou como é chamado hoje em dia ... O Windows sempre o tornou tão obscuro que você pode definir variáveis ​​de ambiente.

Com essa abordagem, as configurações do desenvolvedor estão todas em um local (padrão) e simplesmente substituem as configurações de produção, quando necessário. Qualquer alteração nas configurações de desenvolvimento deve ser completamente segura para se comprometer com o controle de origem, sem impacto na produção.