Для типичного веб-приложения J2EE параметры подключения к источнику данных хранятся как часть конфигурации сервера приложений.
Есть ли способ контролировать версии этих деталей конфигурации? Я хочу больше контролировать источник данных и другие изменения конфигурации сервера приложений.
Какова стандартная практика для этого?
Отслеживание изменений конфигурации вашего сервера приложений с помощью контроля версий — хорошая вещь, о которой стоит попросить. Однако это означает, что все изменения выполняются с помощью сценариев, а не административного веб-интерфейса. Я рекомендую
http://www.ibm.com/developerworks/java/library/j-ap01139/index.html?ca=drs-
как хорошая справочная информационная статья по этой теме.
Обновление: Совсем недавно здесь была опубликована часть 2: http://www.ibm.com/developerworks/java/library/j-ap02109/index.html?ca=drs-
При работе с WebSphere мы обнаружили, что наилучшим подходом является сценарий развертывания и помещение сценария под контроль версий, а также файлы ответов для каждой из целевых сред.
Websphere может быть сложным, так как структура каталогов представляет собой беспорядок файлов - часто появляются дубликаты, и трудно понять, какой волшебный файл вам нужно создать резервную копию / восстановить. Вопрос о том, как это сделать, не должен отвлекать от необходимости делать это. - это однозначно да.
Наши (Spring) приложения имеют жестко закодированное имя jndi в файле конфигурации spring. Таким образом, одно и то же ухо можно развернуть в средах разработки, контроля качества и производства, и вам не придется беспокоиться о деталях подключения к базе данных.
Администраторы сервера приложений следят за тем, чтобы источник данных был зарегистрирован для этого имени jndi с подробными сведениями о подключении, соответствующими каждой среде.
Но как это позволяет мне управлять изменениями в конфигурациях источников данных на серверах приложений. Вот сценарий:
Администраторы баз данных изменяют пароль подключения к серверу базы данных.
Администратор Webspehere/Weblogic вносит соответствующие изменения в конфигурацию сервера через консоль администратора.
Вышеупомянутое изменение не контролируется версиями, поэтому нет четкого способа узнать историю таких изменений.
Проблема заключается не в том, как должно быть настроено приложение, а в том, как изменения конфигурации должны контролироваться версиями. Возможно, это звучит как излишество для простых проектов, но для некоторых проектов контроль подобных изменений действительно становится проблемой.
Каждый раз, когда вы спрашиваете себя «должен ли X быть в системе контроля версий», ответ по умолчанию — «да».
Для более точного ответа спросите себя: файл создан человеком (например, исходный файл или документ) или он создан другой программой (например, объектный файл или дистрибутив PDF)?
Файлы, созданные и/или поддерживаемые человеком, должны находиться под контролем конфигурации.
Мы всегда используем контроль версий для настроек нашего сервера приложений. Это инструмент под названием WLST (инструмент создания сценариев для веб-логики), который является частью дистрибутива сервера веб-логики. Конфигурация домена хранится в скрипте Jython, который легко запускается через командную строку и поэтому превосходно интегрируется с нашим инструментом сборки maven.
Создание предварительно настроенного работающего домена weblogic требует только выполнения цели maven. Все эти раздражающие проблемы с неправильно настроенными соединениями jdbc или неправильными параметрами назначения jms исчезли. У вас всегда будет конфигурация сервера приложений, которая соответствует исходному коду в данный момент времени. Вам никогда не придется помнить, какие настройки сервера приложений должны применяться для этой конкретной версии проекта, над которым вы работаете.
Я действительно рекомендую это.
Я также хотел бы знать, есть ли аналогичные решения для других серверов приложений. Насколько я знаю, есть способ получить стеклянную рыбку через муравья. Как этого можно добиться для JBoss?
