Как использовать git для поддержки немного другой копии производственного исходного кода? - PullRequest
Новая
       27

Как использовать git для поддержки немного другой копии производственного исходного кода?

5 голосов
/ 03 мая 2011

У меня есть приложение Ruby on Rails, которое отправляет электронные письма.

В работе я хочу использовать какой-нибудь X SMTP-сервер, но в разработке я хочу использовать другой SMTP-сервер (таким образом, мой файл конфигурациинастройки SMTP различаются в средах разработки и производства)

Поэтому мне нужно сохранить 2 файла конфигурации (по одному файлу для настроек SMTP среды разработки / производства).

По состоянию натеперь я сохраняю настройки для Y STMP в файле на моей машине для разработки.Я клонирую рабочий код из репозитория github, изменяю рабочую копию с настройками Y SMTP и продолжаю.Затем, когда мне нужно отправить изменения в github, я полностью изменяю процесс.Это работает, но я думаю, что должен быть лучший способ?

Что такое "мерзавец" для обработки такого рода "небольших различий" между базами разработки и производственным кодом?

ОБНОВЛЕНИЕ

За @Mike Axiak, это поток, который вы имеете в виду: (предположим для простоты, что я не использую ln, но использую метод copy)

Настройте исходный код, чтобы на локальном компьютере было 2 файла настроек:

  • smtp.settings.prod
  • smtp.settings.dev

Оба добавлены в .gitignore

Для работы с локальной копией:

  • Извлечение кода из github
  • Копирование smtp.settings.devв smtp.settings
  • Использование.

Чтобы отправить изменения на сервер:

  • Непосредственно перед отправкой скопируйте файл smtp.settings.prod в smtp.settings
  • Push

Если вы это имели в виду, есть ли способ автоматизировать процесс копирования с помощью git?

Ответы [ 5 ]

5 голосов
/ 03 мая 2011

Rails уже поддерживает подобные вещи, используя файлы в каталоге конфигурации / сред. Просто добавьте свои настройки в соответствующий файл.

3 голосов
/ 03 мая 2011

В большинстве мест я имел дело с небольшим файлом конфигурации переопределения, обычно с суффиксом .prod или .dev.Затем в фактической проверенной среде вы используете ln для символической ссылки (или в копии Windows) текущего файла на имя файла реальных настроек.Затем вы говорите git игнорировать файл настроек (используя .gitignore)

1 голос
/ 04 мая 2011

Делайте то, что делает Gitorious, он использует поддержку configuration/environments и вы предоставляете скрипту переменную окружения RAILS_ENV, чтобы он знал, какую конфигурацию использовать.

Один каталог, несколько конфигураций.Удалите неиспользуемые конфиги при продвижении выпуска в производство.

Я также сделал нечто подобное, но более автоматическое, основав конфигурацию на имени хоста сервера, на котором она развернута.dev.mycompany.com против test.mycompany.com против mycompany.com Есть много более автоматизированных способов сделать это, чем манипулирование несколькими файлами, что является просто рецептом человеческих ошибок и страданий.

1 голос
/ 03 мая 2011

Если файлы конфигурации не меняются все время, я обычно сохраняю версионный файл универсального файла настроек в хранилище, скажем, settings.conf.dist, а затем добавляю settings.conf к моему .gitignore.Теперь, когда я клонирую свежий репозиторий, я бы просто cp settings.conf.dist settings.conf сделал копию (игнорируемую git) настроек приложения, а затем изменил по мере необходимости.

Преимущество в том, что вам никогда не придется об этом беспокоитьсяпри совершении / толкании / вытягивании.Недостатком является то, что когда вы вносите изменения, такие как добавление нового параметра, вы не забудьте поместить его в версию .dist, а также добавить его отдельно в каждый локальный файл settings.conf.Как я уже сказал, работает лучше всего, когда вы не добавляете новые настройки все время.

Редактировать: У меня есть только настройки, которые будут изменяться на машинах в этих локальныхфайлы настроек.Если бы у вас были другие настройки, которые были бы одинаковыми для всех сайтов, у меня был бы другой файл конфигурации для этого, который затем включал бы «локальный» файл настроек.

0 голосов
/ 03 мая 2011

Я решил это так. С небольшой помощью .bash_aliases. 

git clone
git checkout -b production.conf

При необходимости измените config.file. 

git commit -a
git checkout master

Сделайте что-нибудь с рабочей копией. 

git checkout production.conf -- config.file
git commit -a
git push
...