Gradle создает несколько файлов .war с различными файлами свойств

Question

Мы разрабатываем новое веб-приложение с нуля с использованием Spring Boot и соответствующих зависимостей и создаем с помощью Gradle.

Наш проект имеет почти 5 этапов тестирования, причем каждый этап выполняется на другом сервере и, следовательно, заканчивается несколько иной конфигурацией на каждом сервере.

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

Теперь очевидным недостатком вышеуказанной настройки является то, что такая настройка не может быть легко передана другим разработчикам через какой-либо контроллер версии. И далее я не могу использовать полномочия «Process Resources» в Gradle, чтобы внедрить некоторые динамические свойства во время процесса сборки.

Теперь, если я вытащил файл .properties в настройку проекта, тогда я могу легко управлять версиями, совместное использование становится проще, а также я могу вводить динамические свойства через Gradle. Недостатком является то, что мне, возможно, придется подготовить несколько файлов .war после обновления файла .properties.

Есть два вопроса, которые у меня есть?

1. Что вы думаете об этих двух способах? Учитывая эту ситуацию, что бы вы выбрали и почему (любой другой способ справиться с этим сценарием)?
2. Во втором случае создания нескольких файлов .war, как повторно запустить военную задачу для создания нового выходного файла?

Спасибо!

Answer 1

Вы должны построить одну войну для всех сред. Установите os envvar для среды (ex spring.profile = dev, spring.profile = prod).

Прочтите файл с правами собственности на основе этого envvar (весна сделает это за вас). Ex application-dev.properties, application-prod.properties

Хранить в производственном соединении пароли для подключения к Интернету в envvars, пока вы на нем.

См

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

Answer 2

Конечно можно свернуть все файлы свойств в войну и построить в какой-то логики «профиль», и вы на самом деле, возможно, это так как вы используете Spring. Spring does support "profiles" на основе значения свойства системного уровня.

Другим подходом, который я использовал в прошлом, является «сборка» файлов свойств во время сборки. Я сделал это с Gradle. По существу у вас есть файл свойств свойств среды выполнения с «заполнителями» для каждого свойства, специфичного для окружающей среды, и файл свойств свойств, который условно втягивается в проект Gradle и используется методом «expand» в задаче копирования Gradle. Вы можете настроить таргетинг на свою среду с помощью свойства командной строки, такого как -Penv=PROD.

Ваша военная задача может зависеть от другой задачи, buildRuntimeProperties или что-то в этом роде. Это создает особые свойства среды.На этом этапе вы должны решить, как обращаться с сборкой артефакт:

1. Строит свойство файл в войну и публиковать каждый ENV конкретной войны на ваш артефакт репо с идентификационной версией или артефактом ID
2. Руководить файл свойств отдельно и сохранить агрономическую среду войны и использовать свой код разрешения собственности для поиска свойств за пределами войны.