Как управлять локальными и производственными настройками в Django?

Question

Каков рекомендуемый способ обработки настроек для локальной разработки и рабочего сервера? Некоторые из них (например, константы и т. Д.) Могут быть изменены / доступны в обоих, но некоторые из них (например, пути к статическим файлам) должны оставаться разными и, следовательно, не должны перезаписываться при каждом развертывании нового кода.

В настоящее время я добавляю все константы к settings.py. Но каждый раз, когда я изменяю некоторую константу локально, мне приходится копировать ее на рабочий сервер и редактировать файл для конкретных производственных изменений ... :(

Редактировать: похоже, что нет стандартного ответа на этот вопрос, я принял самый популярный метод.

Answer 1

Я думаю, что лучшее решение предлагает @T. Камень, но я не знаю, почему просто не использовать флаг DEBUG в Django. Я пишу код ниже для моего сайта:

if DEBUG:
    from .local_settings import *

Всегда простые решения лучше сложных.

Answer 2

Я нашел ответы здесь очень полезными. (Было ли это решено более окончательно? Последний ответ был год назад.) После рассмотрения всех перечисленных подходов я нашел решение, которого здесь не увидел.

Мои критерии были:

• Все должно быть в системе контроля версий. Я не люблю неряшливые биты, валяющиеся вокруг.
• В идеале, хранить настройки в одном файле. Я забываю вещи, если не смотрю прямо на них:)
• Нет ручного редактирования для развертывания. Должен быть в состоянии протестировать / отправить / развернуть с помощью одной команды фабрики.
• Избегайте утечки настроек разработки в производство.
• Держите как можно ближе к «стандартному» (* кашель *) макету Django, насколько это возможно.

Я думал, что переключение на хост-машину имело какой-то смысл, но потом понял, что реальная проблема заключается в разных настройках для сред , и у них был момент ага. Я поместил этот код в end моего файла 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'

Таким образом, приложение по умолчанию настроено на производственные настройки, что означает, что вы явно «заносите в белый список» свою среду разработки. Гораздо безопаснее забыть установить переменную окружения локально, чем если бы это было наоборот, и вы забыли установить что-то в работе и позволить использовать некоторые настройки dev.

При локальной разработке, либо из оболочки, либо в файле .bash_profile, либо где-либо:

$ export DJANGO_DEVELOPMENT_SERVER=yep

(Или, если вы разрабатываете для Windows, настраиваете через панель управления или как ее еще называют в наши дни ... Windows всегда делала это настолько неясным, что вы могли устанавливать переменные окружения.)

При таком подходе все настройки dev находятся в одном (стандартном) месте и просто переопределяют производственные при необходимости. Любое переключение с настройками разработки должно быть полностью безопасным, чтобы взять на себя контроль над исходным кодом без ущерба для производства.