Полуредактируемые файлы (например, файлы конфигурации) и контроль версий - лучшие практики?

Question

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

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

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

Если вы, ребята, уже сталкивались с этой проблемой, мне было бы интересно узнать о найденных вами решениях. Пока они не ломают сборку, то есть;)

Answer 1

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

config.Default.xml
config.User.xml

Только config.Default.xml контролируется исходным кодом. config.User.xml содержит только те конфигурации, которые отличаются для вас. Итак, скажем, вы тестируете на локальном сервере SQL, вы помещаете туда только строку подключения, и она переопределит строку подключения config.Default.

Взгляните на конфигурацию приложения .Net Framwork, она выполняет большую часть (если не всю) работу за вас.

Answer 2

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

• settings.xml
• settings.xml-релиз

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

Answer 3

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

Мы используем следующий подход. Обратите внимание, что мы работаем в .NET с VS и используем задачи MSBuild (встроенные, сообщества и пользовательские).

• App.config игнорируется контролем версий, но включается в проект.
• App.default.config находится под контролем версий и также включен в проект. Вместо того, чтобы жестко кодировать вещи, которые могут измениться, например, Строки соединения с БД, вместо них мы используем токены.

Задача BeforeBuild проекта ищет наличие App.config и, если не найдены копии App.default.config до App.config . Кроме того, сервер сборки всегда удаляет App.config , если он существует в сборке CI (обеспечивает чистую настройку). Затем мы также используем задачу MSBuild Community FileUpdate, чтобы заменить токены соответствующими значениями, основанными на том, что строит проект.

Например, свежая проверка разработчика может настроить строки подключения БД для локальной базы данных, ночная сборка может настроить для ночной БД и т. Д.

Answer 4

У нас есть

• *. (Config | xml)
• *. (Config | xml) .cert
• *. (Config | xml) .production

Хадсон удаляет исходный файл и развертывает правильный файл для правильной среды (в настоящее время только сертификат).

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

Answer 5

Мы храним файлы такого рода в нашей системе управления версиями и имеем разные папки для среды, для которой мы создаем.

Итак, имеем:

Dev
Test
Live

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

Answer 6

Принятый ответ - это хорошо. Тем не менее, можно сделать то, что вы хотели (4 года назад), и поддерживать только один файл конфигурации, который проверяет и никогда не регистрирует - если ваша система контроля версий имеет концепцию списков изменений. Я сделал это в Perforce:

Проверьте файл конфигурации и сохраните его в своем собственном списке изменений. Когда вы делаете коммит, фиксируйте только другие списки изменений; это легко запомнить, если вы называете свой список изменений конфигурационного файла чем-то вроде «НЕ СОВЕРШЕНО».

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

Answer 7

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

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

Этот подход используется, например, в том, как распространяется Wordpress (необходимо скопировать файл шаблона wp-config.php) или в проектах разработки, использующих autoconf (где проверен файл configure.ac). но каждый файл конфигурации должен быть сгенерирован каждым разработчиком; специальный файл конфигурации создается для распространения в tar-архивах во время выпуска).

Answer 8

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

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