Git: конфигурация приложения и различные среды - PullRequest
10 голосов
/ 09 июля 2010

Мы используем git для большинства веб-приложений, которые мы создаем в нашем магазине, и хотя сами приложения используют различные технологии (PHP, Rails и т. Д.), У нас обычно есть промежуточный и рабочий сервердля каждого сайта.Как правило, эти серверы имеют разные наборы учетных данных базы данных, а также различные параметры конфигурации на основе среды (например, кэширование).Наш рабочий процесс обычно включает в себя поддержку двух веток git на проект: master, который отражает рабочий сервер, и staging, который отражает staging.Новые функции разрабатываются на стадии подготовки (или дочерней ветви) и объединяются с главной при завершении и развертывании.

У меня вопрос относительно наилучшего способа поддержки файлов конфигурации, которые являются ветвью и средой-конкретный.Я видел ответы на подобные вопросы здесь и здесь , и ни один из них на самом деле не удовлетворяет.Основными двумя подходами, по-видимому, являются: а) использование исключения .gitignore, чтобы оставить файлы конфигурации вне сферы действия git, или б) написание рефлексивного кода, учитывающего среду, который определяет, например, какие учетные данные базы данных использовать на основе имени хоста.Моя проблема с а) в том, что он позволяет только одному набору файлов конфигурации существовать в кодовой базе (независимо от текущей ветви), поэтому файлы конфигурации другой среды теряются.b) с другой стороны, кажется, что требуется неоправданная модификация кодовой базы таким образом, который не имеет отношения к функциональности приложения.

В идеале, я бы хотел "заблокировать" конфигурациюфайлы в определенной ветви, так что всякий раз, когда я извлекаю master, я получаю файлы конфигурации master, а всякий раз, когда я извлекаю staging, я получаю файлы config размещения.Кроме того, объединение промежуточного уровня в главное не должно влиять на основные файлы конфигурации.На сегодняшний день мы имеем дело с этим, имея папки, содержащие специфические для среды файлы конфигурации за пределами git-корня, и вручную перемещая соответствующие файлы в базу кода при развертывании, но это, конечно, излишне хакерский (и потенциально опасный).

Есть ли способ сделать это с помощью git?

Спасибо за внимание!

Ответы [ 3 ]

12 голосов
/ 09 июля 2010

Не знаю, почему люди думают, что могут уйти без какого-либо инструмента для установки.Git - это отслеживание источника, а не развертывание.У вас по-прежнему должен быть инструмент типа «make install», чтобы перейти от вашего git-репо к реальному развертыванию, и этот инструмент может выполнять различные действия, такие как расширение шаблона или выбор альтернативных файлов.

Например, выдля git могут быть включены «config.staging» и «config.production», а при развертывании в промежуточный инструмент установки выбирает «config.staging» для копирования в «config».Или у вас может быть один файл «config.template», который будет настроен на «config» при развертывании.

3 голосов
/ 27 декабря 2011

Вы можете попробовать использовать хуки после слияния или после проверки, чтобы убедиться, что все в порядке, и исправить это в противном случае. Это на самом деле , кажется, предложено книгой ProGit .

Идея в основном заключается в том, чтобы написать те хуки, которые будут действовать как мини-скрипты «make install», которые обеспечивают правильную конфигурацию по ветвям, по хостам, по наличию или содержимому других файлов, что угодно. Хуки могут даже переписать ваши конфигурационные файлы или воссоздать их, заполнив шаблоны.

0 голосов
/ 09 июля 2010

Я предполагаю, что обычно master содержит только коммиты, которые уже находятся в staging.Если вы добавите дополнительный коммит к master, который содержит различия в конфигурации между двумя ветвями, то перебазирование этого коммита поверх того, что извлечено из staging, должно поддерживать конфигурацию.Это не так просто, так как «объединение в мастер не должно никоим образом влиять на файлы конфигурации мастера», но, поскольку в этих случаях вы получите конфликт слияния, он может быть достаточно близок.

...