#java #spring #git #spring-boot
#java #spring #git #spring-boot
Вопрос:
Я создал следующие файлы свойств, которые все проверены в git:
**application.properties**
spring.application.name=my-service
spring.cloud.config.fail-fast=true
spring.cloud.config.uri=${CONFIG_URI:http://localhost:8888}
spring.cloud.loadbalancer.ribbon.enabled=false
**application-dev.properties**
spring.cloud.config.enabled=false
eureka.client.enabled=false
spring.application.name=my-service
spring.datasource.url=jdbc:mysql://${DB_URL:http://localhost:3306/db_example}
spring.datasource.username=dev
spring.datasource.password=local
В рабочей среде все конфигурации извлекаются с сервера конфигурации.
Вопросы, касающиеся этой настройки:
- Разработчик B начинает работать над этим проектом и клонирует его. К сожалению, его локальная база данных находится на другом порту с другим пользователем. Как бы он это изменил? Использовать указанные переменные среды?
- У разработчика B возникла проблема с фильтром, и он хочет установить трассировку безопасности Spring при отладке. Опять же, как он может изменить его, не загрязняя репозиторий git?
Какие варианты я вижу:
- Переменные среды
- Git игнорирует файл -local.properties, который каждый разработчик может настроить локально. Там я могу установить уровни трассировки и т.д.
Чего-то мне не хватает? Я хочу готовый к работе профиль разработчика, но, конечно, настройки необходимы для каждой отдельной машины разработчика.
Комментарии:
1. Вы также можете передавать свойства в командной строке, например
-Dprop=value
. Они должны переопределять свойства по умолчанию и, следовательно, могут быть пригодны для небольших изменений. Кроме того, насколько я знаю, существует порядок поиска файлов свойств, поэтому вы можете использовать Spring boot для поиска локального (не зафиксированного) файла с пользовательскими настройками.
Ответ №1:
Вы можете определить профили для сборки spring, которые будут переданы во время сборки проекта. Итак, определите столько, сколько файл свойств профиля вам нравится, как :
application-prod.properties
application-user1.properties
application-user2.properties
application-user3.properties
вы можете загрузить свои свойства, передав VM-Options в конфигурации вашего проекта как
-Dspring.profiles.active=user2
Пожалуйста, обратите внимание, что вы можете определить общие свойства, которые будут использоваться всеми профилями как:
application.properties
и установите свой профиль по умолчанию в application.properties
как:
spring.profiles.active=prod
Комментарии:
1. В этом случае я должен был бы убедиться, что разработчики не отправляют свои свойства в репозиторий.
2. пожалуйста, позвольте им передавать свои свойства. это не имеет значения. во время сборки вы указываете, какие свойства должны быть загружены. Я использую это решение в своем проекте для указания свойств среды развертывания и среды разработки, которые оба передаются в репозиторий git.
3. Разработчики должны просматривать свои коммиты, прежде чем они будут запущены. Если они отправляют ошибочный код (плохие порты). Это ответственность разработчиков. Это должно быть учтено в обзорах PR
4. Все, что они нажимают, не будет запускаться в рабочей среде, поскольку вы установили свой профиль по умолчанию в
application.properties
. это означает, что если вы не зададите профиль в конфигурации сборки,application-prod.properties
будет загружен. Я обновил ответ5. @ThomasAndolf по умолчанию Spring загрузится
application-prod.properties
. Таким образом, вы не должны позволять разработчикам изменять файл.
Ответ №2:
У каждого пользователя может быть своя схема базы данных, основанная на. :
spring.datasource.url=jdbc:myql://host:port/database_${user.lowername}
spring.datasource.username=database_${user.lowername}
spring.datasource.password=database_${user.lowername}
$user — это переменная среды, хранящаяся в самой ОС
Ответ №3:
Я видел это несколькими разными способами в моей компании:
- Переменные среды, как у вас в вашем примере
- Такие параметры JVM, как -DuserDatasourceUrl=jdbc:mysql: http://localhost: 3306/db_example в конфигурации запуска проекта. Это все еще требует от разработчиков работы по предоставлению конфигурации их базы данных, но с хорошим разделом «как запускать локально» в README.md это может быть другим вариантом для вас.
Документация по внешней конфигурации Spring Boot была действительно полезна для нас в понимании наших опций и порядка PropertySource.
Комментарии:
1. Я просто чувствую, что использование аргументов командной строки может быть довольно громоздким. Ввод всех типов уровней журнала. Конечно, большинство IDE также сохранят его как конфигурацию, так что этого может быть достаточно