#ruby-on-rails #configuration #config #environment
#ruby-on-rails #конфигурация #Окружающая среда
Вопрос:
У меня есть приложение Ruby on Rails, которое рассылает электронные письма.
В рабочей среде я хочу использовать какой-нибудь X SMTP-сервер, но в разработке я хочу использовать какой-нибудь другой SMTP-сервер (таким образом, мой файл конфигурации для настроек SMTP отличается в средах разработки и производственной среде)
Итак, мне нужно поддерживать 2 файла конфигурации (по одному файлу для настроек SMTP в средах разработки / производства).
На данный момент я сохраняю настройки для Y STMP в файле на моей машине разработки. Я клонирую производственный код из репозитория github, изменяю рабочую копию с настройками для Y SMTP и продолжаю. Затем, когда мне нужно отправить изменения на github, я переворачиваю процесс. Это работает, но я думаю, что должен быть способ получше?
Что такое «git way» для обработки такого рода «небольших различий» между базами кода разработки и производства?
Обновить
Согласно @Mike Axiak, вы имеете в виду именно этот поток: (предположим для простоты, что я не использую ln , но использую copy метод)
Настройте исходный код так, чтобы на локальном компьютере было 2 файла настроек:
- smtp.settings.prod
- smtp.settings.dev
Оба добавляются в .gitignore
Для работы с локальной копией:
- Извлеките код из github
- Скопируйте smtp.settings.dev в smtp.settings
- Используйте.
Для отправки изменений на сервер:
- Непосредственно перед запуском скопируйте файл smtp.settings.prod в smtp.settings
- Толкать
Если это то, что вы имели в виду, есть ли какой-нибудь способ автоматизировать процесс копирования с помощью git?
Ответ №1:
Rails уже поддерживают такого рода вещи, используя файлы в каталоге configuration / environments. Просто добавьте свои настройки в соответствующий файл.
Ответ №2:
В большинстве мест я справлялся с этим, имея небольшой файл конфигурации переопределения, обычно с суффиксом .prod или .dev. Затем в реальной извлеченной среде вы используете ln для символической ссылки (или в копии Windows) текущего файла на реальное имя файла настроек. Затем вы говорите git игнорировать файл настроек (используя .gitignore)
Комментарии:
1. Или у вас есть скрипт с контролем версий для этого.
2. это ручной процесс, который приходится повторять человеку; таким образом, он подвержен ошибкам и должен выполняться для каждого разработчика в команде, что увеличивает вероятность ошибки и подрывает
configuration/environmentsфункциональность, которая есть в Rails для обработки именно этого варианта использования, поэтому это нестандартная еще одна причина не делать это таким образом
Ответ №3:
Если конфигурационные файлы не меняются постоянно, я обычно сохраняю версию файла общих настроек, скажем, в репозитории settings.conf.dist , а затем добавляю settings.conf в свой .gitignore . Теперь, когда я клонирую новый репозиторий, я бы просто cp settings.conf.dist settings.conf сделал копию (игнорируемую git) настроек приложения, а затем изменил по мере необходимости.
Преимущество в том, что вам никогда не придется беспокоиться об этом при фиксации / нажатии / извлечении. Недостатком является то, что когда вы вносите изменения, например, добавляете новую настройку, вам нужно не забывать вносить ее в .dist версию, а также добавлять ее отдельно в каждый локальный settings.conf файл. Как я уже сказал, работает лучше всего, когда вы не добавляете новые настройки постоянно.
Редактировать: у меня есть только настройки, которые будут меняться на разных компьютерах в этих локальных файлах настроек. Если бы у вас были другие настройки, которые были бы одинаковыми для всех сайтов, у меня был бы другой конфигурационный файл для этого, который затем включал бы файл «локальных» настроек.
Ответ №4:
Делайте то, что делает Gitorious, он использует configuration/environments поддержку, и вы предоставляете RAILS_ENV переменную среды скрипту при его запуске, чтобы он знал, какую конфигурацию использовать.
Один каталог, несколько конфигураций. Удаляйте неиспользуемые конфигурации при продвижении выпуска в производство.
Я также сделал нечто подобное, но более автоматическое, основывая конфигурацию на имени хоста сервера, на котором он развернут. dev.mycompany.com против test.mycompany.com vs mycompany.com существует множество более автоматизированных способов сделать это, чем манипулирование несколькими файлами, это просто путь к человеческим ошибкам и страданиям.
Ответ №5:
Я решил это следующим образом. С небольшой помощью от .bash_aliases.
git clone
git checkout -b production.conf
Измените конфигурацию.файл по мере необходимости.
git commit -a
git checkout master
Сделайте что-нибудь с рабочей копией.
git checkout production.conf -- config.file
git commit -a
git push