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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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