Я несколько раз сталкивался с одной и той же проблемой, и я хотел бы внести свой вклад в то, что другие люди думают об этой проблеме: Предположим, что у нас есть Spring приложение, упакованное как файл .war, и мы хотим запустить его в нескольких средах. (Разработка/испытание/preprod/Prod/и т.д.)
Для доступа к инфраструктуре, необходимой для приложения (базы данных/веб-сервисы и т.д.), мы сохраняем информацию о доступе в файлах конфигурации, а также некоторые бизнес-конфигурации находятся в этих файлах. Скажем, для этой цели мы используем файлы .properties (поскольку во время войны у нас есть приложение Spring, и нам нравится иметь свойства, считанные одним слоем в appcontext) а также предположим, что в разных средах у нас нет того же контейнера appserver/servlet. (например: dev, test: jetty, preprod: tomcat, prod: glassfish)
То, что я обычно делал, это создание нескольких профилей Maven, по одному для каждой среды, необходимой конфигурации в соответствующих файлах для каждого.
Недавно я столкнулся с вопросом от парня, который работал: "Итак, действительно ли нам нужно создать новую сборку с соответствующим профилем на сервере-сборщике, если база данных будет изменена в среде preprod?" Я ответил: "Нет, вы действительно можете перейти на... /webapps/currentApp/WEB -INF/classes/config/application.properties и изменить там значения, а затем перезапустить контейнер
Мы придумали решение, которое решает некоторые аспекты этой проблемы: используя плагин сборки Maven, мы внедряем Jetty внутри войны, что делает его пригодным для использования в качестве "исполняемой" войны, а также дает нам возможность иметь глобальную конфигурацию XML, из которого стартер встроенного Jetty создает/изменяет соответствующие файлы .properties в взорванном военном каталоге и только затем запускает приложение.
Но опять же это не решает проблему, если вы хотите использовать что-либо другое, кроме Jetty.
Как все имеют дело с одной и той же ситуацией?