Best practice per il supporto di più configurazioni di login tra gli ambienti

0

Questa domanda ha più a che fare con la struttura e l'accesso di diverse configurazioni attraverso una serie di livelli di sviluppo. Quello che intendo per "livelli di sviluppo" sono gli ambienti in cui vivono le diverse versioni del codice e del prodotto. Può trattarsi di un ramo "Sviluppo", un ramo "Qualità" o una delle diverse aree "Produzione" o "Rilascio".

Abbiamo un numero di servizi che stiamo creando attorno a una VM Java. Al di fuori di Java, stiamo specificando un file di configurazione che il JAR analizza per cose come posizione, nome utente e password del server SQL. Avremo bisogno che questo file di configurazione sia diverso per ogni ambiente in cui è presente, attraverso la promozione / fusione del codice attraverso il processo di sviluppo, passando dallo sviluppo alla gestione temporanea alla qualità, ecc. Poiché ogni istanza del server SQL avrà il proprio Indirizzo IP, nome e informazioni di accesso. La struttura di ogni file di configurazione potrebbe anche essere diversa l'una dall'altra, anche se sarebbe ancora analizzabile dal JAR.

Dal momento che tutto ciò deve accadere, rimaniamo a pensare a quale potrebbe essere la soluzione migliore. Non possiamo mantenere il file di configurazione nel repository di controllo del codice sorgente (utilizzando Git al momento) con il resto del codice, perché deve essere diverso da server a server. Inoltre, qualsiasi modifica alla configurazione che deve accadere non dovrebbe essere un push / pull completo e ricostruire da quel server.

Quali sono alcuni modi per fare questo? Un'idea che abbiamo visto era avere una posizione di controllo del codice sorgente separata solo per i file di configurazione, ma per noi è ancora indesiderabile.

    
posta CrystalBlue 01.08.2016 - 20:56
fonte

2 risposte

1

Ci sono due modi in cui posso inizialmente pensare. Entrambi sono stati usati con successo in un ambiente di produzione.

Definisci per host

Questo è fondamentalmente l'utilizzo di un singolo file di configurazione che contiene tutte le impostazioni di configurazione. Ogni ambiente è definito sotto un'intestazione diversa.

Supponendo che si stia distribuendo su macchine diverse per i diversi ambienti: è possibile determinare quale gruppo di impostazioni utilizzare interrogando l'identità delle macchine host prima di leggere nelle impostazioni. Questa query può essere la lettura delle macchine IP, nome host o test per l'esistenza di un file da qualche parte - ci sono molti modi.

Puoi anche conservare più file, se lo desideri, ma direi che se la lista delle impostazioni è piccola potresti trovare più facile conservarli tutti in un unico file.

Professionisti: si adatta immediatamente all'ambiente. Non è necessario modificare alcun codice di versione per far funzionare correttamente le cose. Adattabile a un ambiente di prova proxy quando si utilizzano le intestazioni host http.

Definisci per impostazione predefinita

Questo è simile alla spiegazione di definire una configurazione per host. Ma controlli una variabile, solitamente definita all'interno del file di configurazione, che indica quali impostazioni devono essere utilizzate di default.

Quindi nella parte superiore del tuo file di configurazione potresti avere qualcosa di simile;

use_settings: production

Pro: nessuna dipendenza dall'ambiente stesso - non ci si aspetta che nulla sia in un certo modo. IP, gli URL possono sempre cambiare. L'ambiente può essere confermato visualizzando il file di configurazione.

    
risposta data 03.08.2016 - 08:55
fonte
0

Mi piace il seguente approccio: link . La premessa di base dietro è che si imposta in fase di esecuzione per ogni jvm

    
risposta data 03.08.2016 - 08:25
fonte

Leggi altre domande sui tag