Come si fa a trattare con i file di configurazione nel controllo del codice sorgente?

https://stackoverflow.com/questions/6009

08-06-2019
|

Domanda

Diciamo che hanno una tipica applicazione web e con un file di configurazione.qualunque sia.Ogni sviluppatore che lavora per il progetto avrà una versione per la loro dev scatole, ci sarà un dev, prod e la fase di versioni.Come si fa a trattare con questo nel controllo del codice sorgente?In questo file, verificare con nomi diversi o fare qualcosa di fantasia del tutto?

Soluzione

Quello che ho fatto in passato, è quello di avere un file di configurazione di default, che è controllata al controllo del codice sorgente.Quindi, ogni sviluppatore ha la propria sovrascrivere file di configurazione in cui è escluso dal controllo del codice sorgente.La prima applicazione di carichi predefinita, quindi se il file di override è presente, carichi e utilizza tutte le impostazioni da eseguire l'override di preferenza per il file di default.

In generale, minore è il file di override meglio, ma può contenere sempre di più le impostazioni per uno sviluppatore con un non-standard.

Altri suggerimenti

Non la versione del file.Versione di un modello o qualcosa del genere.

Configurazione è il codice, e si dovrebbe versione.Alla base del nostro file di configurazione sul nome utente;in entrambi UNIX/Mac e Windows, è possibile accedere il nome di login dell'utente, e fintanto che queste sono le uniche al progetto, si sta bene.Si può anche sostituire presente nell'ambiente, ma è dovrebbe controllo di versione del tutto.

Questo permette anche di esaminare gli altri le configurazioni, che può aiutare a diagnosticare costruire e piattaforma di problemi.

La mia squadra mantiene separate le versioni dei file di configurazione per ogni ambiente (web.config.dev, web.config.prova, web.config.prod).Il nostro script di distribuzione copiare la versione corretta, rinominandolo web.config.In questo modo, abbiamo il pieno controllo della versione del file di configurazione per ogni ambiente, è possibile eseguire facilmente con un diff, etc.

Attualmente ho il "modello" del file di configurazione con l'aggiunta di una estensione per esempio:

web.config.rename

Tuttavia, posso vedere un problema con questo metodo se le modifiche importanti sono cambiati.

La soluzione che uso è solo il singolo file di configurazione (web.config/app.config), ma si aggiunge una sezione speciale per il file che contiene le impostazioni per tutti gli ambienti.

C'è un LOCALE, SVILUPPO, CONTROLLO QUALITÀ DI PRODUZIONE sezioni, ciascuna contenente le chiavi di configurazione rilevanti per l'ambiente nel nostro file di configurazione(s).

Ciò che rende tutto questo lavoro è un assembly denominato xxx.Ambiente cui si fa riferimento in tutte le nostre applicazioni (windows form e web form) che racconta l'applicazione che l'ambiente operativo.

Xxx.Ambiente di assemblea, si legge in una singola riga di informazioni da macchina.config il dato macchina che gli dice che è in sviluppo, controllo qualità, etc.Questa voce è presente su tutti i nostri server e workstation.

Spero che questo aiuta.

+1 sul modello di approccio.

Ma dal momento che questa domanda tag Git, distribuito alternativa mi viene in mente, in cui le personalizzazioni sono tenuti al test privati ramo:

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

In questo schema, il principale contiene un generico "modello" config file che richiedono la minima quantità di regolazioni per diventare funzionale.

