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

Question

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

В приложении Spring у вас также могут быть bean-компоненты, которые вы хотите загрузить в локальной среде, но не в производственной среде, и наоборот.

Как вы с этим справляетесь?Используете ли вы отдельные файлы, фильтрацию ресурсов ant/maven или другие подходы?

Answer 1

Я просто поместил различные свойства в JNDI.Таким образом, каждый из серверов может быть настроен, и у меня может быть ОДИН военный файл.Если список свойств большой, я размещу файлы свойств (или XML) на другом сервере.Я буду использовать JNDI, чтобы указать URL-адрес используемого файла.

Если вы создаете разные файлы приложения (war/ear) для каждой среды, вы не развертываете ту же самую war/ear, которую тестируете.

В одном из моих приложений мы используем несколько служб REST.Я просто поместил корневой URL-адрес в JNDI.Затем в каждой среде сервер можно настроить для взаимодействия с соответствующей службой REST для этой среды.

Answer 2

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

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

Тогда единственное, что мне нужно четко понимать, это то, какой файл конфигурации развертывается на какой машине.До сих пор у меня не возникало проблем со стратегией создания задач Ant, которые обрабатывают копирование правильного файла конфигурации на место перед созданием моего файла WAR;таким образом, в приведенном выше примере у меня есть три задачи Ant: одна генерирует производственный WAR, другая генерирует dev WAR и третья генерирует тестовый WAR.Все три задачи обрабатывают копирование нужного файла конфигурации в нужное место, а затем вызывают один и тот же следующий шаг — компиляцию приложения и создание WAR.

Надеюсь, это имеет какой-то смысл...

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

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

Answer 12

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

Кроме того, в этой настройке вы можете иметь общий файл свойств и переопределять файлы свойств для конкретных сред.И Ant, и Maven поддерживают эти возможности.

Answer 13

Не забудьте изучить PropertyPlaceholderConfigurer — это особенно полезно в средах, где JNDI недоступен.