piattaforma Java: come gestire le impostazioni di configurazione per ogni sviluppatore

Question

Ispirato da questa domanda:

How to manage Configuration Settings for each Developer

Come posso gestire le impostazioni di configurazione dell'applicazione che devono essere impostati per ogni sviluppatore senza controllo in controllo del codice sorgente sulla piattaforma Java?

Ad esempio, questo è il genere di cose che stiamo facendo ora:

• configurazione origine dati viene memorizzato in un file XML di configurazione di primavera.

• Attualmente, ogni sviluppatore modifica il file e fa del suo meglio per non commettere quel file nel controllo del codice sorgente. Molti di noi hanno delle patch (file diff) che vengono applicate al codice prima di eseguire test sul nostro database locale e rimuovere la patch prima di controllare il codice. Altri sviluppatori modificano e ripristinano i file di configurazione a mano.

• Purtroppo le patch non sono più aggiornate. A volte le persone dimenticano di ripristinare la configurazione locale prima di eseguire il commit.

La mia domanda, tuttavia, non è limitata alle impostazioni di connessione del database. Mi piacerebbe trovare una soluzione in cui ogni sviluppatore possa ignorare le impostazioni di configurazione dell'applicazione senza dover modificare i file controllati dal sorgente.

Se dobbiamo cambiare il modo in cui abbiamo memorizzato le impostazioni di configurazione, allora penso che dovremmo farlo (forse JNDI ?, file di configurazione esterni in un percorso ben noto ?, non so)

Cosa faresti/hai fatto?

Answer 1

Inserire il file di configurazione in una directory esterna. Se non è presente, leggere un file di configurazione predefinito. La directory esterna può essere configurabile e può avere un valore predefinito, ad esempio c:\workspace\config.

Opzionalmente, durante la compilazione, è possibile copiare le proprietà esterne nell'arte di costruzione.

Answer 2

Il posto migliore per avere questa configurazione è un database. E aggiungi alcune righe al tuo codice di produzione solo per leggere queste configurazioni. Significa non nuocere finché lo scopo è risolto e tutto è coerente e coerente. Metti su un piccolo framework che legge queste configurazioni e sovrascrive quelle predefinite che appaiono in produzione.

Fortunatamente alcuni framework come Rails forniscono questi e sono abbastanza sicuro che sia flessibile anche in Java.

Answer 3

Una cosa che abbiamo fatto qui è un caricatore di proprietà che controlla prima le proprietà del sistema.

ad es. hai una proprietà denominata datasource.url che viene caricata nel tuo file Spring.

Abbiamo esteso ResourceLoader per verificare innanzitutto le proprietà di sistema per verificare se esistesse una proprietà con quel nome e, in tal caso, caricarla anziché utilizzare il valore dal file delle proprietà. (In realtà penso che Spring's ResourceBundleMessageSource funzioni in modo immediato se lo si configura, ma volevamo un comportamento personalizzato a cui non dovrei partecipare).

Quindi, se cominciamo la nostra applicazione con alcuni ulteriori parametri della riga di comando:

-Ddatasource.url=[local-datasource-url]

Poi si ignora il valore dal file delle proprietà.

Ovviamente questo è più facile da fare per un'applicazione Swing (che era nostra) di un'app Web, ma comunque una possibilità.

Answer 4

Facciamo in modo che la compilazione sia completamente autonoma, incluse cose come database locali H2/Hipersonic/JavaDB e server di posta Ruby. Ciò significa che la build locale non ha configurazioni specifiche per lo sviluppatore e tutto punta solo ai componenti preconfezionati. Significa anche che oltre alle basi (JVM, Ruby, Editors) non c'è tempo per configurare una finestra di sviluppo.

Lo svantaggio è che il checkout del codice è leggermente più grande.

Answer 5

Controllare un file modello (come sample.context.xml) nel controllo del codice sorgente. Ogni sviluppatore copia quel file in context.xml e apporta le modifiche che gli piacciono. Se il vero file di configurazione risiede in una directory controllata da sorgenti, aggiungilo a svn: ignora per impedire il check-in accidentale.

==> Nessun commit accidentale e impostazioni di configurazione locali persistenti.

Se il file di configurazione locale è mancante, l'applicazione non viene avviata. Ciò rende evidente ai nuovi membri del team che le impostazioni possono essere configurate per. Ovviamente, il server di integrazione di continuos avrà anche bisogno di un file di impostazioni locali.

Per quanto riguarda dove mettere quella configurazione: rende più facile la creazione e la distribuzione se la configurazione specifica dell'istanza non fa parte del file .war. Usiamo le voci JNDI, che sono facili da cercare dai file di configurazione di primavera usando <j2ee:jndiLookup>.