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

Question

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Не делайте версию этого файла. Версия шаблона или что-то.

Answer 4

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

Answer 5

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

web.config.rename

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

Answer 6

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

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

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

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

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

Answer 7

Я использовал шаблон раньше, то есть web.dev.config, web.prod.config и т. Д., Но теперь предпочитаю метод «переопределить файл». Файл web.config содержит большинство настроек, но внешний файл содержит значения, относящиеся к среде, такие как соединения БД. Хорошее объяснение в блоге Пола Уилсона .

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

Answer 8

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

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

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

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

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

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

Answer 9

Я всегда держал все версии файлов конфигурации в системе контроля версий в той же папке, что и файл 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 файлом конфигурации, соответствующим этой среде. Если файлы заархивированы, то ненужные файлы должны быть удалены из этой сборки.

Answer 10

@ Грант прав.

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

У нас все хорошо получилось.