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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

I «Не уверен, что это идеальное решение, его довольно сложно поддерживать, но это интересно.

Answer 9

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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