Как вы справляетесь с файлами конфигурации в системе контроля версий?

Question

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

Answer 1

Долгое время я делал именно то, что делал bcwood. Я держу копии web.dev.config, web.test.config, web.prod.config и т. Д. Под контролем исходного кода, а затем моя система сборки / развертывания переименовывает их автоматически при развертывании в различных средах. Вы получаете определенную избыточность между файлами (особенно со всем содержимым asp.net), но в целом это работает очень хорошо. Вы также должны убедиться, что все в команде помнят обновить все файлы, когда они вносят изменения.

Кстати, мне нравится хранить в конце расширение «.config», чтобы не нарушались ассоциации файлов.

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

Answer 2

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

Мы используем MSBuild в нашей автоматической сборке, поэтому мы используем задачу XmlUpdate из Задачи сообщества MSBuild для обновления значений.

Answer 3

Зарегистрированная версия app / web.config для простого пользователя должна быть достаточно универсальной, чтобы работать на всех машинах разработчика, а также постоянно обновляться с любыми новыми изменениями настроек и т. Д. Если вам требуется определенный набор настройки для dev / test / production, проверьте в отдельных файлах с этими настройками, как сказал GateKiller, с каким-то соглашением об именах, хотя я обычно иду с "web.prod.config", чтобы не изменять расширение файла.

Answer 4

Я управляю версией, но никогда не отправляю ее на другие серверы. Если производственный сервер требует изменения, я внесу это изменение непосредственно в файл конфигурации.

Это может быть не красиво, но работает просто отлично.

Answer 5

У нас здесь две проблемы.

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

  Разработчику легко проверить нежелательное изменение основного файла конфигурации, если они используют один и тот же файл в среде разработки.

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

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

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

мне еще предстоит увидеть хорошие решения это работает хорошо во всех случаях, однако Я видел частичных решения (которые могут быть объединены в разные комбинации по мере необходимости), что уменьшает проблема много.

• Сначала уменьшите количество элементов конфигурации, которые есть в вашем основном файле конфигурации.

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

  Аналогично для настройки внедрения зависимостей.

• Разделите файл конфигурации, если это возможно, например, используйте отдельный файл для настройки журналов Log4Net.

• Не повторяйте элементы между множеством файлов конфигурации, например, если у вас есть 4 веб-приложения, которые все установлены на одном компьютере, у вас есть общий файл конфигурации, на который указывает файл web.config в каждом приложении.

  (по умолчанию используется относительный путь, поэтому редко нужно менять файл web.config)

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

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

• Вместо одной строки подключения к базе данных, по одной на разработчиков.

  E.g сначала ищите «database_ianr» (где ianr - мое имя пользователя или имя машины) в файле конфигурации во время выполнения, если он не найден, затем ищите «database»

  Имейте 2-й уровень "например, -oracle or -sqlserver", чтобы разработчики быстрее могли добраться до обеих систем баз данных.

  Конечно, это можно сделать и для любого другого значения конфигурации.

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

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

Вы не можете устранить потребность в заботливом человеке, если у вас нет такой проблемы.

Answer 6

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

Answer 7

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

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

Что я делаю, это создаю каталог configs в корне проекта, и в этом каталоге хранится несколько файлов для всех сред (а иногда и отдельных файлов для среды каждого разработчика), которые отслеживаются в системе контроля версий. , И есть фактический файл, который код использует с именем config в корне проекта. Это единственный файл, который не отслеживается. Так это выглядит

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

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

А на серверах неотслеживаемый файл может быть просто копией (или ссылкой) отслеживаемого файла, соответствующего этой среде. В JS вы можете просто иметь 1 строку, чтобы требовать этот файл.

Поначалу этот процесс может быть немного сложным, но он имеет большие преимущества: 1. Вам никогда не придется беспокоиться об удалении или изменении файла конфигурации на сервере без резервной копии 2. То же самое, если у разработчика есть какая-то настраиваемая конфигурация на его компьютере, и его машина перестает работать по любой причине 3. Перед любым развертыванием вы можете, например, изменить файлы конфигурации для development и staging и посмотреть, есть ли что-то пропущенное или сломанное.

Answer 8

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

Answer 9

Я столкнулся с той же проблемой и нашел решение для нее. Сначала я добавил все файлы в центральный репозиторий (в том числе файлы разработчика).

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

Я решил это с помощью команды git: update-index --assume-unchanged. Я создал bat-файл, который выполняется в предварительной сборке проектов, содержащих файл, изменения которого должны игнорироваться Git. Вот код, который я вставил в файл bat:

IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END

В моей предварительной сборке я бы сделал вызов файла bat, например:

call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

Я нашел в SO файл bat, который копирует правильный файл конфигурации в web.config / app.config. Я также называю этот файл bat в предварительной сборке. Код для этого файла bat:

@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2 
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same.  Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same.  Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.

В моей предварительной сборке я бы сделал вызов файла bat, например:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config