Контроль версий и личный файл конфигурации

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

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

Тем не менее, это все еще выглядит как специальное решение.

Можете ли вы предложить лучшее решение?

Что делают профессионалы?

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

Я могу думать о двух возможных решениях здесь:

• постарайтесь строго отделить эту информацию. Например, не используйте имена модулей в вашей пользовательской конфигурации. Используйте идентификаторы (например, GUID) для ссылки на модули, и пусть эти идентификаторы никогда не изменятся после того, как они были назначены модулю. Конечно, это, вероятно, имеет тот недостаток, что ваши пользовательские конфигурационные файлы теряют часть своей простоты, которую они могли бы иметь сейчас. Возможно, вам потребуется создать инструмент с графическим интерфейсом для редактирования файлов конфигурации, а не с помощью простого текстового редактора.

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

РЕДАКТИРОВАТЬ: после прочтения вашей публикации, я думаю, что ваше предполагаемое решение является разумным, если новые модули только добавлены, но не переименованы. То, что я написал выше, позволит впоследствии изменить имена модулей или структуру конфигурации существующих модулей. Но если вам это не нужно, я бы остановился на самом простом решении.

Это разумное решение.

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

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

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

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

У нас есть несколько интересное решение, мы в первую очередь разработчики PHP, поэтому мы используем Phing, который позволяет создавать автоматизированные задачи, написанные на PHP, поэтому вместо обычного обновления svn мы делаем «обновление phing», которое вызывает svn update, а затем заменяет наши конфиги соответствующими переменными, например, конфиг:

$db_user = "${test.db_user}";

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

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

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

Поместите номер версии в личный файл конфигурации (номер версии формата файла конфигурации).

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

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

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

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

Здесь мы создаем блоки настроек. Это можно сделать в Zend следующим образом:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

Это означает, что тестирование наследует производство и расширяет его ключом 3. Все, что нужно сделать каждому разработчику, - это настроить свою среду (в этом случае тестирование или производство)

Это полезное решение, основанное на посте: Хранение паролей в системе контроля версий.

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

1. Создайте фиктивный файл comfig и .gitignore его.
2. Создайте make-файл, который может зашифровать и расшифровать файл конфигурации
3. Сохраните make-файл и зашифрованный файл конфигурации в хранилище
4. Makefile запрашивает пароль, и как связаться с автором для пароля.
5. При сборке проекта, если make-файл еще не запущен, сообщите пользователю console.error («Файл конфигурации [conf / settings.json] отсутствует! Вы забыли запустить make decrypt_conf?»);
6. Описана проверка, чтобы убедиться, что файл конфигурации обновлен.

Мы создали инструмент под названием Config, который обрабатывает проблемы конфигурации, подобные этой. Что вы будете делать, это создать (или импортировать) 1 главный файл конфигурации. Затем создайте среду под названием Local. В локальной среде создайте несколько экземпляров, по 1 экземпляру на пользователя. Если вам нужно внести изменения, которые являются общими для всей платы, например, добавить новую запись конфигурации или изменить имя модуля, просто внесите изменение, и оно будет применено ко всей плате. Если вы хотите внести изменения в экземпляр / пользователя, сделайте это значение конфигурации переменной, а затем измените переменную. Это изменение будет применено только к вашему экземпляру / пользователю. Все они находятся под контролем версий. Вы развертываете файлы конфигурации с помощью push или pull. Опция pull похожа на git pull, но для этого конкретного экземпляра / пользователя.

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