Весенний профиль условный опорный файл несколько окружений

Question

У меня вопрос, с весенними профилями. Я понимаю причину не использования профилей maven, потому что для каждой среды потребуется другой артефакт. Это происходит с тех пор. Я изменил свой код для использования Spring Profile, но проблема с Spring Profiles заключается в том, что он требует наличия файла database.property для каждой среды на сервере. У меня есть эта настройка, та же самая настройка, которую все видели сто раз.

src 
- main 
- resources 
    -conf 
    myapp.properties 
    -env 
     dev.db.properties 
     test.db.properties 
     prod.db.properties 

Проблемой я думаю, что с этой установкой является то, что каждый сервер будет иметь все файлы в окр реже (т.е. DEV будет иметь prod.db.properties и test.db.properties файлы на своем сервере). Есть ли способ копировать файлы, которые необходимы во время сборки maven без использования профилей? Я не смог найти способ. Если это так, то это будет повод для использования профилей maven. Возможно, я что-то пропустил. Любые мысли были бы весьма признательны.

Answer 1

Это похоже на проблему с курицей и яйцом. Если вы хотите, чтобы ваш артефакт работал во всех этих трех средах, вам необходимо отправить 3 конфигурации. Не делать этого приведет к той же проблеме, о которой вы говорили первоначально. Как правило, плохой практикой является создание артефакта с определенными координатами по-разному в соответствии с профилем.

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

Answer 2

Прежде всего вы должны указать, что ваше приложение действительно: если вы используете «приложение в разных средах» или если вы используете «разные приложения в своих собственных приватных средах». Это две несколько разные концепции:

• Если вы используете приложение в разных средах, лучше поместить все файлы свойств в свою банку. Примите это во внимание, представьте, что вы покупаете новый внедорожник; вы сначала управляете его на тестовой трассе, а затем по обыкновенным дорогам, прежде чем отправляться в путь, чтобы наконец насладиться возможностями внедорожника. Вы всегда используете один и тот же автомобиль в разных условиях со всеми его возможностями и характеристиками движения. В каждой среде автомобиль адаптирует свое поведение и характеристики движения. Если вы используете одно приложение для его работы в разных средах, используйте первый подход для создания всех характеристик среды в одной банке.
• С другой стороны, вы также можете использовать несколько разных автомобилей в разных условиях. Поэтому, если вам нужны разные автомобили со своими особыми характеристиками вождения для разных сред, возможно, 4WD или специальные наводнения, потому что вы едете ночью, вы должны взять второй подход. Вернуться к приложению: Если вам нужны разные приложения с разными характеристиками в разных производственных средах, лучше создавать каждое приложение только с теми свойствами, которые ему действительно нужны.

Наконец, вы можете также объединить два подхода:

• мой-весело-приложений foo.jar для обув клиента со свойствами для тестирования, интеграции и производственной среды.
• my-fun-application-2047.jar для клиента 2047 с свойствами для тестирования, предварительной интеграции, интеграции, предварительной обработки и производственной среды.

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