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

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

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

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

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

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

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

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

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

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

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

Я использовал шаблон прежде, т.е. web.dev.config, web.prod.config, и т.д., но теперь предпочитаю 'технику' файла переопределения. web.config файл содержит большинство настроек, но внешний файл содержит определенные для среды значения, такие как соединения дб. Хорошее объяснение на блог .

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

+1 на шаблонном подходе.

, Но так как этот вопрос имеет Мерзавца тега, распределенная альтернатива приходит на ум, в котором настройки сохранены на частном ответвлении тестирования:

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

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

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

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

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

web.config.rename

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

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

существует ЛОКАЛЬНЫ, DEV, QA, ПРОИЗВОДСТВО разделы каждый содержащий ключи конфигурации, относящиеся к той среде в нашем файле (файлах) конфигурации.

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

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

Hope это помогает.

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

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

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

Не присваивайте версию тому файлу. Присвойте версию шаблону или чему-то.

@Grant является правильным.

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

Это удалось вполне прилично для нас.

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

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

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

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

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

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

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

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

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

  То же самое для настройки внедрения зависимостей.

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

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

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

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

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

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

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

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

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

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

Однако, в конце концов, вы Или наличие разделов, которые удаляются в процессе создания установщика.

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

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

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

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

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

Однако, в конце концов, вы Или наличие разделов, которые удаляются в процессе создания установщика.

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

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

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

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

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

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

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