Как я могу управлять другими настройками для моего приложения Ruby on Rails в зависимости от производства или разработки?

Question

Я пытаюсь развернуть свое первое приложение на rails и немного борюсь. Я планирую сначала разместить его на бесплатной учетной записи heroku, чтобы почувствовать живое развертывание и провести некоторое производственное тестирование. В конце концов я мог бы переместить его на VPS.

Я использую git и не использую Capistrano в данный момент.

Heroku в основном использует git, что нормально, но git управляет всем состоянием проекта, а не файлами. Поэтому у меня есть проблемы с управлением файлами конфигурации, которые отличаются от производства к разработке, например, ключи капчи в environment.rb или goolge js api keys. Так что я сделал, чтобы ..

1 - Извлеките специфическую для среды конфигурацию из enviornment.rb и поместите ее в файлы development.rb и production.rb. Создал ветку с названием dev, где я делаю свою разработку, а затем объединяю ее с master и push master на рабочий пульт heroku.

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

Другая серьезная проблема заключается в том, что мне, возможно, придется использовать разные драгоценные камни в dev и herouku. Например, я использую ThinkingSphinix для поиска в dev, но в Heroku мне нужно использовать activ_as_solr, что означает, что мой вызов Article.search в контроллере должен быть Article.find_by_solr на производстве. Это может очень быстро запутаться.

Какой лучший способ справиться с такой ситуацией?

Спасибо

Answer 1

Для значений, которые вы хотите оставить разными в разных средах, Heroku предлагает config vars .

Что касается использования одной программы индексирования в производстве, а другой в разработке, то это плохая идея, и она будет намного более запутанной, чем она должна быть. Либо начните использовать Solr локально, либо создайте экземпляр Thinking Sphinx в EC2 самостоятельно и подключите к нему своих динамовцев.

Answer 2

Для нечувствительных ключей, таких как ключ Google JS API и т. Д., Я нашел этот эпизод RailsCasts очень полезным.

Просто создал файл конфигурации в config/ и сохраните свою разработкутам есть настройки.

# /config/google.yml
development:
  google:
    js:
      key: 123456

test:
  google:
    js:
      key: 345678

production:
  google:
    js:
      key: 567890

Затем создайте инициализатор внутри config/initializers/, который будет анализировать yaml и создавать объект, который можно использовать, не беспокоясь о текущей среде.

# /config/initializers/google.rb
GOOGLE_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/google.yml")[RAILS_ENV]

Переменная среды RAILS_ENV относится к текущей среде, поэтому при запуске приложения она выбирает текущий тип, и вы можете обратиться к настройкам в вашем коде через GOOGLE_CONFIG:

<script type="text/javascript" src="http://www.google.com/jsapi?key=<%= GOOGLE_CONFIG['js']['key'] %>"></script>

Для последнегоЯ считаю, что проблема в том, что сам код отличается от среды к среде. Лучшим решением будет Capistrano.

Answer 3

Я бы предположил, что очень неразумно иметь другой код в разработке и производстве. Ваша среда разработки, тестирования и производства должна быть максимально похожей. На самом деле, я бы сказал, что весь смысл различных сред состоит в том, чтобы просто предоставить простую систему, позволяющую вносить незначительные изменения конфигурации между установками. Разные базы данных, разные параметры API, разные варианты ноки, но основная система ДОЛЖНА быть одинаковой.

Проблема, с которой вы столкнетесь, заключается в удвоении ваших усилий по разработке. Вы все еще должны написать код. Таким образом, в приведенном выше примере поиска вам придется разрабатывать и тестировать дважды - один раз для производственной системы Solr и один раз для локального Sphinx, а затем вам нужно будет иметь возможность переключаться и тестировать два подхода во всех ваших средах обеспечить тестовое покрытие и функциональность.