2011-01-12 4 views
7

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

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

В таких ситуациях, что рекомендуется? У нас были файлы конфигурации YAML, но лично я чувствовал, что сохранение многочисленных файлов конфигурации не имеет смысла. И так, я изменил из практики
«Config файла в среду»
в
«Config файл в режиме рельсов, экстернализация переменных в Linux среду».

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

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

ответ

11

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

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

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

+0

Спасибо. Это основано на вашем утверждении, что переменные окружения для конфигурации приложения - это последнее примененное действие, и ваш совет использовать файл YAML для загрузки конфигураций приложений, я придумал дизайн, который я написал в блоге в своем сообщении. Ваш ответ удвоил мою страсть к решению. Снова спасибо! – karthiks

+0

Да, это, миллион раз. Конфигурационные файлы становятся беспорядочными, чем среда. Кроме того, когда вы перечитываете файл конфигурации, вы получаете последнее сохраненное значение. Я не могу сказать вам, сколько раз мне приходилось объяснять людям, что вы должны явно изменить текущую переменную среды вашего конкретного оболочки или убить свою оболочку после изменения .profile и перезапустить ее, чтобы загрузить обновленную переменную среды. Это смущает людей. Просто используйте файл конфигурации. – kmort

0

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

У нас есть приложение 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: Обратите внимание, что это только для разработки и тестирования, установщик нашего программного обеспечения позаботится об установке всего этого, чтобы наши клиенты никогда не меняли каких-либо переменных среды.

+0

Я не уверен, что это лучший способ или нет, но это определенно улучшение. –

0

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

Подробнее о нем можно найти в моем блоге на http://bit.ly/hpChwl

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

 Смежные вопросы

  • Нет связанных вопросов^_^