streamalism.org

Innholdsfortegnelse

• 1. Konfigurasjonen må være miljøspesifikk
• 2. De .eiendommer filer for hvert miljø
• 3. Vårkonfigurasjonen
• 4. Angi eiendommen i hvert miljø
• 5. Testing og Maven
• 6. Gå videre
• 7. Konklusjon

1. Konfigurasjonen må være miljøspesifikk

Konfigurasjon må være miljøspesifikk - det er bare et faktum i livet. Hvis det ikke var tilfelle, ville det ikke være konfigurasjon, og vi ville bare hardkode verdier i kode.

For en vårapplikasjon er det flere løsninger du kan bruke - fra enkle løsninger helt til uber-fleksible, svært komplekse alternativer.

En av mer vanlige og greie løsninger er en fleksibel bruk av egenskaper filer og førsteklasses eiendomsstøtte levert av Spring.

Som et bevis på konseptet, i forbindelse med denne artikkelen, ser vi på en bestemt type eiendom - databasekonfigurasjonen. Det er veldig fornuftig å bruke en type databasekonfigurasjon for produksjon, en annen for testing og en annen for et dev-miljø.

2. Den .eiendommer Filer for hvert miljø

La oss starte Proof of Concept - ved å definere miljøene vi ønsker å målrette mot:

• Dev
• Iscenesettelse
• Produksjon

Neste - la oss lage 3 eiendomsfiler - en for hvert av disse miljøene:

• utholdenhetsdev. eiendommer
• vedvarende- iscenesettelse.egenskaper
• utholdenhetsproduksjon.egenskaper

I en typisk Maven-applikasjon kan disse ligge i src / main / resources, men uansett hvor de er, må de være tilgjengelig på klassestien når applikasjonen distribueres.

En viktig sidenote - å ha alle egenskapsfilene under versjonskontroll gjør konfigurasjonen mye mer gjennomsiktig og reproduserbar. Dette er i motsetning til å ha konfigurasjonene på disken et sted og rett og slett å peke våren til dem.

3. Vårkonfigurasjonen

På våren vil vi inkludere riktig fil basert på miljøet:

Det samme kan selvsagt også gjøres med Java-konfigurasjon:

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

Denne tilnærmingen gir mulighet for å ha flere *.eiendommer filer for spesifikke, fokuserte formål. For eksempel - i vårt tilfelle importerer persistens vårkonfigurasjonen persistensegenskapene - noe som gir perfekt mening. Sikkerhetskonfigurasjonen importerer sikkerhetsrelaterte egenskaper og så videre.

4. Stille inn eiendommen i hvert miljø

Den siste, utplasserbare krigen vil inneholde alle egenskapsfilene - for utholdenhet, de tre variantene av utholdenhet - *. egenskaper. Siden filene faktisk heter forskjellig, er det ingen frykt for å inkludere feil. Vi vil sette de envTarget variabel og velg dermed forekomsten vi ønsker fra flere eksisterende varianter.

De envTarget variabel kan angis i operativsystemet / miljøet eller som en parameter til JVM-kommandolinjen:

-DenvTarget = dev

5. Testing og Maven

For integrasjonstester som trenger utholdenhet aktivert - vi setter ganske enkelt inn envTarget eiendom i pom.xml:

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

Det tilsvarende utholdenhet-h2_test.egenskaper filen kan plasseres i src / test / ressurser slik at det vil bare brukes til testing og ikke unødvendig inkludert og distribuert med krigen ved kjøretid.

6. Går videre

Det er flere måter å bygge ytterligere fleksibilitet i denne løsningen om nødvendig.

En slik måte er å bruke en mer kompleks koding for navnene av eiendomsfilene, og spesifiserer ikke bare miljøet de skal brukes i, men også mer informasjon (for eksempel utholdenhetsleverandøren). For eksempel kan vi bruke følgende typer egenskaper: utholdenhet-h2.egenskaper, utholdenhets-mysql.egenskaper eller, enda mer spesifikk: utholdenhetsdev_h2.egenskaper, persistence-staging_mysql.properties, utholdenhetsproduksjon_amazonRDS.egenskaper.

Fordelen med en slik navnekonvensjon - og det er den bare en stevne som ingenting endres i den generelle tilnærmingen - er bare åpenhet. Det blir nå mye tydeligere hva konfigurasjonen bare gjør ved å se på navnene:

• utholdenhetsdev_h2.egenskaper: utholdenhetsleverandøren for dev miljø er en lett H2-database i minnet
• persistence-staging_mysql.properties: utholdenhetsleverandøren for iscenesettelse miljø er en MySQL-forekomst
• utholdenhetsproduksjon_amazon_rds.propertie: utholdenhetsleverandøren for produksjon miljøet er Amazon RDS

7. Konklusjon

Denne artikkelen diskuterer en fleksibel løsning for å gjøre miljøspesifikk konfigurasjon om våren. En alternativ løsning ved bruk av profiler finner du her.

Implementeringen av løsningen finner du i GitHub-prosjektet - dette er et Maven-basert prosjekt, så det skal være enkelt å importere og kjøre som det er.