Мы создали структуру папок для свойств, которые были специфичны для среды. В этой папке мы создали папки для каждой конкретной среды, предназначенной для развертывания, включая локальную разработку. Выглядело это так:
Project
\
-Properties
\
-Local (your PC)
-Dev (shared dev server)
-Test (pre-production)
-Prod (Production)
В каждой папке мы помещаем параллельные копии свойства/конфигурационные файлы и поставить различные конфигурации только в файле в соответствующей папке. Секрет состоял в том, чтобы управлять классом классов среды развертывания. Мы определили запись класса PROPERTIES на каждом сервере. В Prod он будет установлен в «$ ProjectDir/Properties/Prod», а при тестировании одна и та же переменная будет установлена в «$ ProjectDir/Properties/Test».
Таким образом, мы могли бы связать строки базы данных с базой данных dev/test/prod, предварительно сконфигурированные и не имеющие необходимости проверять/в файле свойств каждый раз, когда мы хотели создать для другой среды.
Это также означало, что мы можем развернуть тот же самый .war/.ear файл для Test и Prod без перестройки. Любые свойства, которые не были объявлены в файле свойств, которые мы обрабатывали аналогичным образом, используя одно и то же имя JNDI в каждой среде, но используя значения, которые были специфичны для этой среды.
и можно использовать его для создания файла войны с немного изменены файлы конфигурации файл? например. для одного файла войны в something.properties property address = one и для второго файла войны в том же файле something.properties address = second? thx – blefesd
@blefesd - короче нет. Однако я советую не принимать такой подход. Лучше всего иметь только одну версию развертывания и иметь либо всю конфигурацию, включенную в нее, либо загруженную из внешних мест. Некоторые причины этого - простота управления версиями, возможность добавления новых окружений и отслеживания. – Pablojim