Существует несколько распространенных практик для решения этой ситуации, если вы не хотите использовать перехватчики Git или другие методы для изменения реального кода при развертывании.
Конфигурация на основе среды
Если вы не возражаете против того, чтобы производственные значения были указаны в вашей конфигурации в вашем хранилище, вы можете сделать их основанными на среде. Я иногда использую что-то вроде этого:
# config/application.yml
default:
facebook:
app_id: app_id_for_dev_and_test
app_secret: app_secret_for_dev_and_test
api_key: api_key_for_dev_and_test
production:
facebook:
app_id: app_id_for_production
app_secret: app_secret_for_production
api_key: api_key_for_production
# config/initializers/app_config.rb
require 'yaml'
yaml_data = YAML::load(ERB.new(IO.read(File.join(Rails.root, 'config', 'application.yml'))).result)
config = yaml_data["default"]
begin
config.merge! yaml_data[Rails.env]
rescue TypeError
# nothing specified for this environment; do nothing
end
APP_CONFIG = HashWithIndifferentAccess.new(config)
Теперь вы можете получить доступ к данным, например, с помощью APP_CONFIG[:facebook][:app_id], и значение будет автоматически отличаться в зависимости от среды, в которой было загружено приложение.
Конфигурация на основе переменных среды
Другой вариант - указать производственные данные через переменные среды. Heroku позволяет вам сделать это через config vars .
Настройте свой код на использование значения в зависимости от среды (возможно, с дополнительными значениями по умолчанию):
facebook_app_id = ENV['FB_APP_ID'] || 'some default value'
Создайте производственную конфигурацию var на Heroku, набрав в консоли:
heroku config:add FB_APP_ID=the_fb_app_id_to_use
Теперь ENV['FB_APP_ID'] - the_fb_app_id_to_use в производстве (Heroku) и 'some default value' в разработке и тестировании.
В приведенной выше документации Heroku содержится более подробная информация об этой стратегии.