Как мне обращаться с файлами конфигурации сайта при импорте сайта в репозиторий SVN? - PullRequest
1 голос
/ 18 января 2010

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

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

Что люди обычно делают с конфигурационными файлами, есть ли способ сказать SVN пропускать конфигурационные файлы при выполнении коммитов и т. Д.?

Ответы [ 5 ]

2 голосов
/ 18 января 2010

Как правило, лучше всего помещать файлы конфигурации в систему управления версиями, если они хранят важную информацию.

Если вы говорите здесь ASP.NET сайтов, я бы определенно разместил конфигурациюфайл в SVN.Вы можете воспроизвести несколько хитростей в файлах конфигурации ASP.NET, используя inheritInChildApplications и allowOverride (см. Как: заблокировать параметры конфигурации ASP.NET ), что может позволить вам использовать локальную отладочную версию для использованияотличны от окончательной рабочей версии, несмотря на использование одного и того же файла конфигурации: просто подключите веб-сайт в качестве подкаталога в локальной отладочной IIS и заблокируйте несколько разделов, которые вы хотите переопределить.И, конечно, вы можете просто включить два конфигурационных ключа для особо сложных битов и проверить код, который нужно загрузить.

В общем, хорошая практика делать развертывание что угодно из SVN процесс включает в себя как можно меньше ручных шагов.Это повышает вероятность того, что вы будете делать это правильно в условиях нехватки времени, и это облегчает аварийное восстановление при загрузке (скажем, когда ваш центр обработки данных вызывает утечку, и вы хотите установить веб-сайт на какой-то временный ящик, пока не получитеэти резервные копии отсортированы).В идеале для запуска и запуска веб-сайта должно быть достаточно svn извлечения или экспорта с максимально возможной компиляцией.Я включил даже двоичные dll-зависимости непосредственно в svn (такие как компрессоры javascript и все такое), чтобы он работал без необходимости установки множества пользовательских библиотек на сервере и компилировался на компьютере разработчика с помощью только msbuild.

Для PHP принцип тот же.Однако вам понадобятся разные хитрости.Например, вы можете написать файл конфигурации так, чтобы он проверял некоторую глобальную переменную системной среды, а затем переопределял выбранные настройки, если это dev-машина.Например, у меня есть настройка, подобная этой, где я проверяю IP-адрес;все dev-машины находятся в определенном IP-блоке;если машина не находится в этом IP-блоке, она считается рабочей машиной (которая не включает различные опции трассировки и т. д.).Вы также можете проверить имя хоста или просто любую старую переменную среды, которую все разработчики согласны установить на своих машинах разработки.

1 голос
/ 18 января 2010

Я бы хотел, чтобы файл был в системе контроля версий, поскольку он, как правило, имеет ключевое значение для работы сайта.Чтобы он не загружался в живую, вы можете взглянуть на скрипт сборки (например, Web Deployment Project ), который бы переключал ваши версии разработки для разработки с «живой» версией.


Извините, проигнорируйте ссылку, только что увидел ваш комментарий о том, что это PHP-сайт - однако принцип тот же.

1 голос
/ 18 января 2010

Я думаю, что лучше всего хранить файлы конфигурации в SVN. Что касается настроек для промежуточной / производственной среды, мы делаем отдельные конфигурационные файлы для каждой среды, а затем меняем их как часть нашего процесса сборки (используя Ant и MSBuild). То есть мы можем запустить «производственную сборку», которая скопирует производственный файл web.config.

1 голос
/ 18 января 2010

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

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

1 голос
/ 18 января 2010

Если переменные между вашей средой dev / live ограничены только связными строками и настройками приложений, то вы можете разбить ваш файл web.config на отдельные файлы и загрузить разные файлы для каждой среды.Таким образом, вы можете проверить все в SVN и просто обновить ссылку на имя файла в веб-конфигурации в зависимости от того, в какую среду вы развертываете.

http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx

Редактировать: только что вы говорилио PHP.

...