Платформа Java: как управлять настройками конфигурации для каждого разработчика

Question

Вдохновлен этим вопросом:

Как управлять настройками конфигурации для каждого разработчика

Как управлять настройками конфигурации приложения, которые должны быть установлены для каждого разработчика безпроверка их в системе управления исходным кодом на платформе Java ?

Например, вот что мы делаем сейчас:

• Конфигурация источника данныххранится в XML-файле конфигурации Spring.

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

  К сожалению, патчи устарели.Люди иногда забывают вернуть свою локальную конфигурацию перед фиксацией.

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

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

Что бы вы сделали / сделали?

Answer 1

Проверьте файл шаблона (например, sample.context.xml) в системе контроля версий. Каждый разработчик копирует этот файл в context.xml и вносит любые изменения, которые ему нравятся. Если файл реальной конфигурации находится в каталоге, управляемом источником, добавьте его в svn: ignore, чтобы предотвратить случайные проверки.

==> Нет случайных фиксаций и постоянных настроек локальной конфигурации.

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

Что касается того, где разместить эту конфигурацию: она упрощает сборку и развертывание, если конфигурация конкретного экземпляра не является частью файла .war. Мы используем записи JNDI, которые легко найти из конфигурационных файлов Spring, используя <j2ee:jndiLookup>.

Answer 2

Мы делаем сборку полностью автономной, включая такие вещи, как локальные базы данных H2 / Hipersonic / JavaDB и почтовые сервера Ruby. Это означает, что локальная сборка не имеет конфигурации, специфичной для разработчика, и все указывает на предварительно упакованные компоненты. Это также означает, что кроме основ (JVM, Ruby, Editors) на настройку окна разработчика нет нуля.

Недостатком является то, что ваш код проверки немного больше.

Answer 3

Поместите файл конфигурации во внешний каталог. Если его нет, прочитайте файл конфигурации по умолчанию. Внешний каталог может быть настраиваемым и может иметь значение по умолчанию, например, c:\workspace\config.

Дополнительно, во время сборки, вы можете скопировать внешние свойства в артефакт сборки.

Answer 4

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

например, у вас есть свойство с именем datasource.url, которое загружается в ваш файл Spring.

Мы расширили ResourceLoader, чтобы сначала проверить системные свойства, чтобы увидеть, было ли свойство с таким именем, и если так, то оно будет загружать его, а не использовать значение из файла свойств.(На самом деле, я думаю, что Spring ResourceBundleMessageSource делает это «из коробки», если вы настраиваете его, но нам нужно было какое-то нестандартное поведение, в которое я не буду вдаваться).

Итак, если мы запустим наше приложение с помощью нескольких дополнительных командстроковые параметры:

-Ddatasource.url=[local-datasource-url]

Затем оно переопределяет значение из файла свойств.

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

Answer 5

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

К счастью, некоторые из фреймворков, таких как Rails, предоставляют их, и я уверен, что и в Java она гибкая.