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=dev5. 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'è.