Ora, gli sviluppatori/tester possibile modificare il file di configurazione per il loro cuore il contenuto, e solo salvare queste modifiche in locale su un privato ramo testing (ad es.B' = B + personalizzazioni).Ogni volta che mainline avanza senza fatica unire nel test, il cui risultato è unione si impegna, come D' (= D + unita di versione di B personalizzazioni).

Questo schema brilla davvero quando il "modello" del file di configurazione è aggiornato:le modifiche da entrambi i lati unite, e sono estremamente probabile risultato in conflitti (o i fallimenti dei test) se sono incompatibili!

Ho usato il modello prima, cioèweb.dev.config, web.prod.config, ecc, ma ora preferisce il 'file di override' tecnica.Web.file di configurazione contiene la maggior parte delle impostazioni, ma un file esterno contenente specifici dell'ambiente di valori come il db connessioni.Buona spiegazione Paul Wilson blog.

Penso che questo riduce la quantità di duplicazione tra i file di configurazione, che può causare dolore quando l'aggiunta di nuovi valori e attributi.

Ho sempre mantenuto tutte le versioni dei file di configurazione nel controllo del codice sorgente, nella stessa cartella del web.file di configurazione.

Per esempio

web.config
web.qa.config
web.staging.config
web.production.config

Io preferisco questa convenzione di denominazione (rispetto al web.config.di produzione o di produzione.web.config) perché

Mantiene i file insieme quando si ordina per nome di file
Mantiene i file insieme quando si ordina per estensione di un file
Se il file viene accidentalmente spinto per la produzione, non sarà in grado di vedere il contenuto su http, perché IIS impedirà *.i file di configurazione da essere servita

Il file di configurazione di default dovrebbe essere configurato in modo che è possibile eseguire l'applicazione in locale sulla propria macchina.

Ancora più importante, questi file devono essere quasi al 100% identici in ogni aspetto, anche la formattazione.Non si deve utilizzare le schede in una sola versione e spazi in un altro per il rientro.Si dovrebbe essere in grado di eseguire un programma diff contro il file per vedere esattamente cosa c'è di diverso tra di loro.Io preferisco usare WinMerge per diffing il file.

Quando il processo di generazione crea il file binari, ci dovrebbe essere un compito che sovrascrive il web.config con il file di configurazione appropriato per l'ambiente.Se i file sono in formato zip, quindi non pertinenti file devono essere eliminati da costruire.

@Sovvenzione è di destra.

Io sono su un team con più di 100 altri sviluppatori, e il nostro file di configurazione non vengono controllati nel controllo del codice sorgente.Abbiamo le versioni dei file nel repository che sono tirato con ogni check out, ma non cambiano.

Ha funzionato abbastanza bene per noi.

Ho il controllo di versione, ma non spingere mai agli altri server.Se il server di produzione richiede un cambiamento, io fare che modificare direttamente il file di configurazione.

Potrebbe non essere abbastanza, ma funziona bene.

Il check-in, plain vanilla versione di app/web.config dovrebbe essere sufficientemente generico per funzionare su tutti i developer macchine, ed essere sempre aggiornato con le nuove modifiche di impostazione, etc.Se si ha bisogno di uno specifico set di impostazioni per dev/test/produzione impostazioni, check-in file separati, con queste impostazioni, come GateKiller dichiarato, con una sorta di convenzione di denominazione, anche se di solito vado con il web".prod.config", così da non modificare l'estensione del file.

Utilizziamo un modello di file di configurazione che è controllato per il controllo di versione e quindi un passo avanti nella nostra generazione automatica di sostituire specifiche voci nel file di modello con l'ambiente-impostazioni specifiche.L'ambiente specifiche impostazioni sono memorizzate in un file XML separato che è anche sotto il controllo di versione.

Stiamo usando MSBuild nella nostra generazione automatica, quindi usiamo il XmlUpdate attività da Attività Della Community Di MSBuild per aggiornare i valori.

Per un lungo periodo di tempo, ho fatto esattamente quello che bcwood ha fatto.Tengo le copie del web.dev.config, web.test.config, web.prod.config, ecc.nel controllo del codice sorgente, e quindi la mia generazione/distribuzione sistema di rinomina automaticamente come si distribuisce ai vari ambienti.Si ottiene una certa quantità di ridondanza tra i file (soprattutto con tutti i asp.net roba lì), ma in generale funziona molto bene.È inoltre necessario assicurarsi che tutti i membri del team si ricorda di aggiornamento tutti i file di cui si apporta una modifica.

A proposito, mi piace mantenere ".config" alla fine come l'estensione in modo che le associazioni di file non ottenere rotto.

Per quanto sviluppatore versioni dei file di configurazione, cerco sempre di fare del mio meglio per incoraggiare le persone a utilizzare le stesse impostazioni locali per quanto possibile, in modo che non c'è bisogno di avere la tua versione.Non sempre funziona per tutti, nel qual caso la gente di solito basta sostituire localmente come necessario e passare da lì.Non è troppo doloroso o nulla.

Nel nostro progetto abbiamo configurazione memorizzati in file con prefisso allora il nostro sistema di compilazione tira in una configurazione appropriata sulla base dell'attuale sistema hostname.Questo funziona bene per noi in un numero relativamente piccolo team, che ci permette di applicare config modifiche al file, se/quando si aggiunge un nuovo elemento di configurazione.Ovviamente questo non ha certamente scala a progetti open source con un numero illimitato di sviluppatori.

Abbiamo due problemi qui.

In primo luogo dobbiamo controllare il file di configurazione che viene fornito con il software.

È tutte e due facile per uno sviluppatore di controllare in un indesiderato di modificare il master file di configurazione, se si utilizza lo stesso file nella devoluzione ambiente.

D'altra parte, se si dispone di un file di configurazione separato che è incluso con il programma di installazione, è molto facile dimenticare di aggiungere una nuova impostazione, o di lasciare i commenti in esso ottenere la sincronizzazione con i commenti in la devoluzione configurazione di file.
Poi abbiamo il problema che gli sviluppatori devono tenere lì copia del file di configurazione di up-to-date, come altri sviluppatori di aggiungere nuove impostazioni di configurazione.Tuttavia, alcune impostazioni, come ad esempio stringhe di connessione al database sono diversi per ogni sviluppatore.
C'è un 3 ° problema il di domande/risposte non di copertura. Come si fa a unire le modifiche cliente possono fare per il tuo file di configurazione quando si installa una nuova versione del software?

Devo ancora vedere una buona soluzione che funziona bene in tutti i casi, tuttavia Ho visto alcuni soluzioni parziali (che possono essere combinate in diversi combinazioni necessarie) che riduce il problema di un sacco.

In primo luogo ridurre il numero di elementi di configurazione che avete nel vostro file di configurazione principale.

Se non avete bisogno di lasciare i vostri clienti di modificare le mappature, utilizzare Fluentemente NHibernate (o altro) per spostare la configurazione in codice.

Allo stesso modo per depency configurazione di iniezione.
Dividere i file di configurazione, quando possibile, ad es.utilizzare un file separato per configurare quello che Log4Net registri.
Non ripetere gli elementi tra un sacco di file di configurazione, ad esempiose si dispone di 4 applicazioni web che sono installati sulla stessa macchina, hanno un complessivo file di configurazione web.file di configurazione in ciascuno dei punti di applicazione per.

(Utilizzare un percorso relativo per impostazione predefinita, quindi è raro per modificare il web.file di configurazione)
Processo di sviluppo del file di configurazione per ottenere la spedizione del file di configurazione.

Questo può essere fatto per avere i valori di default nel file Xml commenti che sono quindi impostare nel file di configurazione quando una build è fatta.O avere sezioni che vengono eliminati come parte del processo di creazione del programma di installazione.
Invece di avere solo una stringhe di connessione al database, sono uno per gli sviluppatori.

E. g cerca prima di tutto “database_ianr” (dove ianr è il mio nome utente o il nome del computer) nel file di configurazione in fase di esecuzione, se non viene trovato, quindi cercare il “database”

Dispone di 2 ° livello ", per esempio-oracle o -sqlserver" rendere più veloce per gli sviluppatori per ottenere per entrambi i sistemi di database.

Questo può anche essere fatto per qualsiasi altro valore di configurazione.

Quindi tutti i valori che finiscono in “_userName” può essere striato fuori prima di spedire il file di configurazione.

Tuttavia, alla fine, che cosa è che si tratta di un “il proprietario del file di configurazione” che prende il responsabile della gestione del il file di configurazione(s) come sopra, o altrimenti.Lui/Lei dovrebbe anche fare un diff cliente rivestimenti file di configurazione prima di ogni spedizione.

Non è possibile rimuovere il necessario per una persona premurosa alcuni questa breve del problema.

Io non credo che ci sia un'unica soluzione che funziona per tutti i casi, come si può dipendere dalla sensibilità di dati nel file di configurazione, o il linguaggio di programmazione che si sta utilizzando, e tanti altri fattori.Ma io penso che è importante per mantenere i file di configurazione per tutti gli ambienti sotto il controllo del codice sorgente, in modo da poter sempre sapere quando è stato cambiato e da chi, e cosa ancora più importante, essere in grado di recuperare se le cose vanno male.E questo lo sarà.

Quindi, ecco come fare.Questo è per nodejs progetti di solito, ma penso che funziona per altri framework e linguaggi.

Quello che mi viene da fare è creare un configs la directory root del progetto, e in che directory mantenere più file per tutti gli ambienti (e alcune volte un file separato per ogni ambiente di sviluppo così) che sono tutti monitorati nel controllo del codice sorgente.E c'è il file vero e proprio che il codice utilizza denominato config alla radice del progetto.Questo è l'unico file che non è monitorata.Quindi sembra che questo

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

Quando qualcuno controllato il progetto, copia i file di configurazione egli vuole utilizzare il untracked config file e lui è libero di modificarlo come vuole, ma è anche responsabile per la copia di questi cambiamenti, prima che lui si impegna per l'ambiente il file, se necessario.

E sul server, il non tracciata file può essere semplicemente una copia (o di riferimento) del tracciato del file corrispondente a quella ambiente.In JS si può semplicemente avere 1 linea di richiedere che i file.

Questo flusso può essere un po ' complicato all'inizio, ma ha due grandi vantaggi:1.Non hai mai preoccuparsi di un file di configurazione di ottenere eliminati o modificati sul server senza avere un backup 2.Lo stesso se uno sviluppatore ha qualche configurazione personalizzato sulla sua macchina e la sua macchina smette di funzionare per qualsiasi motivo 3.Prima di ogni distribuzione può diff i file di configurazione per development e staging per esempio, per vedere se c'è qualcosa di mancante o rotto.

Dobbiamo solo mantenere la produzione config file al check-in.È responsabilità dello sviluppatore di modificare il file quando lo tiro fuori di origine sicuro per la messa in scena o di sviluppo.Questo ha bruciato noi in passato, quindi io non lo consiglio.

Ho affrontato lo stesso problema e ho trovato una soluzione.Ho aggiunto tutti i file all'archivio centrale (anche lo sviluppatore di quelli).

Quindi, se uno sviluppatore recupera i file dal repository dello sviluppatore config è anche lì.Quando si modifica fatta al file, Git non dovrebbe essere a conoscenza di questi cambiamenti.Che modo i cambiamenti non può essere spinto/commesso nel repository, ma rimanere a livello locale.

Ho risolto usando il comando git: update-index --assume-unchanged.Ho fatto un file bat che viene eseguito in prebuild di progetti contenente un file in cui le modifiche dovrebbero essere ignorato da Git.Ecco il codice che ho messo nel file bat:

IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END

Nel mio prebuild avrei fatto una chiamata al file bat, per esempio:

call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"

Ho trovato COSÌ un file bat che copia corretta del file di configurazione per il web.config/app.config.Ho anche chiamare questo file bat in prebuild.Il codice di questo file bat è:

@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2 
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same.  Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same.  Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.

Nel mio prebuild avrei fatto una chiamata al file bat, per esempio:

call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow