Projektkonfiguration med forår

Indholdsfortegnelse

  • 1. Konfiguration skal være miljøspecifik
  • 2. Det .ejendomme filer til hvert miljø
  • 3. Forårskonfigurationen
  • 4. Indstilling af ejendommen i hvert miljø
  • 5. Testing og Maven
  • 6. Går videre
  • 7. Konklusion

1. Konfiguration skal være miljøspecifik

Konfiguration skal være miljøspecifik - det er bare en kendsgerning. Hvis det ikke var tilfældet, ville det ikke være konfiguration, og vi ville bare hardcode-værdier i kode.

Til en Spring-applikation er der flere løsninger, du kan bruge - fra enkle løsninger til uber-fleksible, meget komplekse alternativer.

En af mere almindelige og ligetil løsninger er en fleksibel anvendelse af egenskabsfiler og førsteklasses ejendomssupport leveret af Spring.

Som et bevis på konceptet skal vi i forbindelse med denne artikel se på en bestemt type ejendom - databasekonfigurationen. Det giver mening at bruge en type databaskonfiguration til produktion, en anden til test og endnu en til et dev-miljø.

2. Den .ejendomme Filer til hvert miljø

Lad os starte vores Proof of Concept - ved at definere de miljøer, vi vil målrette mod:

  • Dev
  • Iscenesættelse
  • Produktion

Derefter - lad os oprette 3 egenskabsfiler - en til hvert af disse miljøer:

  • persistens-ev.egenskaber
  • persistens- iscenesættelse.egenskaber
  • vedholdenhedsproduktion.egenskaber

I en typisk Maven-applikation kan disse opholde sig i src / main / ressourcer, men uanset hvor de er, bliver de nødt til at være tilgængelig på klassestien når applikationen implementeres.

En vigtig sidenote - at have alle egenskabsfiler under versionskontrol gør konfigurationen meget mere gennemsigtig og reproducerbar. Dette er i modsætning til at have konfigurationerne på disken et eller andet sted og blot pege foråret på dem.

3. Forårskonfigurationen

I foråret inkluderer vi den korrekte fil baseret på miljøet:

Det samme kan naturligvis også gøres med Java-konfiguration:

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

Denne tilgang giver mulighed for fleksibiliteten ved at have flere *.ejendomme filer til specifikke, fokuserede formål. For eksempel - i vores tilfælde importerer persistens Spring-konfigurationen persistensegenskaberne - hvilket giver perfekt mening. Sikkerhedskonfigurationen importerer sikkerhedsrelaterede egenskaber og så videre.

4. Indstilling af ejendommen i hvert miljø

Den sidste krig, der kan implementeres indeholder alle egenskabsfiler - for vedholdenhed, de tre varianter af persistens - *. egenskaber. Da filerne faktisk er navngivet forskelligt, er der ingen frygt for ved et uheld at inkludere den forkerte. Vi vil sætte det envTarget variabel og vælg således den instans, vi ønsker, fra de flere eksisterende varianter.

Det envTarget variabel kan indstilles i OS / miljøet eller som en parameter til JVM-kommandolinjen:

-DenvTarget = dev

5. Test og Maven

Til integrationstest, der kræver persistens aktiveret - indstiller vi simpelthen envTarget ejendom i pom.xml:

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

Det tilsvarende persistence-h2_test.properties fil kan placeres i src / test / ressourcer så det vil kun bruges til testning og ikke unødigt inkluderet og indsat sammen med krigen i løbetid.

6. Gå videre

Der er flere måder at indbygge yderligere fleksibilitet i denne løsning, hvis det er nødvendigt.

En sådan måde er at bruge en mere kompleks kodning for navnene af egenskabsfilerne, der ikke kun angiver det miljø, hvori de skal bruges, men også mere information (såsom persistensudbyderen). For eksempel kan vi bruge følgende typer egenskaber: vedholdenhed-h2.egenskaber, vedholdenhed-mysql.egenskaber eller endnu mere specifikt: persistence-dev_h2.properties, persistence-staging_mysql.egenskaber, vedholdenhedsproduktion_amazonRDS.egenskaber.

Fordelen ved en sådan navngivningskonvention - og den er bare en konvention som intet ændrer sig i den overordnede tilgang - er simpelthen gennemsigtighed. Det bliver nu meget tydeligere, hvad konfigurationen kun gør ved at se på navnene:

  • persistence-dev_h2.properties: udholdenhedsudbyderen til dev miljø er en letvægts H2-database i hukommelsen
  • persistence-staging_mysql.egenskaber: udholdenhedsudbyderen til iscenesættelse miljø er en MySQL-forekomst
  • persistens-produktion_amazon_rds.propertie: udholdenhedsudbyderen til produktion miljø er Amazon RDS

7. Konklusion

Denne artikel diskuterer en fleksibel løsning til at foretage miljøspecifik konfiguration i foråret. En alternativ løsning ved hjælp af profiler kan findes her.

Implementeringen af ​​løsningen findes i GitHub-projektet - dette er et Maven-baseret projekt, så det skal være let at importere og køre som det er.


$config[zx-auto] not found$config[zx-overlay] not found