Projektkonfiguration mit Spring

Inhaltsverzeichnis

  • 1. Die Konfiguration muss umgebungsspezifisch sein
  • 2. Die .properties- Dateien für jede Umgebung
  • 3. Die Federkonfiguration
  • 4. Festlegen der Eigenschaft in jeder Umgebung
  • 5. Testen und Maven
  • 6. Weiter gehen
  • 7. Fazit

1. Die Konfiguration muss umgebungsspezifisch sein

Die Konfiguration muss umgebungsspezifisch sein - das ist nur eine Tatsache des Lebens. Wenn das nicht der Fall wäre, wäre es keine Konfiguration und wir würden nur Werte im Code fest codieren.

Für eine Spring-Anwendung können Sie verschiedene Lösungen verwenden - von einfachen Lösungen bis hin zu überflexiblen, hochkomplexen Alternativen.

Eine der gängigsten und einfachsten Lösungen ist die flexible Verwendung von Eigenschaftendateien und die erstklassige Unterstützung von Eigenschaften durch Spring.

Als Proof of Concept betrachten wir für die Zwecke dieses Artikels einen bestimmten Eigenschaftstyp - die Datenbankkonfiguration. Es ist absolut sinnvoll, eine Art von Datenbankkonfiguration für die Produktion, eine andere zum Testen und eine andere für eine Entwicklungsumgebung zu verwenden.

2. Die .properties- Dateien für jede Umgebung

Beginnen wir mit unserem Proof of Concept - indem wir die Umgebungen definieren, auf die wir abzielen möchten:

  • Dev
  • Inszenierung
  • Produktion

Als Nächstes erstellen wir drei Eigenschaftendateien - eine für jede dieser Umgebungen:

  • persistence-dev.properties
  • persistence-staging.properties
  • persistence-production.properties

In einer typischen Maven-Anwendung können sich diese in src / main / resources befinden , aber wo immer sie sich befinden, müssen sie bei der Bereitstellung der Anwendung im Klassenpfad verfügbar sein .

Eine wichtige Nebenbemerkung: Wenn alle Eigenschaftendateien unter Versionskontrolle stehen, wird die Konfiguration viel transparenter und reproduzierbarer. Dies steht im Gegensatz dazu, dass die Konfigurationen irgendwo auf der Festplatte gespeichert sind und Spring einfach auf sie zeigt.

3. Die Federkonfiguration

Im Frühjahr werden wir die richtige Datei basierend auf der Umgebung einfügen:

Das gleiche kann natürlich auch mit der Java-Konfiguration gemacht werden:

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

Dieser Ansatz ermöglicht die Flexibilität, mehrere * .properties- Dateien für bestimmte, fokussierte Zwecke zu haben . Zum Beispiel - in unserem Fall importiert die Persistence Spring-Konfiguration die Persistenz-Eigenschaften - was durchaus sinnvoll ist. Die Sicherheitskonfiguration würde sicherheitsrelevante Eigenschaften usw. importieren.

4. Festlegen der Eigenschaft in jeder Umgebung

Der endgültige, bereitstellbare Krieg enthält alle Eigenschaftendateien - für die Persistenz die drei Varianten der Persistenz - *. Eigenschaften . Da die Dateien tatsächlich unterschiedlich benannt sind, besteht keine Angst, versehentlich die falsche einzuschließen. Wir werden die Variable envTarget festlegen und somit die gewünschte Instanz aus den mehreren vorhandenen Varianten auswählen.

Die envTarget- Variable kann im Betriebssystem / in der Umgebung oder als Parameter für die JVM-Befehlszeile festgelegt werden:

-DenvTarget=dev

5. Testen und Maven

Für Integrationstests, für die die Persistenz aktiviert werden muss, legen wir einfach die Eigenschaft envTarget in der Datei pom.xml fest:

 org.apache.maven.plugins maven-surefire-plugin   h2_test   

Die entsprechende Datei persistence-h2_test.properties kann in src / test / resources abgelegt werden, sodass sie nur zum Testen verwendet wird und zur Laufzeit nicht unnötig in den Krieg einbezogen und bereitgestellt wird.

6. Weiter gehen

Es gibt verschiedene Möglichkeiten, um bei Bedarf zusätzliche Flexibilität in diese Lösung zu integrieren.

Eine Möglichkeit besteht darin, eine komplexere Codierung für die Namen der Eigenschaftendateien zu verwenden, wobei nicht nur die Umgebung angegeben wird, in der sie verwendet werden sollen, sondern auch mehr Informationen (z. B. der Persistenzanbieter). Beispielsweise könnten wir die folgenden Arten von Eigenschaften verwenden: persistence-h2.properties , persistence-mysql.properties oder noch spezifischer: persistence-dev_h2.properties , persistence-staging_mysql.properties , persistence-production_amazonRDS.properties .

Der Vorteil einer solchen Namenskonvention - und es ist nur eine Konvention, da sich am Gesamtansatz nichts ändert - ist einfach Transparenz. Es wird jetzt viel klarer, was die Konfiguration nur durch Betrachten der Namen bewirkt:

  • persistence-dev_h2.properties : Der Persistenzanbieter für die Entwicklungsumgebung ist eine kompakte speicherinterne H2-Datenbank
  • persistence-staging_mysql.properties : Der Persistenzanbieter für die Staging- Umgebung ist eine MySQL-Instanz
  • persistence-product_amazon_rds.propertie : Der Persistenzanbieter für die Produktionsumgebung ist Amazon RDS

7. Fazit

Dieser Artikel beschreibt eine flexible Lösung für die umgebungsspezifische Konfiguration im Frühjahr. Eine alternative Lösung mit Profilen finden Sie hier.

Die Implementierung der Lösung finden Sie im GitHub-Projekt - dies ist ein Maven-basiertes Projekt, daher sollte es einfach zu importieren und auszuführen sein, wie es ist.