Configurazione del progetto con Spring

Sommario

  • 1. La configurazione deve essere specifica dell'ambiente
  • 2. I file .properties per ogni ambiente
  • 3. La configurazione della molla
  • 4. Impostazione della proprietà in ogni ambiente
  • 5. Test e Maven
  • 6. Andare oltre
  • 7. Conclusione

1. La configurazione deve essere specifica dell'ambiente

La configurazione deve essere specifica per l'ambiente: questo è solo un dato di fatto. Se non fosse così, non sarebbe la configurazione e avremmo solo i valori di hardcode nel codice.

Per un'applicazione Spring ci sono diverse soluzioni che puoi usare : da soluzioni semplici fino ad alternative super flessibili e altamente complesse.

Una delle soluzioni più comuni e dirette è un uso flessibile dei file delle proprietà e il supporto delle proprietà di prima classe fornito da Spring.

Come prova di concetto, ai fini di questo articolo, daremo un'occhiata a un tipo specifico di proprietà: la configurazione del database. Ha perfettamente senso utilizzare un tipo di configurazione del database per la produzione, un'altra per i test e un'altra ancora per un ambiente di sviluppo.

2. I file .properties per ogni ambiente

Cominciamo la nostra prova di concetto, definendo gli ambienti che vogliamo targetizzare:

  • Dev
  • Messa in scena
  • Produzione

Successivamente, creiamo 3 file di proprietà, uno per ciascuno di questi ambienti:

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

In una tipica applicazione Maven, questi possono risiedere in src / main / resources , ma ovunque si trovino, dovranno essere disponibili sul classpath quando l'applicazione viene distribuita.

Un'importante nota a margine: avere tutti i file delle proprietà sotto il controllo della versione rende la configurazione molto più trasparente e riproducibile. Questo è in opposizione ad avere le configurazioni su disco da qualche parte e semplicemente indicarle Spring.

3. La configurazione della molla

In primavera includeremo il file corretto in base all'ambiente:

Lo stesso può essere fatto ovviamente anche con la configurazione Java:

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

Questo approccio consente la flessibilità di avere più file * .properties per scopi specifici e mirati . Ad esempio, nel nostro caso, la configurazione Spring di persistenza importa le proprietà di persistenza, il che ha perfettamente senso. La configurazione della sicurezza importerebbe le proprietà relative alla sicurezza e così via.

4. Impostazione della proprietà in ogni ambiente

L'ultima guerra dispiegabile conterrà tutti i file delle proprietà - per la persistenza, le tre varianti di persistenza - *. Proprietà . Poiché i file sono effettivamente denominati in modo diverso, non c'è paura di includere accidentalmente quello sbagliato. Noi imposteremo l'envTarget variabile e quindi selezionare l'istanza che vogliamo dalle molteplici varianti esistenti.

La variabile envTarget può essere impostata nel sistema operativo / ambiente o come parametro nella riga di comando JVM:

-DenvTarget=dev

5. Test e Maven

Per i test di integrazione che richiedono la persistenza abilitata, imposteremo semplicemente la proprietà envTarget nel pom.xml:

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

Il file persistence-h2_test.properties corrispondente può essere posizionato in src / test / resources in modo che venga utilizzato solo per i test e non sia incluso e distribuito inutilmente con la guerra in fase di esecuzione.

6. Andare oltre

Esistono diversi modi per creare ulteriore flessibilità in questa soluzione, se necessario.

Uno di questi è usare una codifica più complessa per i nomi dei file delle proprietà, specificando non solo l'ambiente in cui devono essere utilizzati, ma anche più informazioni (come il provider di persistenza). Ad esempio, potremmo utilizzare i seguenti tipi di proprietà: persistence-h2.properties , persistence-mysql.properties o, ancora più specifico: persistence-dev_h2.properties , persistence-staging_mysql.properties , persistence-production_amazonRDS.properties .

Il vantaggio di una tale convenzione di denominazione - ed è solo una convenzione in quanto nulla cambia nell'approccio generale - è semplicemente la trasparenza. Ora diventa molto più chiaro cosa fa la configurazione solo guardando i nomi:

  • persistence-dev_h2.properties : il provider di persistenza per il dev ambiente è un peso leggero, database di H2 in-memory
  • persistence-staging_mysql.properties : il provider di persistenza per l'ambiente di staging è un'istanza MySQL
  • persistence-production_amazon_rds.propertie : il provider di persistenza per l'ambiente di produzione è Amazon RDS

7. Conclusione

Questo articolo discute una soluzione flessibile per eseguire la configurazione specifica dell'ambiente in primavera. Una soluzione alternativa che utilizza i profili può essere trovata qui.

L'implementazione della soluzione può essere trovata nel progetto GitHub: questo è un progetto basato su Maven, quindi dovrebbe essere facile da importare ed eseguire così com'è.