Конфигурация. dev vs production

[rimmer333]

У меня была другая мысль на эту тему: в массив или хэш заносим как настройки как для developer, так и для production. Затем на девелоперских (или на тестовых) машинах настраиваем переменную среды, равную некоему значению, по которому можно найти соотв. настройки в вышеописанном массиве. Затем при загрузке настроек просто извлекаем их их массива, пользуясь переменной среды как ключом. Игнорить ничего не надо, конфиг можно спокойно заливать с девелоперских и тестовых машин на сервер, на боевом сервере воротить ничего не надо (разумеется, следует предусмотреть вариант, когда переменная среды не установлена).

[marazm]

Не кажется, что это гемор?

[Honeyman]

Раньше я делал примерно похоже на описанный marazm-ом способ, только "ровно наоборот".
Меня абсолютно не устраивал подход, при котором хоть локальный, хоть продакшновый файл с настройками не попадает в репозиторий, поэтому мне надо было сделать так, чтобы каждый из файлов был доступен, попадал в репозиторий, но на каждой из машин срабатывали только актуальные настройки. Поэтому я завёл файлы settings_common.py (содержащие всякие MIDDLEWARE_CLASSES, INSTALLED_APPS и т.п.), а также файлы settings-laptop.py, settings-webfaction.py, settings-dedicated.py, каждый из которых включал специфичные для машины вещи, но помимо этого, делал "from settings_common import *". И последним пунктом, на каждой машине я просто делал симлинк с settings.py на нужный из settings-*.py.
Потом мне надоела негибкость этого, и я сделал ровно по-твоему. SetEnv DJANGO_HOSTING_NAME "webfaction" или SetEnv DJANGO_HOSTING_NAME "laptop", и внутри единственного settings.py проверки на значение os.environ.get('DJANGO_HOSTING_NAME', None). Всё в одном месте, комфортно и удобно, и в SVN-е бэкапится.

[googlebot]

М... Если количество девелоперов больше 1го - схема неудобная

[kivsiak]

Мне нравится. Максимально простой и в тоже время рабочий способ.

[glader]

Знаем и с удовольствием используем

[majesty]

И как же я, идиот, до этого не додумался ранее? :) Не джанговод, но и в пхп-проектах такой ход очень пригодится :)

[apk]

как вариант можно и так,
но вообще для этой цели придумали make, ant, rake...

[glader]

Не всегда для deployment-а используются пакеты.

[daevaorn]

Баян!:) Уже всё комьюнити этим сто лет как пользуется:)

[marazm]

Прочитайте ещё раз вступление

[daevaorn]

Ну баяном это быть не перестало, даже после вашего замечания. Лучше бы предложили новую концепцию какую-нибудь, чем мусолить уже давно известное.

[marazm]

Вам ещё не показалось странным, что у вас 3 минуса за первый комментарий?

[daevaorn]

Ой, да? И что? Нет, вы правы вот уже 3 минуса точно говорят, что тема не баян, а вот было бы 2, то точно он. Еле уловимая граница прям.

[marazm]

Если говорить языком подъёба, то прошу ссылку в студию, где на хабре данный вопрос уже поднимался. Да и хорошо бы за пределами хабра.

А минусы (как и комментарии) говорят о том, что тема оказалась полезна.

Прочитайте комментарии кроме своего и для вас откроется секрет.

[daevaorn]

Да сколько угодно!
http://code.djangoproject.com/wiki/SplitSettings
http://www.davidcramer.net/code/django/107/deploying-django.html
http://www.technobabble.dk/2007/aug/16/managing-local-settings-django/

[marazm]

Ну вот, ни одной ссылки с хабра. А за прочие спс.

[Lev_in]

Как насчет констант?

[marazm]

Когда-то и я писал на PHP :)

[Lev_in]

Вот и приходится придерживаться той же схемы, только вставлять if !defined

[Lev_in]

От PHP так просто не уйти... Постоянно что-то где-то докрутить надо, поправить, изменить...
Все бросить и переписать - невсегда подходит. =(

[hoodoy]

Symfony с самого начала создания проекта позволяет запускать/тестить его в dev и prod конфигурациях. Плюс можно свои конфигурации создовать.. Хм, не врут получается, когда пишут что взяли лучшее из других фреймворков. :)

[marazm]

Совсем не в тему.

[ESQUELETO]

А я купил новый культиватор и культивирую им поле! Он классный, работает на бензине! Хорошо, что я предпочел его Symfony!

[ESQUELETO]

