Как Вы поддерживаете веб-приложения Java в различных средах подготовки?

Не забывайте исследовать PropertyPlaceholderConfigurer - это особенно полезно в средах, где JNDI не доступен

У Caleb P и JeeBee, вероятно, есть Ваше быстрое решение. Плюс Вы не должны установить различные сервисы или указать на файлы на различных машинах. Можно указать среду или при помощи $ {user.name} переменная или путем определения профиля в-D аргументе в пользу Муравья или Знатока.

Дополнительно в этой установке, у Вас могут быть универсальный файл свойств и переопределяющие файлы свойств для определенных сред. И Муравей и Знаток поддерживают эти возможности.

Одно решение, которое я видел используемый, состоит в том, чтобы настроить среду подготовки так, чтобы это было идентично продуктивной среде. Это означает, что каждая среда имеет VLAN с тем же диапазоном IP и роли машины на тех же IP-адресах (например, IP кластера дб всегда 192.168.1.101 в каждой среде). Брандмауэры отобразили внешние адреса направления на веб-серверы, таким образом, путем свопинга файлов хоста на ПК тот же URL мог использоваться - http://www.myapp.com/webapp/file.jsp перейдет к подготовке или в производству, в зависимости от которого файла hosts Вы загрузили.

Я не уверен, что это - идеальное решение, это довольно трудно для поддержания, но это - интересное для замечания.

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

У меня есть различные папки конфигурации, содержащие конфигурации для целевого развертывания, и я использую МУРАВЬЯ для выбора того для использования во время этапа копии файла.

Я использую копию Муравья с файлом фильтра. В каталоге с файлом конфигурации с переменными у меня есть каталог с файлом для каждой среды. Сценарий сборки знает ENV, и использует корректный переменный файл.

Я использую Знатока для отфильтровывания ресурсов под src/main/resources в моем проекте. Я использую это в сочетании с файлами свойств для получения по запросу в специализированных атрибутах в моих основанных на Spring проектах.

Для сборок по умолчанию у меня есть файл свойств в моем корневом каталоге, который Знаток затем использует в качестве переопределений (таким образом, вещи как моя локальная установка Tomcat найдены правильно). Тестовый сервер и рабочий сервер являются моими другими профилями. Простое -Pproduction все, что затем требуется для создавания приложения для моего рабочего сервера.

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

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

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

Среда определенные вещи может также быть обработана через службу каталогов (JNDI), в зависимости от Вашего сервера приложений. Мы используем кота, и наш DataSource определяется в реализации Tomcat JNDI только для чтения. Spring делает поиск очень легким.

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

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

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

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

Например, у меня есть веб-приложение, которое соединяется с интерфейсом Java RMI другого приложения. Мое приложение получает адрес интерфейса RMI этого другого приложения через боб, это настроено в Spring файл конфигурации XML. И мое приложение и другое приложение имеют dev, тест и производственные экземпляры, таким образом, у меня есть три конфигурационных файла для моего приложения - то, которое соответствует конфигурации, подходящей для производственного экземпляра, один для тестового экземпляра, и один для dev экземпляра.

Затем единственная вещь, что я должен сохранить прямым, - какой конфигурационный файл развертывается на который машина. До сих пор у меня не было проблем со стратегией создания задач Ant, которые обрабатывают копирование корректного конфигурационного файла в место прежде, чем генерировать мой ВОЕННЫЙ файл; таким образом, в вышеупомянутом примере, у меня есть три задачи Ant, та, которая генерирует производственную ВОЙНУ, та, которая генерирует dev ВОЙНУ и ту, которая генерирует тестовую ВОЙНУ. Все три дескриптора задач, копирующие правильный файл конфигурации в правильное место, и затем, называют тот же следующий шаг, который компилирует приложение и создает ВОЙНУ.

Надежда это имеет некоторый смысл...

Используйте разные файлы свойств и фильтры замены ant, которые выполнят замену в зависимости от среды, для которой выполняется сборка. См. http://www.devrecipes.com/2009/08/14/environment-specific-configuration-for-java-applications/