IN
У тебя наверное очень большие .env-файлы
Size: a a a
2020 May 18
АШ
это дает независимость команде админов деплоить приложение куда они хотят не трогая разрабов
IN
Хотя да, если они генерятся ансиблом то это не беда
АШ
приложение большое, да, но я про сам подход
w
Это конечно решение, но имхо довольно радикальное. Не получается что ты при этом часть логики приложения утаскиваешь в инфраструктуру?
Rails.env.production — это ваще жесть, вон в докере оно постоянно продакшн, и на стейдже у нас тоже в продакшен окружение
m
это равносильно тому что у вас вообще нет "окружения" (в том смысле как это понимают рельсы), есть только флаги, которые вы передаете в приложение
но "окружение" и было придумано ровно с той целью, что бы эти флаги сгруппировать и переиспользовать - а вы пошли в обратную сторону
нравится - на здоровье, но мы говорим о ситуации когда люди хотят "окружения"
но "окружение" и было придумано ровно с той целью, что бы эти флаги сгруппировать и переиспользовать - а вы пошли в обратную сторону
нравится - на здоровье, но мы говорим о ситуации когда люди хотят "окружения"
АШ
а вот скажите мне когда "окружение" вам реально помогло
IN
приложение большое, да, но я про сам подход
Но все равно блин плоская струтура переменнных по сути остается.
АШ
да, с переменными окружения это большой минус
АШ
если очень нужна иерархия, то можно идти на компромисс, например, засунуть в переменную json (так себе решение, конечно) или использовать ERB в YAML-конфигах как вы показали раньше
IM
Это конечно решение, но имхо довольно радикальное. Не получается что ты при этом часть логики приложения утаскиваешь в инфраструктуру?
мне кажется, что production/staging/dev это и есть та самая инфраструктура, на которую вешается слишком много логики
АШ
12 factors разделяют конфигурацию и код. Конфигурация - это то, что меняется между окружениями, например, пароль к базе. А код - это то, что не меняется, например, роуты в вашем приложении. Если что-то не меняется, то это следует коммитить в репозиторий, например,
MONTHS_AMOUNT=12, все остальное следует читать снаружи.IN
12 factors разделяют конфигурацию и код. Конфигурация - это то, что меняется между окружениями, например, пароль к базе. А код - это то, что не меняется, например, роуты в вашем приложении. Если что-то не меняется, то это следует коммитить в репозиторий, например,
MONTHS_AMOUNT=12, все остальное следует читать снаружи.У тебя рассуждения на уровне "как должен быть устроен идеальный фрэймворк", а у меня статья "как в обычном среднем рельсоприложении не воюя против фрэймворка достигнуть sanity" )
А так да, я со многим даже пожалуй соглашусь
А так да, я со многим даже пожалуй соглашусь
АШ
ммм, ну да, поэтому мне во многом рельсы уже не нравятся
АШ
букетно-конфетный период уже давно прошел :)
IN
букетно-конфетный период уже давно прошел :)
это норм, просто ты не ЦА этого поста )
АШ
Я исхожу из позиции удобства деплоя приложения в облако. Мне кажется, что при описании конфигов DSL-ем в руби, это будет не очень удобно.
АШ
Опять же придется на каждое значение писать `
aws.bucket.name = ENV['AWS_BUCKET_NAME']` и все в таком духеm
а как у вас переменная окружения
SETTINGS__EMAILS_ENABLED = false попадает в Settings.app.emails.enabled? разве не так же?АШ
ну гем
config этим занимается