Più sviluppatori che utilizzano un'unica web.config con diverse impostazioni

Question

Sto creando una web app ASP.Net MVC. Ci sono più sviluppatori nel team che devono avere impostazioni diverse nel file web.config. Queste impostazioni sono per la connessione al database e una macchina virtuale Linux locale a cui è necessario accedere. Ci sono altre cose che dovremo aggiungere in futuro. Qual è una metodologia che può essere utilizzata da ogni sviluppatore per avere le proprie impostazioni personalizzate nel web.config senza il timore di avere le proprie impostazioni locali impegnate nel controllo del codice sorgente?

Le configurazioni di distribuzione non funzionano perché sono in esecuzione il sito attraverso lo sviluppo locale, VS server web. Utilizzeremo le configurazioni di implementazione per la distribuzione in diverse fasi nel nostro ambiente.

Answer 1

La maggior parte delle sezioni del file di configurazione XML consentono di utilizzare un configSource attribute. Abbiamo usato questo attributo per inserire le sezioni comunemente modificate da dev in un file separato. Ognuna di queste sezioni comunemente modificate avrebbe un file * .dev.config e * .prd.config separati. I file * .dev.config sono stati ignorati dal controllo del codice sorgente (git).

La distribuzione di produzione sarebbe quindi impostare l'attributo configSource di utilizzare i file * .prd.config. Di nuovo questo significa che è necessario mantenere aggiornati due gruppi di configurazione. Ho iniziato a lavorare su una soluzione per mantenere i file * .prd.config e * .dev.config in sincronizzazione a livello di elemento, ma non ho mai avuto il tempo di terminarlo.

Answer 2

Non sono sicuro che questa sia la soluzione più high-tech, ma chiamo semplicemente il mio web.config "web.config.sample" e aggiungo web.config a svn: ignore. Questo impedisce agli sviluppatori di verificarlo accidentalmente.

Quando una nuova chiave viene aggiunta a web.config, è sufficiente ricordarsi di duplicarla in web.config.sample.

Quando uno sviluppatore estrae una nuova copia, devono solo rinominare e configurare questo file. Ho lavorato in diverse società, e lo abbiamo fatto ogni volta, quindi non sono sicuro se c'è davvero un altro modo per farlo.

Modifica: è anche possibile impostare un hook di pre-commit per assicurarsi che nessuno abbia archiviato un web.config in una directory che contiene anche un esempio web.config.sample.

Modifica n. 2: È inoltre possibile impostare un hook post-commit che invierà tramite e-mail tutti gli utenti coinvolti quando web.config.sample viene aggiornato, pertanto le loro app non iniziano a fallire quando cercano le chiavi di configurazione mancanti. Lo farò in futuro.