File semi-modificabili (ad es. File di configurazione) e controllo della versione - best practice?

Question

Quindi, ho ucciso la compilazione oggi verificando un file di configurazione. Sa dove si trova il server (pensa al server SQL o simili) e ho lavorato contro il server che gira sulla mia scatola. Normalmente, o meglio, in altre circostanze, corriamo contro il server centrale. La build giornaliera, ovviamente, non ha trovato il "mio" server, quindi la rottura. Quindi, di nuovo, modificare il file di configurazione in modo che punti al server "normale" prima del checkin, e modificarlo di nuovo dopo il checkin è tendenzioso.

Sono stato tentato di fare in modo che VC ignori semplicemente il file di configurazione, in modo che non venga controllato per errore. D'altra parte, il repository dovrebbe contenere una versione pulita e utilizzabile del file. Non posso ignorarlo e farlo controllare allo stesso tempo, ora, potrei?

Quindi, quello che sto cercando sarebbe un modo per avere un file che, errr, che controlla, ma non controlla mai. Almeno nel caso più comune - il file di configurazione dovrebbe cambiare in modo significativo, alcuni speciali la procedura per ottenere la nuova versione nel repository sarebbe fattibile.

Se prima hai riscontrato questo problema, sarei interessato a qualsiasi soluzione che hai trovato. Finché non interrompono la compilazione, ovvero;)

Answer 1

Che cosa si può fare è avere un file di configurazione di default che rimane invariata, a meno che non si aggiunge qualche nuova configurazione. Quindi hai un file diverso che sovrascrive le configurazioni del file predefinito.

config.Default.xml 
config.User.xml 

Solo config.Default.xml è controllato all'origine. config.User.xml contiene solo le configurazioni che sono diverse per te. Quindi, supponiamo che tu stia testando su un server SQL locale, inserendo solo la stringa di connessione e sovrascrivendo la stringa di connessione config.Default.

Date un'occhiata a Net Framwork configurazione dell'applicazione, lo fa la maggior parte (se non tutti) il lavoro per voi.

Answer 2

Un metodo che ho usato è avere due versioni del file di configurazione e fare in modo che lo script di installazione tiri la versione corretta.

• settings.xml
• settings.xml a rilascio

Entrambi i file contengono le stesse chiavi, ma uno contiene valori 'dev' e l'altro contiene i valori che si aspettano da implementare e da modificare nel campo.

Answer 3

Se lavorassi, abbiamo file di configurazione separati per gli spiegamenti. Quindi i file di configurazione delle nostre soluzioni sono le versioni di sviluppo e le persone possono cambiarle a loro piacimento. Questi file di configurazione non vengono mai distribuiti ovunque.

I file di configurazione che vengono distribuiti sono memorizzati in una posizione separata nel nostro fornitore di controllo del codice sorgente. Se qualcuno ha bisogno di apportare una modifica di configurazione che verrà implementata, dovranno invece modificare questa versione.

Answer 4

Archiviamo questi tipi di file nel nostro sistema di controllo del codice sorgente e disponiamo di cartelle diverse per l'ambiente che stiamo costruendo.

Quindi abbiamo:

Dev 
Test 
Live 

ci sono sottocartelle questi file specifici per altro ambiente.

Answer 5

Abbiamo

• *. (Config | xml)
• *. (Config | xml) .cert
• *. (Config | xml) .Produzione

Hudson elimina il file iniziale e distribuisce il file corretto per l'ambiente corretto (attualmente solo cert).

Questo consente agli sviluppatori di documentare e sviluppare file di produzione, CERT e il livello di sviluppo di configurazione in modo indipendente e li hanno con versione separatamente in SVN.

Answer 6

Per ogni file di configurazione di X, creare un file che si controlli denominato x.dist, che è la configurazione predefinita distribuita. Dopo che gli sviluppatori hanno verificato, disponi di uno script che copia ciascun file x.dist in x, in cui possono personalizzare x quanto necessario. Questo script può essere rieseguito per aggiornare i file in seguito a modifiche importanti, oppure gli sviluppatori possono unire manualmente le loro modifiche.

Per la distribuzione, è possibile controllare nei file di implementazione in tempo reale e avere i vostri script di start-up si riferiscono a loro in modo esplicito (ad esempio --config x.production).

Questo approccio viene utilizzato, ad esempio, nel modo in cui è distribuito Wordpress (è necessario copiare un file modello wp-config.php) o in progetti di sviluppo che utilizzano autoconf (dove il configure.ac viene archiviato, ma il file di configurazione deve essere generato da ogni sviluppatore, un file di configurazione speciale è costruito per la distribuzione in archivi di tarball al momento del rilascio).

Answer 7

Penso che la risposta accettata sia buona, ma a seconda delle esigenze, potrebbe avere delle limitazioni.

Utilizziamo il seguente approccio. Si noti che .NET Shop utilizza VS e fa uso delle attività MSBuild (integrate, di comunità e personalizzate).

• App.config viene ignorato dal controllo di versione, ma inclusi nel progetto.
• App.default.config è sotto il controllo di versione e anche incluso nel progetto. Invece di cose hard-coding che possono cambiare, ad es. stringhe di connessione db, utilizziamo invece i token.

di un progetto compito BeforeBuild cerca esistenza di App.config e se non trovato copie App.default.config a App.config. Inoltre, il server di generazione elimina sempre App.config se esiste in un build di configurazione (garantisce una configurazione pulita). Inoltre, utilizziamo l'attività MSBuild Community FileUpdate per sostituire i token con i valori appropriati in base a ciò che sta creando il progetto.

Ad esempio, uno sviluppatore di cassa fresca può stringhe di connessione configurazione db per un database locale, una nightly build può impostare per il db di notte, ecc

Answer 8

La risposta accettata è buono.Tuttavia, è possibile fare ciò che si desidera (4 anni fa) e mantenere solo un singolo file di configurazione che esegue il check-out e non effettua mai il check-in se il proprio sistema di controllo della versione ha il concetto di lista modifiche. L'ho fatto in Perforce:

Controllare il file di configurazione e conservarlo nel proprio elenco delle modifiche. Quando commetti, commetti solo gli altri elenchi di modifiche; questo è facile da ricordare se si assegna un nome al file di configurazione come "NON COMPROMETTERE".

Un vantaggio di questo sistema è che se qualcun altro modifica la versione di produzione del file di configurazione, ovvero quella che esiste sul server e che tutti mantengono una versione locale modificata di, verrà inviata una notifica di possibili conflitti quando si ottiene il file di configurazione dal server. Con una soluzione come quella suggerita nella risposta accettata, si potrebbe continuare a ignorare in silenzio le nuove impostazioni di produzione con le impostazioni locali, che potrebbero interrompere la build locale o causare la rottura della build al prossimo commit.