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

Ответ 1

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

В общем, чем меньше файл переопределения, тем лучше, но он всегда может содержать больше настроек для разработчика с очень нестандартной средой.

Ответ 2

Не используйте этот файл. Версия шаблона или что-то еще.

Ответ 3

Конфигурация - это код, и вы должны его версия. Мы основываем наши файлы конфигурации на именах пользователей; в UNIX/Mac и Windows вы можете получить доступ к имени входа пользователя, и пока они уникальны для проекта, вы в порядке. Вы даже можете переопределить это в среде, но вы должны управлять версиями.

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

Ответ 4

Моя команда хранит отдельные версии конфигурационных файлов для каждой среды (web.config.dev, web.config.test, web.config.prod). Наши сценарии развертывания копируют правильную версию, переименовывая ее в web.config. Таким образом, у нас есть полный контроль версий в конфигурационных файлах для каждой среды, можно легко выполнить diff и т.д.

Ответ 5

В настоящее время у меня есть конфигурационный файл "template" с добавленным расширением, например:

web.config.rename

Тем не менее, я вижу проблему с этим методом, если изменились критические изменения.

Ответ 6

Мы используем только один файл конфигурации (web.config/app.config), но добавим специальный раздел в файл, содержащий настройки для всех сред.

В наших конфигурационных файлах есть разделы LOCAL, DEV, QA, PRODUCTION, каждый из которых содержит ключи конфигурации, относящиеся к этой среде.

Что все это значит, это сборка с именем xxx.Environment, на которую ссылаются во всех наших приложениях (winforms и webforms), которые сообщают приложению, в какой среде он работает.

Узел xxx.Environment читает одну строку информации из machine.config данного компьютера, которая сообщает ему, что она находится на DEV, QA и т.д. Эта запись присутствует на всех наши рабочие станции и серверы.

Надеюсь, что это поможет.

Ответ 7

+1 в шаблоне.

Но поскольку этот вопрос имеет тег Git, распределенная альтернатива на ум, в котором настройки сохраняются на частном тестировании Отрасль:

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

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

Теперь разработчики/тестеры могут настроить конфигурационный файл на свой контента и только фиксировать эти изменения локально на одном приватном (например, B '= B + настройки). Каждый раз, когда магистраль прогресс, они без труда сливают его в тестирование, что приводит к merge совершает такие действия, как D '(= D + объединенная версия настроек B).

Эта схема действительно сияет, когда обновляется файл конфигурации "template": изменения с обеих сторон объединяются и, приводят к конфликтам (или к ошибкам тестирования), если они несовместимы!

Ответ 8

Я использовал шаблон раньше, т.е. web.dev.config, web.prod.config и т.д., но теперь предпочитаю метод "переопределить файл". Файл web.config содержит большинство параметров, но внешний файл содержит значения, специфичные для среды, такие как соединения db. Хорошее объяснение на Paul Wilson blog.

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

Ответ 9

@Grant прав.

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

Это сработало для нас хорошо.

Ответ 10

Я всегда сохранял все версии конфигурационных файлов в исходном элементе управления в той же папке, что и файл web.config.

Например

web.config
web.qa.config
web.staging.config
web.production.config

Я предпочитаю это соглашение об именах (в отличие от web.config.production или production.web.config), потому что

• Он хранит файлы вместе при сортировке по имени файла
• Он сохраняет файлы вместе при сортировке по расширению файла
• Если файл случайно попадает в производство, вы не сможете увидеть содержимое через http, потому что IIS предотвратит доступ к файлам *.config.

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

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

Здесь у нас две проблемы.

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

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

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

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

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

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

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

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

  Аналогично для установки инъекций depency.

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

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

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

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

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

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

  Например, сначала найдите "database_ianr" (где ianr - мое имя пользователя или имя машины) в файле конфигурации во время выполнения, если он не найден, затем найдите "базу данных"

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

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

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

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

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

Ответ 18

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

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

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

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

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

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

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

Ответ 19

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

Итак, если разработчик извлекает файлы из репозитория, там также присутствует конфигурация разработчика. При изменении этого файла, 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 в prebuild. Код для этого файла 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