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


36

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

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

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

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

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



4
Потрясение ... С какой стати вы позволяете разработчикам переименовывать модули и нарушать настройку клиента в любой момент, кроме серьезного обновления ?
Марк Бут

@jk да, есть даже лучшее совпадение: stackoverflow.com/questions/1974886/…
Erel Segal-Halevi

Я озадачен Как это не проблема при установке обновлений.
Джошуа

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

Ответы:


22

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

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

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

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

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


11

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

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

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

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

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


3

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

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

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


2

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

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


+1 за упоминание о том, что это не просто проблема для разработчиков, а общая проблема развертывания.
Слеське

2

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

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

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


1

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

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


Это кажется довольно подверженным ошибкам; Я видел, как это было сделано, но разработчики случайно проверяли личные настройки, которые затем перезаписывали настройки, используемые другими разработчиками :-(. Кроме того, это означает, что все дерево всегда будет отображаться как «измененное» в инструментах VCS, что очень неудобно.
Слеське

@sleske Это требует определенной дисциплины. Но, честно говоря, я бы ожидал, что у большинства разработчиков эта возможность будет отлично работать.
Томас Оуэнс

1

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

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

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


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

В зависимости от того, сколько настроек и как они используются, вы можете использовать ресурсы в INI-файле для Zend. Не уверен, что это также относится к вашей проблеме.
Agilix

Мне нужно более общее решение, которое может обрабатывать все типы пользовательских предпочтений, а не только ресурсы.
Эрель Сегал-Халеви

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

0

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

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

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

1
-1, поскольку это не отвечает на первоначальный вопрос вообще. Кроме того, ответы, представляющие собой не что иное, как ссылку, и без объяснения, бесполезны для формата Stack Exchange Q / A, поскольку внешние ссылки могут исчезнуть в какой-то момент, не оставляя ссылки на предлагаемый ответ.
Дерек

1
Это интересный пост, хотя.
Эрель Сегал-Халеви

0

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

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


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

Я не думаю, что Config является излишним, если вы подумаете о том, насколько легко его настроить, по сравнению с затрачиваемым временем, пытаясь найти решение, попросить сообщество, внедрить и поддерживать его. Config работает на любой платформе, в формате, на языке, в библиотеке, так что вы изучаете его только один раз. Для конфиденциальных данных есть опция шифрования на стороне клиента, локальное хранилище, если хотите. Пользователи, которые идут ва-банк, могут установить на месте или использовать VPC.
Биенвенидо Дэвид
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.