Как вы относитесь к развертыванию файлов конфигурации на разных системах в Subversion?

Question

Subversion - отличный способ обновить наши веб-приложения на наших серверах. С простым svn update все измененные файлы становятся ... ну, изменены.

За исключением вездесущих файлов конфигурации, таких как config.php, которые содержат конфигурацию доступа к базе данных, пути к серверу и т. Д. И, следовательно, отличаются в моей локальной системе разработки и на удаленном сервере.

С помощью команды update файл, измененный на сервере, не будет перезаписан, но если я изменю файл локально и передам его, сервер получит неправильный файл конфигурации.

Но я также не хочу устанавливать свойство svn:ignore, так как файл конфигурации принадлежит проекту.

Существует ли механизм Subversion, который позволит мне легко обрабатывать файлы такого типа? Или это единственный способ решить эту проблему, сделать системный переключатель в файле конфигурации, который определит исполняющую систему и соответственно настроит конфигурацию?

Answer 1

Создайте шаблон для файла (например, config.php-default) и позвольте пользователю скопировать шаблон. Она также может выполнить сравнение, чтобы увидеть, что изменилось между версиями, чтобы включить эти изменения в локально развернутую версию файла.

Answer 2

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

Чтобы справиться с этим, такую ​​конфигурацию следует рассматривать как «подробности развертывания», а не как общую конфигурацию приложения. Даже когда вы делаете это концептуальное различие, вам все равно приходится иметь дело с различными средами развертывания, но, поскольку вы, похоже, имеете дело с PHP, я не могу комментировать специфику для вашего случая.

Как упомянул Ларс, одним из возможных решений J2EE является сохранение таких деталей в JNDI, что делает точно такой же двоичный файл приложения развертываемым в любой среде, оставляя администраторам баз данных / администраторам устанавливать имя пользователя / пароль для каждой машины.

Answer 3

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

Если вы запускаете веб-сервер apache, вы можете легко настроить его так, чтобы каждый разработчик использовал свой собственный (суб) домен на своем локальном компьютере, а не просто использовал localhost. Таким образом, каждый разработчик может использовать свою собственную конфигурацию.

Answer 4

Я считаю, что самый простой способ - включить имя хоста машины. У меня есть файл .ini с общим разделом, который также переопределяет это для систем производства, тестирования и разработки.

[general]
info=misc
db.password=secret
db.host=localhost

[production : general]
info=only on production system
db.password=secret1

[testing : general]
info=only on test system
db.password=secret2

[dev : general]
info=only on dev system
db.password=secret3

Итак, dev: db.password == 'secret3', но dev: db.host == 'localhost' из исходной группы 'general'.

«production», «testing» и «dev» могут быть именами хостов компьютера или псевдонимами для них, установленными из какого-либо другого механизма в скрипте управления конфигурацией.

Answer 5

Некоторые возможные решения:

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

У вас может быть файл свойств по умолчанию на вашем сервере subversion, но в других местах на серверах (за пределами частей проекта, которые проверяются в svn) ищите файл реальных свойств, но тогда вы обычно получаете зависимые от ОС пути и имеете Не забудьте обновить файлы реальных свойств вручную при добавлении новых свойств в файл SVN.

Вы можете установить свойства в файле свойств как часть сборки и передать параметр в команду сборки, чтобы сообщить ей, для какой среды сервера строить. Это может показаться немного обходным, и вы должны помнить, чтобы обновить скрипт сборки новыми свойствами. Но он может хорошо работать - если вы настроите сервер Continuous Integration, он может собрать для всех различных сред и протестировать пакеты для вас. Тогда вы знаете, что у вас есть что-то готовое к развертыванию.

Answer 6

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

Поскольку наша среда разработки локально представляет собой файловую систему Windows, а производственные серверы работают в файловых системах UNIX, мы решили определить операционную систему хоста и загрузить правильный файл.

Мы храним их непосредственно в нашем контроле над источниками, чтобы вести историю любых внесенных изменений. Я думаю, что мы извлекли урок из нашего (внутреннего) указательного пальца в отношении НЕПРАВИЛЬНО ЧАСТО ЗАДАВАЕМЫХ ИЗМЕНЕНИЙ в том, что нам нужно было иметь возможность защитить любые из прошлых изменений файлов.

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