GIt Развертывание + файлы конфигурации + Heroku

Я использую Heroku для размещения приложения Rails, что означает использование Git для развертывания в Heroku. Из-за "чистого Git рабочего процесса" на Heroku все, что должно идти вверх по течению к серверу, должно быть настроено идентично в моем локальном поле.

Однако мне нужно, чтобы определенные файлы конфигурации были разными, в зависимости от того, находится ли я в локальной установке или развернута на Heroku. Опять же, из-за метода развертывания Heroku я не могу использовать .gitignore и шаблон (как я уже неоднократно видел, и использовал его в других проектах).

Мне нужно, чтобы Git каким-то образом отслеживал изменения в файле, но выборочно указывал Git не переопределять определенные файлы при выводе из определенного репо - в основном для внесения определенных изменений только в одну сторону.

Можно ли это сделать? Буду признателен за любые предложения!

ОТВЕТЫ

Ответ 1

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

Это подход, который мы использовали. (Мы использовали его для ТОЧНОЙ вещи... у нас есть несколько клонов приложения SAME в Heroku, но мы хотим только одного источника в github, в нашем локальном каталоге dev мы делаем PUSH для ORIGIN (github), тогда, когда у нас есть так как нам это нравится, мы CD в локальный каталог prod, который отправляется в SAME репозиторий github, и мы ТОЛЬКО PULL из GITHUB в этот каталог, никогда не нажимаем (например, все нажатия на github приходят из нашего каталога dev каталог prod - это просто промежуточная область для другого приложения heroku.)

По , имеющему разные конфигурации на разных сайтах HEROKU (как описано ниже), EXACT SAME CODE работает на BOTH сайтах heroku.

Итак, наш рабочий процесс: (ключ в том, что каталоги BOTH указывают на SAME github repo)

cd myDEVdir
*....develop away....*
git add .
git commit -am "another day, another push"
git push origin  *(to our SINGLE github repo)*
git push heroku  *(test it out on heroku #1)*

cd ../myPRODdir
git pull         *(grabs SAME code as used on other site *)
git push heroku  *(now the SAME code runs on Heroku #2)*

что это!

Теперь, как вы храните свой сайт-специфический конфиг на сайте heroku:

http://docs.heroku.com/config-vars

в локальной командной строке, для каждого из двух локальных каталогов выполните:

$ heroku config:add FIRST_CONFIGVAR=fooheroku1
Adding config vars:
  FIRST_CONFIGVAR => fooheroku1

$ heroku config:add SECOND_CONFIGVAR=barheroku1
Adding config vars:
  SECOND_CONFIGVAR => barheroku1

чтобы увидеть те, которые вы определили:

$ heroku config
FIRST_CONFIGVAR => fooheroku1
SECOND_CONFIGVAR => barheroku1

затем cd в другой каталог myPRODdir и сделайте ТОЧНУЮ вещь, установите только одни и те же удаленные геры героя для fooheroku2 и barheroku2.

то в вашем приложении rails вы просто ссылаетесь на них так:

a = ENV['FIRST_CONFIGVAR']

В одном приложении будет читаться "fooheroku1", другое приложение будет читать "fooheroku2"

И наконец, в вашем ЛОКАЛЬНОМ каталоге myDEVdir, где вы запускаете в режиме DEV, поместите те же команды config в свой файл config/environment/development.rb, что ваша версия dev будет установлена ​​так, как бы они ни были:

ENV['FIRST_CONFIGVAR'] = "foodev"
ENV['SECOND_CONFIGVAR'] = "bardev"

Легкий, элегантный. Спасибо, Heroku!

Ответ 2

Вот несколько решений:

1) Если вы хотите игнорировать файлы только на heroku, используйте slugignore

2) Если ваши изменения незначительны, оставайтесь DRY и используйте универсальные файлы конфигурации, вставляя переключатели для поведения, характерного для сервера.

if Rails.env == "production"
    #production server code
elsif Rails.env == "development"
    #development server code
else
    #test server code
end

3) Если ваши изменения значительны, напишите один файл конфигурации и добавьте "файл smudge" в конфигурацию/инициализаторы для каждого дополнительного сервера. В принципе, у вас будут отдельные файлы, используя технику в (2).

4) Если ваши изменения SWEEPING (маловероятно), то поддерживайте отдельные ветки для каждого сервера.

5) Этот script может выполнять именно то, что вы просили, но может быть излишним.

Я надеюсь, что это помогло.