Конфигурация проекта с Spring

Оглавление

• 1. Конфигурация должна быть специфичной для среды
• 2. Файлы .properties для каждой среды
• 3. Конфигурация Spring
• 4. Установка свойства в каждой среде
• 5. Тестирование и Maven
• 6. Идем дальше
• 7. Заключение

1. Конфигурация должна быть специфичной для среды

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

Для приложения Spring есть несколько решений, которые вы можете использовать — от простых решений до сверхгибких и очень сложных альтернатив.

Одним из наиболее распространенных и простых решений является гибкое использование файлов свойств и поддержка свойств первого класса, предоставляемая Spring .

В качестве доказательства концепции для целей этой статьи мы рассмотрим один конкретный тип свойства — конфигурацию базы данных. Имеет смысл использовать один тип конфигурации базы данных для производства, другой для тестирования и еще один для среды разработки.

2. Файлы .properties для каждой среды

Давайте начнем проверку концепции с определения сред, на которые мы хотим ориентироваться:

• Дев

• Постановка

• Производство

720

Далее — давайте создадим 3 файла свойств — по одному для каждой из этих сред:

• постоянство-dev.properties
• сохранение-staging.properties
• сохранение-production.properties

В типичном приложении Maven они могут находиться в src/main/resources , но где бы они ни находились, они должны быть доступны в пути к классам при развертывании приложения.

Важное замечание: наличие всех файлов свойств под контролем версий делает конфигурацию более прозрачной и воспроизводимой. Это противоположно тому, чтобы где-то хранить конфиги на диске и просто указывать на них Spring.

3. Конфигурация Spring

В Spring мы включим правильный файл в зависимости от среды:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:context="http://www.springframework.org/schema/context"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-4.0.xsd
      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-4.0.xsd">

      <context:property-placeholder
         location="
         classpath*:*persistence-${envTarget}.properties" />

</beans>

То же самое, конечно, можно сделать и с конфигурацией Java:

@PropertySource({ "classpath:persistence-${envTarget:dev}.properties" })

Такой подход обеспечивает гибкость использования нескольких файлов *.properties для конкретных целей . Например, в нашем случае конфигурация Spring постоянства импортирует свойства постоянства, что вполне логично. Конфигурация безопасности будет импортировать свойства, связанные с безопасностью, и так далее.

4. Установка свойства в каждой среде

Последняя развертываемая война будет содержать все файлы свойств — для сохраняемости три варианта persistence-*.properties . Поскольку файлы на самом деле называются по-разному, можно не бояться случайно включить не тот файл. Мы установим переменную envTarget и, таким образом, выберем нужный экземпляр из нескольких существующих вариантов .

Переменная envTarget может быть установлена в ОС/окружении или в качестве параметра командной строки JVM:

-DenvTarget=dev

5. Тестирование и Maven

Для интеграционных тестов, которым необходимо включить постоянство, мы просто установим свойство envTarget в pom.xml:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <configuration>
      <systemPropertyVariables>
         <envTarget>h2_test</envTarget>
      </systemPropertyVariables>
   </configuration>
</plugin>

Соответствующий файл persistence-h2_test.properties можно поместить в src/test/resources , чтобы он использовался только для тестирования, а не без необходимости включался и развертывался вместе с войной во время выполнения.

6. Идем дальше

Существует несколько способов придания дополнительной гибкости этому решению, если это необходимо.

Один из таких способов — использовать более сложную кодировку для имен файлов свойств, указав не только среду, в которой они должны использоваться, но и дополнительную информацию (например, поставщика постоянства). Например, мы можем использовать следующие типы свойств: persistence-h2.properties , persistence-mysql.properties или даже более конкретно: persistence-dev_h2.properties , persistence-staging_mysql.properties , persistence-production_amazonRDS.properties .

Преимущество такого соглашения об именах — и это всего лишь соглашение , поскольку в общем подходе ничего не меняется — просто прозрачность. Теперь становится намного понятнее, что делает конфигурация, только взглянув на имена:

• persistence-dev_h2.properties : поставщик сохраняемости для среды разработки представляет собой легковесную базу данных H2 в памяти.
• persistence-staging_mysql.properties : поставщик сохраняемости для промежуточной среды — это экземпляр MySQL.
• persistence-production_amazon_rds.propertie : поставщиком постоянства для производственной среды является Amazon RDS

7. Заключение

В этой статье обсуждается гибкое решение для настройки среды в Spring. Альтернативное решение с использованием профилей можно найти здесь .

Реализацию решения можно найти в проекте GitHub — это проект на основе Maven, поэтому его должно быть легко импортировать и запускать как есть.