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

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

8.08.2008 14:44:25
19 ОТВЕТОВ
РЕШЕНИЕ

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

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

68
8.08.2008 14:50:00

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

19
8.08.2008 14:46:15
Я использую этот подход, у меня просто есть main.php.tmpl, и когда я извлекаю новую копию, просто копирую ее в main, php. Я добавляю файл main.php в список игнорирования, чтобы избежать его фиксации случайно.
levhita 15.09.2008 18:10:05

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

web.config.rename

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

6
8.08.2008 14:47:06

@ Грант прав.

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

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

3
8.08.2008 14:49:52

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

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

2
8.08.2008 14:50:48

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

2
8.08.2008 14:51:35

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

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

2
8.08.2008 15:41:29

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

10
8.08.2008 15:44:59

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

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

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

2
17.08.2008 03:10:24

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

0
17.08.2008 04:10:42

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

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

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

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

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

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

6
31.08.2008 11:01:56
Но когда разработчики-тестировщики продвигаются в основную линию, их изменения в файле шаблона также будут внесены. Нет?
Nick Zalutskiy 30.04.2009 01:16:40
Если нет ответа на комментарий Ника, это не сработает из того, что я вижу. Или, возможно, объясните, какую модель потока вы используете, чтобы решить эту проблему.
Alexander Bird 21.06.2011 14:00:19
Я согласен с подходом шаблона с любыми необходимыми изменениями, внесенными во время сборки. Однако по теме ветвления ... Что делать, если было несколько шаблонов (dev, test и т. Д.), И разработчики просто пропускают изменения в своих коммитах. Не надежно, но может работать в сотрудничестве.
NickSuperb 6.10.2011 19:42:48

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

1
5.09.2008 22:43:30

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

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

4
8.09.2008 16:11:26

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

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

24
15.09.2008 18:04:39
+1 абсолютно за то, что подчеркиваю, что конфигурация все еще должна быть версионной
Alexander Bird 21.06.2011 13:55:16
И если по какой-либо причине имя пользователя ненадежно, то у вас может быть один файл с одной строкой, содержащей имя файла конфигурации переопределения. Таким образом, очень мало (примерно 10 символов или около того), которые не контролируются версией. И файл README может объяснить, что вам нужно сделать этот файл.
Alexander Bird 21.06.2011 13:58:29
Я всегда думаю, что конфигурации должны храниться отдельно от кода. Я работал в местах, где требуется так много конфигураций для одного репозитория, что Git просто перегружен конфигурационными файлами. Не говоря о том, что конфиги не должны быть версионными, они принадлежат где-то еще, как менеджер артефактов. Конфиг не код, это настройки кода.
Thomas 16.08.2019 13:57:08
Файлы конфигурации могут содержать конфиденциальную информацию, такую ​​как пароли, которые не должны быть версионными. Или вы хотите предоставить каждому разработчику доступ к вашей производственной среде? Я думаю, что лучше просто установить версию master config и переопределить ее в определенных средах.
Christophe Weis 31.12.2019 07:32:16

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

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

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

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

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

5
16.09.2008 18:47:00
Это работает очень хорошо, если есть только несколько различий между средой (например, строки подключения)
Eric Labashosky 26.04.2009 13:17:59
и при условии, что не сотни разработчиков все разместят там свои собственные настройки (это все равно будет работать, но будет очень громоздко)
Alexander Bird 21.06.2011 13:53:39

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
20.10.2009 09:03:42

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

5
6.05.2011 00:51:51

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

Поэтому, если разработчик выбирает файлы из репозитория, конфигурация разработчика также там. При внесении изменений в этот файл 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
0
7.08.2017 01:15:37

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

Вот как я это делаю. Обычно это для проектов nodejs, но я думаю, что это работает и для других сред и языков.

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

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

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

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

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

1
14.09.2016 06:19:16