Переменные среды или файлы конфигурации YAML

Предыстория:
Шаг 1 - > у нас есть окно, которое выполняет модульные и функциональные тесты приложения, запустив его в тестовом режиме с определенной конфигурацией.
Шаг 2 - > После успеха шага 1 мы запускаем интеграционные тесты приложения, запустив его в тестовом режиме с другим набором конфигурации в другом окне.
Шаг 3 - > После успеха шага 2 мы запускаем тесты производительности приложения, запустив его в производственном режиме, в тесте производительности коробка.
Шаг 4 - > После успеха шага 3 Сборка считается стабильной, и поле UAT обновляется с этой базой кода, и приложение запускается в производственном режиме для обзора клиентов и обратной связи. Шаг 5 - > с GO от клиента, производственная коробка обновляется с базой кода.

теперь, из вышеуказанных шагов мы наблюдаем, что в шагах 1 и 2, в то время как приложение работает в тестовом режиме, оно имеет другую конфигурацию. Аналогично обстоит дело с шагами 3,4 и 5.

в таких ситуациях, какова рекомендуемая практика? У нас были файлы конфигурации YAML, но лично я чувствовал, что поддержание многочисленных файлов конфигурации не имеет смысла. Итак, я перешел от практики
"конфигурационный файл для каждой среды"
к
"конфигурационный файл в режиме rails, экстернализация переменных в среду linux".

Я на правильном пути? Разве мои действия не упрощают ситуацию?

каковы плюсы и минусы этих двух подходов?

7
jrubyonrails ruby-on-rails

3 ответов

по моему опыту, переменные среды являются опцией конфигурации последней инстанции. Они абсолютно имеют свое место, но, как правило, должны сначала проверить другие, более надежные и явно преднамеренной конфигурации. Я бы настоятельно рекомендовал загрузить конфигурацию из файла YAML и использовать только переменную среды в качестве резервного. Всегда предполагайте, что ваша переменная среды будет применяться ко всему общесистемному и предполагается, что она будет случайно получить unset или установить неправильное значение в какой-то момент. т. е. ваше приложение не должно совершать seppuku, потому что некоторый каталог конфигурации установлен в / и у него нет разрешений на него (или хуже, вы стираете диск, потому что приложение работает как root). Или, что более вероятно, что-то вроде вашего RAILS_ENV был установлен до test когда это должно было быть production и никто не понял, и теперь пользователи пишут данные в неправильном месте или /dev/null из-за всех 500s.

лично мне нравится падение logger.warn сообщения в любое время я возвращаюсь к переменной среды для значения конфигурации.

С вашей точной проблемой, честно говоря, я бы, вероятно, передал значение конфигурации, для которой среда запускается в командной строке.

11

в моей компании у нас есть и то, и другое.

У нас есть приложение Rails, которое может указывать на одну из многих различных установок другого программного обеспечения и использовать API из этой установки. Чтобы указать установку, необходимо задать около 5 переменных.

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

Итак, теперь у нас есть одна переменная среды мы вызываем ENV_TOKEN, и у нас есть файлы yaml, содержащие записи, соответствующие допустимым переменным ENV_TOKEN, и код в config/initializers, который устанавливает ENV[key]=value.

Итак, предположим, у меня есть переменные "FOO" и "BAR", которые я хочу установить в "one" и " two " соответственно. Я мог бы создать файл yaml, содержащий:

carolclarinet:
  FOO: one
  BAR: two

и затем я бы установил переменную среды ENV_TOKEN в carolclarinet, а FOO и BAR - в один и два.

У меня нет идея, если это лучший способ сделать это, но это работает для нас.

ETA: обратите внимание, что это только для разработки и тестирования, установщик нашего программного обеспечения заботится о настройке всего этого, чтобы наши клиенты никогда не меняли переменные среды.

0

после многих тщетных поисков в гугле, обсуждений с некоторыми людьми rails и некоторых мозговых ударов, я внес изменения в код так, что у меня есть "файл конфигурации в режиме rails, экстернализация конфигураций приложений в файл yml, который в моем случае остается вне среды rails"

более подробную информацию об этом можно найти в моем блоге по адресуhttp://bit.ly/hpChwl

спасибо всем, что поделились своими мыслями. Надеюсь, мое решение интересует вас всех:)

0