streamalism.org

Inhoudsopgave

• 1. De configuratie moet omgevingsspecifiek zijn
• 2. De .eigendommen bestanden voor elke omgeving
• 3. De lente-configuratie
• 4. De eigenschap in elke omgeving instellen
• 5. Testen en Maven
• 6. Verder gaan
• 7. Conclusie

1. De configuratie moet omgevingsspecifiek zijn

De configuratie moet omgevingsspecifiek zijn - dat is gewoon een feit. Als dat niet het geval was, dan zou het geen configuratie zijn en zouden we waarden in code hardcoderen.

Voor een veerapplicatie zijn er verschillende oplossingen die u kunt gebruiken - van eenvoudige oplossingen tot uiterst flexibele, zeer complexe alternatieven.

Een van de meest voorkomende en ongecompliceerde oplossingen is een flexibel gebruik van properties-bestanden en de eersteklas vastgoedondersteuning van Spring.

Als proof of concept zullen we voor de toepassing van dit artikel een specifiek type eigenschap bekijken: de databaseconfiguratie. Het is volkomen logisch om het ene type databaseconfiguratie te gebruiken voor productie, een ander voor testen en nog een ander voor een ontwikkelomgeving.

2. Het .eigendommen Bestanden voor elke omgeving

Laten we beginnen met ons Proof of Concept - door de omgevingen te definiëren waarop we ons willen richten:

• Dev
• Enscenering
• Productie

Vervolgens - laten we 3 eigenschappenbestanden maken - één voor elk van deze omgevingen:

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

In een typische Maven-applicatie kunnen deze zich in src / main / resources, maar waar ze ook zijn, ze zullen moeten zijn beschikbaar op het klassenpad wanneer de applicatie wordt ingezet.

Een belangrijke kanttekening - het hebben van alle eigenschappenbestanden onder versiebeheer maakt de configuratie veel transparanter en reproduceerbaar. Dit is in tegenstelling tot het ergens op schijf hebben van de configs en er simpelweg de Spring naar toe te wijzen.

3. De veerconfiguratie

In het voorjaar voegen we het juiste bestand toe op basis van de omgeving:

Hetzelfde kan natuurlijk ook worden gedaan met de Java-configuratie:

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

Deze benadering biedt de flexibiliteit om meerdere te hebben *.eigendommen bestanden voor specifieke, gerichte doeleinden. Bijvoorbeeld - in ons geval importeert de persistence Spring-configuratie de persistentie-eigenschappen - wat volkomen logisch is. De beveiligingsconfiguratie importeert beveiligingsgerelateerde eigenschappen enzovoort.

4. De eigenschap in elke omgeving instellen

De laatste, inzetbare oorlog bevat alle eigenschappenbestanden - voor persistentie, de drie varianten van persistentie - *. eigenschappen. Omdat de bestanden eigenlijk een andere naam hebben, hoeft u niet bang te zijn dat u per ongeluk de verkeerde opneemt. We zullen gaan de envTarget variabele en selecteer dus de instantie die we willen uit de meerdere bestaande varianten.

De envTarget variabele kan worden ingesteld in het besturingssysteem / omgeving of als een parameter op de JVM-opdrachtregel:

-DenvTarget = dev

5. Testen en Maven

Voor integratietests waarvoor persistentie is ingeschakeld, stellen we eenvoudig het envTarget eigenschap in de pom.xml:

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

De bijbehorende persistence-h2_test.properties bestand kan worden geplaatst in src / test / resources zodat het zal alleen worden gebruikt voor testen en niet onnodig opgenomen en ingezet bij de oorlog tijdens runtime.

6. Verder gaan

Er zijn verschillende manieren om indien nodig extra flexibiliteit in deze oplossing in te bouwen.

Een van die manieren is om een meer complexe codering voor de namen van de eigenschappenbestanden, die niet alleen de omgeving specificeren waarin ze zullen worden gebruikt, maar ook meer informatie (zoals de persistentieprovider). We kunnen bijvoorbeeld de volgende typen eigenschappen gebruiken: persistence-h2.properties, persistence-mysql.properties of, nog specifieker: persistence-dev_h2.properties, persistence-staging_mysql.properties, persistence-production_amazonRDS.properties.

Het voordeel van een dergelijke naamgevingsconventie - en dat is het ook gewoon een conventie aangezien er niets verandert aan de algemene aanpak - is het gewoon transparantie. Het wordt nu veel duidelijker wat de configuratie doet door alleen naar de namen te kijken:

• persistence-dev_h2.properties: de persistentieprovider voor het dev omgeving is een lichtgewicht H2-database in het geheugen
• persistence-staging_mysql.properties: de persistentieprovider voor het enscenering omgeving is een MySQL-instantie
• persistence-production_amazon_rds.propertie: de persistentieprovider voor het productie omgeving is Amazon RDS

7. Conclusie

Dit artikel bespreekt een flexibele oplossing voor het uitvoeren van omgevingsspecifieke configuratie in Spring. Een alternatieve oplossing met profielen vindt u hier.

De implementatie van de oplossing is te vinden in het GitHub-project - dit is een op Maven gebaseerd project, dus het moet gemakkelijk te importeren en uit te voeren zijn zoals het is.