У вас может быть набор свойств, которые используются на машине разработчика, которые варьируются от разработчика к разработчику, другого набора для промежуточной среды и еще одного для рабочей среды.
В приложении Spring у вас также может быть beans, который вы хотите загрузить в локальной среде, но не в производственной среде, и наоборот.
Как вы справляетесь с этим? Используете ли вы отдельные файлы, ant/maven фильтрацию ресурсов или другие подходы?
Я просто добавил различные свойства в JNDI. Таким образом, каждый из серверов может быть настроен, и у меня может быть один военный файл. Если список свойств велико, то я буду размещать файлы свойств (или XML) на другом сервере. Я буду использовать JNDI, чтобы указать URL-адрес используемого файла.
Если вы создаете разные файлы приложений (войну/ухо) для каждой среды, то вы не развертываете ту же войну/ухо, которую вы тестируете.
В одном из моих приложений мы используем несколько служб REST. Я просто поместил корневой URL в JNDI. Затем в каждой среде сервер может быть настроен для связи с надлежащей службой REST для этой среды.
Я просто использую разные файлы конфигурации XML Spring для каждой машины и удостоверяю, что все биты данных конфигурации, которые различаются между машинами, ссылаются на beans, которые загружаются из этих конфигурационных файлов Spring.
Например, у меня есть webapp, который подключается к интерфейсу Java RMI другого приложения. Мое приложение получает адрес этого другого интерфейса RMI приложения через bean, настроенный в файле конфигурации Spring XML. Как у моего приложения, так и у другого приложения есть демонстрационные, тестовые и производственные экземпляры, поэтому у меня есть три файла конфигурации для моего приложения - тот, который соответствует конфигурации, подходящей для экземпляра производства, по одному для тестового экземпляра, а другой для разработчика экземпляр.
Тогда единственное, что мне нужно, чтобы сохранить прямо, - какой файл конфигурации развертывается на какой машине. До сих пор у меня не было никаких проблем со стратегией создания Ant задач, которые обрабатывают копирование правильного файла конфигурации на место перед созданием моего WAR файла; таким образом, в приведенном выше примере у меня есть три задачи Ant, которые генерируют WAR WAR, тот, который генерирует dev WAR, и тот, который генерирует тестовую WAR. Все три задачи обрабатывают правильный файл конфигурации в нужном месте, а затем вызывают тот же следующий шаг, который компилирует приложение и создает WAR.
Надеюсь, это имеет смысл...
Мы используем файлы свойств, специфичные для сред, и при сборке флагов/войн выбираем правильный набор ant.
Среда, специфичная для окружающей среды, также может обрабатываться через службу каталогов (JNDI), в зависимости от вашего сервера приложений. Мы используем tomcat, и наш DataSource определен в Tomcat только для чтения JNDI-реализации. Spring делает поиск очень простым.
Мы также используем стратегию ant для создания разных сайтов (различного контента, ролей безопасности и т.д.) из того же исходного проекта.
Есть одна вещь, которая вызывает у нас небольшую проблему с этой стратегией сборки, и часто файлы и каталоги не существуют до тех пор, пока не будет выполнена сборка, поэтому это может затруднить запись настоящих интеграционных тестов (с использованием такой же Spring, как при развертывании), которые запускаются из среды IDE. Вы также пропустите некоторые возможности IDE для проверки наличия файлов и т.д.
Я использую Maven для фильтрации ресурсов в src/main/resources в моем проекте. Я использую это в сочетании с файлами свойств, чтобы вытащить настроенные атрибуты в моих проектах, основанных на Spring.
Для стандартных построений у меня есть файл свойств в моем домашнем каталоге, который Maven использует в качестве переопределений (так что такие вещи, как моя локальная установка Tomcat, найдены правильно). Тестовый сервер и производственный сервер - это мои другие профили. Простой -Pproduction - это все, что требуется для создания приложения для моего производственного сервера.
Используйте разные файлы свойств и используйте ant заменить фильтры, которые будут выполнять замену на основе среды, для которой выполняется сборка. См. http://www.devrecipes.com/2009/08/14/environment-specific-configuration-for-java-applications/
Отдельные файлы конфигурации, хранящиеся в репозитории управления версиями и обновленные вручную. Обычно конфигурация не изменяется радикально между одной версией и следующей, поэтому синхронизация (даже вручную) на самом деле не является серьезной проблемой.
Для высокомасштабируемых систем в производственных средах я серьезно рекомендую схему, в которой файлы конфигурации хранятся в шаблонах, и как часть сборки script эти шаблоны используются для рендеринга "окончательных", (все среды должны использовать один и тот же процесс).
Недавно я также использовал Maven для альтернативных конфигураций для живых или промежуточных сред. Конфигурация производства с использованием профилей Maven. Надеюсь, что это поможет.
Я использую Ant копию с файлом фильтра. В каталоге с конфигурационным файлом с переменными у меня есть каталог с файлом для каждой среды. Строка script знает env и использует правильный файл переменной.
У меня есть разные папки конфигурации, содержащие конфигурации для целевого развертывания, и я использую ANT, чтобы выбрать тот, который будет использоваться на этапе копирования файла.
Мы используем разные цели ant для разных сред. То, как мы это делаем, может быть немного неэлегантным, но оно работает. Мы просто укажем определенным ant целям, чтобы отфильтровать различные файлы ресурсов (таким образом вы можете исключить загрузку определенных beans), загрузить различные свойства базы данных и загрузить разные данные семени в базу данных. У нас действительно нет эксперта ant ', но мы можем запускать наши сборки с разными конфигурациями из одной команды.
Одним из решений, которое я видел, является настройка промежуточной среды так, чтобы она была идентичной рабочей среде. Это означает, что каждая среда имеет VLAN с одним и тем же диапазоном IP и ролями компьютеров на тех же IP-адресах (например, IP-адрес кластера db всегда 192.168.1.101 в каждой среде). Брандмауэры отображали внешние обращенные адреса на веб-серверы, поэтому, заменяя файлы хоста на вашем ПК, можно использовать один и тот же URL-адрес - http://www.myapp.com/webapp/file.jsp перейдите на этап постановки или производства, в зависимости от того, какой файл хостов вы поменяли.
Я не уверен, что это идеальное решение, довольно неудобно поддерживать, но это интересно отметить.
У Caleb P и JeeBee, возможно, есть самое быстрое решение. Кроме того, вам не нужно настраивать разные службы или указывать файлы на разных машинах. Вы можете указать свою среду либо с помощью переменной ${user.name}, либо путем указания профиля в аргументе -D для Ant или Maven.
Кроме того, в этой настройке вы можете иметь общий файл свойств и переопределять файлы свойств для определенных сред. Оба Ant и Maven поддерживают эти возможности.
Не забудьте изучить PropertyPlaceholderConfigurer - это особенно полезно в средах, где JNDI недоступен