Я совсем не гордый, поэтому скажу — я такого не знал.
Элегантный подход. Спасибо и в избранное.

[ESQUELETO]

а еще бы я «django» в теги добавил. хоть и в блоге про джанго, вклад в облако не сделан :-Р

[mjr27]

буду краток - спасибо! :)

[marazm]

Интересно за что карму минусят жёстко :-/

[nekufa]

Не знаю кто и за что, компенсировал в ответ. Полезный пост :)

[proxor]

Не догадался как-то :) Да и удавалось обойтись без этого. Круто, спасибо.

[ilvar]

Буквально вчера отказался участвовать в проекте, в котором в сеттингах было наворочено чего-то страшное - от выбора конфигурации в зависимости от имени машины и до кусков SQL каких-то. Остальное вроде выглядело поприличнее - тестами покрыто, не то чтобы страшно написано, но ощущение какое-то гнетущее производило :)

[marazm]

Даже могу предположить что за проект =)
Думаю, вы не ошиблись :)

[ilvar]

Судя по всему, вы правильно предполагаете :)

[alexbig]

у меня всегда две ветки разработки: production и development. это совершенно разные «папки» и, соответственно, конфиги они используют разные.
непозволительно мне ковыряться в коде, которым пользуются пользователи.

[glader]

А кто в нем ковыряется?

[alexbig]

я! :-)
имелось ввиду, что я не никогда не работаю с production кодом. туда только апдейты с development.

[korzhik]

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

[lost_shadow]

Мы организовываем настроечки чуть посложнее:
settings_base.py, целиком:
# Здесь описываем настройки, от которых зависят многие другие.
# В большинстве случае в новом экземпляре проекта
# достаточно подправить пути в этом файле.
sys.path.append('путь_до_библиотек_1')
sys.path.append('путь_до_библиотек_2')

PROJECT_ROOT = '/home/me/develop/project/'
MEDIA_ROOT = PROJECT_ROOT + 'media/'
SITE_URL = 'http://me:8000/'
ADMINS = (
('me', 'me@e-mail'),
)

Файл settings_base.py.sample, лежит в репозитории, settings_local.py игнорируется. Та же ситуация с settings_local.py.

часть settings.py:
from settings_base import *
# Здесь переопределяются настройки, зависимые от базовых.
# Далее часть grep-а по PROJECT_ROOT:
TEMPLATE_DIRS = (PROJECT_ROOT + 'templates/',)
LOCALE_PATHS = (PROJECT_ROOT + 'locale/',)
LOGGING_DIRECTORY = PROJECT_ROOT + 'log/'
APPLICATION1_COMMAND = 'java -parameters ' + PROJECT_ROOT + 'scripts/convertor.jar '
APPLICATION1_SETTINGS_FILE = PROJECT_ROOT + 'src/settings_format1.conf'
APPLICATION2_SCRIPTS_PATH = PROJECT_ROOT + 'module2_scripts_path/'
APPLICATION2_OBFUSCATE_COMMAND = 'java -parameters ' + PROJECT_ROOT + 'scripts/application2-obfuscator.jar %(source_file)s -o %(output_file)s'
APPLICATION3_TEMPLATES_ROOT = PROJECT_ROOT + 'templates/'
APPLICATION3_STYLES_ROOT = PROJECT_ROOT + 'styles/'
APPLICATION4_PARSER = PROJECT_ROOT + 'src/application4-parser/bla-bla-bla'
APPLICATION5_SERIALIZATION_DIRECTORY = PROJECT_ROOT + 'mymodule-data/'
# и ещё 4 сотни строк настроек разных приложений в том же духе, затем хвост:
from settings_local import *

часть settings_local.py:
# Здесь:
# 1) Переопределяются настройки, от которых, как правило,
# не зависят другие настройки.
# 2) Настраиваются специфичные обработчики - подключаются
# отладочные midlleware, добавляются консольные хандлеры для логгеров.
# Этот файл обычно небольшой.
import warnings
warnings.filterwarnings(action="error", category=DeprecationWarning)
warnings.filterwarnings(action="error", category=UserWarning)
DEBUG = True
TEMPLATE_DEBUG = True
APPLICATION6_USE_CACHE = False
SESSION_COOKIE_AGE = 14 * 24 * 3600 # 2 weeks
APPLICATION7_PERFORMANCE_LOG_INTERVAL = 3600
...

[marazm]

Кстати, PROJECT_ROOT можно динамически определять, что тоже проще... Хотя хз =)