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

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

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

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

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

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

3 ответа

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

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

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


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

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

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

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

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

carolclarinet:
 FOO: one
 BAR: two

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

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

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


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

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

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

licensed under cc by-sa 3.0 with attribution.