Параметры web.config и app.config для конкретного компьютера в git

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

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

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

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

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

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

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

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

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

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

Я должен был упомянуть ранее, мы все еще на VS2008, поэтому Configuration Transforms недоступны.

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

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

Ответ 1

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

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

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

Edit2. Посмотрите также на статью Daniel: fooobar.com/questions/59753/.... Он дает очень яркий пример шаблона и таблицы, и как заставить его работать в вашем решении.

Ответ 2

Вы считали фильтр фильтра содержимого?

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

файл шаблона конфигурации (с добавлением значения параметра конфигурации, например @@[email protected]@)
один из файлов значений конфигурации (каждый разработчик может сохранить версию своего собственного файла конфигурации)

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

Ответ 3

Я бы рассмотрел этот ответ для управления сложными файлами Web.Config между средами развертывания 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 не проверены и не заменены при новом развертывании.

Ответ 4

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

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

Кроме того, есть и некоторые коммерческие решения, которые вы можете захотеть увидеть как Beanstalk

Ответ 5

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

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