Параметры настройки web.config и app.config в git

Question

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

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

Исторически мы использовали Subversion, и в частности TortoiseSVN, и это обеспечило простой способ управления локальными изменениями: мы просто добавили эти файлы в автоматический список изменений TortoiseSVN ignore-on-commit. Это предотвращает случайную проверку этих файлов, так как тогда вам нужно специально их выбирать, чтобы включить их в проверку (и вы можете убедиться, что вы проверяете значительные изменения, а не локальный-config-шум). Основным недостатком такого подхода является то, что файлы конфигурации всегда выглядят «измененными», поэтому невозможно сразу узнать, есть ли у вас локальные изменения.

Мы хотим переключиться на Git, и я пытаюсь найти лучший подход.

Во-первых, то, что уже есть в других StackOverflow ответов:

Вариант 1: Проверьте в xxx.sample файлов и .gitignore фактические конфигурационные файлы: Это рекомендуется, например, в this answer. Основная проблема, которую я вижу в этом, заключается в том, что изменения в конфигурационном файле легко забываются в двух разных точках: коммиттер может легко пропустить изменения, которые им необходимо добавить в файл .sample, а потребители (например, сервер непрерывной интеграции) могут легко пропустите изменения, которые им необходимо включить из файла .sample в их локальный файл конфигурации. Таким образом, в принципе, это не похоже на очень хорошее решение.

Вариант 2: Есть проверенный в xxx.defaults файле и .gitignored xxx.local конфигурационный файл, который переопределяет любые настройки определяет: Это возносил, фр например, here. Проблема в том, что мы работаем со стандартными поставщиками конфигурации .Net. Я действительно не хочу, чтобы мы реализовали целую новую структуру настроек загрузки, когда Mirosoft уже выполнила всю работу. Кто-нибудь знает способ получить файлы app.config и web.config для ссылки на дополнительные файлы локального переопределения?

Вариант 3: Есть разработчики держать местные отделения, а затем они всегда проверяют в вишневой кирке или перебазировать ветви в мастер, всегда байпас/избежать нежелательных коммитов в их местном отделении: Это предлагается в качестве возможного рабочий процесс here, и хотя я ценю его чистоту с точки зрения отслеживания изменений (все проверено), он вводит значительную сумму , требуемую накладные расходы на каждый сеанс; это большая боль!

Вариант 4: Есть файлы конфигурации проверяются, но они отмечены --assume-unchanged: Это предлагается в качестве возможного варианта here; насколько я могу судить, он очень похож по духу на список изменений в TortoiseSVN ignore-on-commit, за исключением того, что у вас нет видимости для этих «скрытых» измененных файлов в процессе фиксации; Например, TortoiseGit показывает файл с «измененным» наложением значков, но в диалоговом окне фиксации файл вообще не отображается. Это кажется немного пугающим, снова очень легко забыть проверить изменения.

Учитывая эти параметры, которые все я нашел, я действительно надеюсь на опцию «включить» локальный файл конфигурации в/над зарегистрированным файлом app.config/web.config и перейти с вариант 2; кто-нибудь знает способ сделать это или другие варианты, которые мне не хватает? (Я слабо соблазнился рассмотрением пользовательского шага предварительной сборки Xml ...)

Я должен был упомянуть ранее, что мы все еще на VS2008, поэтому Конфигурационные преобразования недоступны.

---

UPDATE: (удален, был просто неправильно)

UPDATE 2: Я удалил мое предыдущее обновление и ответ, это было глупо/не работает. Я не понимал, что после слияния «наше» следующее слияние в другом направлении возвращает «оригинальные» версии этих файлов (перезаписывает изменения локальных ветвей); Если вы заинтересованы, просмотрите историю изменений. Этот вопрос так же открыт, как и прежде.

Answer 1

Я бы посмотрел this answer for Managing complex Web.Config files between deployment environments на Dan для потенциального решения. Я использую mercurial и использую этот же процесс для того, чтобы иметь общий файл web.config и использовать веб-преобразования для изменения местоположения configSource, чтобы указать на мои специфические вещи для развертывания.

Преимущество использования этого маршрута заключается в том, что он полностью встроен в структуру, не требует дополнительного кода и работает с веб-развертыванием.

Проверен в web.config:

<?xml version="1.0"?> 
<configuration> 
    <!-- snip --> 
    <connectionStrings configSource="config/connectionStrings.config" /> 
</configuration> 

Проверен в web.debug.config:

<?xml version="1.0"?> 
<configuration> 
    <connectionStrings 
     configSource="config/dev.connectionStrings.config" 
     xdt:Transform="Replace(configSource)" /> 
</configuration> 

У меня есть config/connectionStrings.config зарегистрировалась с дефолтами, но сервера развития config/dev.connectionStrings.config не проверяются и его не заменяют на новое развертывание.

Answer 2

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

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

EDIT: Следует отметить, что вы можете игнорировать все ваши файлы Web.config и App.config (в терминах .git). Но вам нужно добавить свои шаблоны и электронные таблицы в репо. Кроме того, я уверен, что есть обновление на пути, который вполне может включать замену xml для электронных таблиц, у которой есть собственный редактор, что делает его в высшей степени более подходящим для DVCS.

Редактировать2: Также посмотрите сообщение Даниэля здесь: https://stackoverflow.com/a/8082937/186184. Он дает очень ясный пример шаблона и таблицы, и как заставить его работать в вашем решении.

Answer 3

Мы столкнулись с подобной дилеммой в нашей компании. В результате мы создали отдельные ветви конфигурации, которые дополняют основную ветвь. Как, например, - develop-config, master-config и т. Д. Затем у нас есть небольшой скрипт, который будет переустанавливать эти ветви с правильной ветвью источника на основе среды развертывания. Так, например, на машине разработки мы будем перестраивать разработку-config с помощью разработки. Если вы работаете на локальном компьютере, вы получите конфигурацию по умолчанию (согласованную всеми разработчиками), которая будет проверена в основной ветке (например, имя локальной базы данных, пароль и т. Д.). Конечно, недостатком является то, что вам всегда нужно поддерживать эти * -конфигурные ветви в актуальном состоянии или получать их до скорости во время развертывания.

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

Помимо этого, есть также некоторые коммерческие решения, что там вы можете взглянуть на как Beanstalk

Answer 4

ли вы рассмотреть content filter driver?

Это означало бы, на каждом git checkout, сценарий размазать бы генерировать фактический конфигурационный файл на основе:

• шаблона конфигурации файла (со значением конфигурации заполнителем как @@A_PARAM_VALUE@@)
• один из файлов значений конфигурации (каждый разработчик может сохранить версии своих собственных значений файла конфигурации)

Это исключает любые проблемы с объединением и настройки gitignore: каждый «файл значений конфигурации» отличается и остается отдельным.
Это также совместимо с другими решениями для создания конфигурации, такими как ConfigGen, указанными в pms1969's answer.

Answer 5

Немного изменилось с 2012 года и в настоящее время, и теперь я предлагаю использовать средство сборки/развертывания (VS Team Services, TeamCity, Octopus Deploy) для управления конфигурациями, специфичными для конкретной среды.

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