Gestire le impostazioni che cambieranno in base all'ambiente?

la risposta di @ amon è azzeccata. Il modo migliore per affrontare questo in modo agnostico con lo stack tecnologico è con gli script di compilazione, ecc. Per creare i file necessari al momento della compilazione.

Tuttavia, dal momento che lavori su .Net land, puoi consultare NConfig . È un pacchetto NuGet che rende davvero facile caricare configurazioni specifiche della macchina. (Ci sono anche modi per usare le variabili d'ambiente, ma non l'ho mai fatto.) Potresti ancora eseguire il commit di configurazioni specifiche del computer al controllo del codice sorgente (o ignorarle con il file ignora del tuo SCM), ma anche con esse commesse, non raccogli la build di qualcun altro.

Il modo in cui l'ho fatto è attraverso configSource per i file di configurazione specifici della macchina (appSettings, mailSettings ecc.) poiché questo era il modo più compatibile e appropriato per ASP.NET ai miei occhi.

Ho escluso questi file dal controllo del codice sorgente e ho preso una foglia dallo sviluppo di Symfony 4 creando versioni .dist di ciascun file configSource per il controllo del codice sorgente, in modo che sia inviata una versione di riferimento con ogni versione del codice sorgente (ad es. AppSettings.config.dist ).

Per correggere i file che non vengono creati su build, devi impostare Build Action su Content . (Fai clic con il pulsante destro del mouse, proprietà, Azione build è in "Avanzate").

Questa sembra essere la migliore pratica per noi in quanto fornisce un riferimento alla configurazione pur continuando a fare in modo che i proprietari dell'ambiente ne assumano la responsabilità .

Ciò fornisce anche una separazione tra la modifica dei file di configurazione e i valori statici trovati in Web.config .

Potresti quindi automatizzare la creazione di file di configurazione dai file .dist in VSTS tramite uno script o se ti senti davvero piccante una funzione in Startup.cs per creare questi file se non esistono.

Come a parte - quando si estrae le build si possono fornire sostituzioni / trasformazioni per i file di configurazione semplicemente nominandole in qualsiasi fase della build in cui ci si trova (come "Debug" o "Release"), maggiori informazioni possono essere trovate qui .

Questo può essere incredibilmente utile in determinate situazioni (specialmente per i valori costanti nel tuo Web.config).

Non è compito dell'applicazione conoscere la configurazione di ogni singolo ambiente. Invece, l'ambiente dovrebbe fornire la sua configurazione. Ciò potrebbe accadere attraverso i file di configurazione o le variabili di ambiente o qualsiasi altro meccanismo.

Se si dovesse fornire un file di configurazione predefinito, questa configurazione sarà sempre errata in alcuni casi. Una volta ho lavorato a un progetto in cui è stata configurata la configurazione di default per un ambiente di test. Un giorno un collega si avvicinò alla mia scrivania: "Potresti forse cambiare la connessione al tuo database? Quando esegui i test, questo sovrascrive le modifiche nell'istanza del database my . "Spiacenti. Avevano commesso la loro configurazione, e non sapevo di dover cambiare i valori predefiniti.

Se la configurazione era per un ambiente di produzione, abbiamo l'ulteriore difficoltà che potrebbe contenere password in chiaro (o altri segreti). Anche quando ti fidi di chiunque abbia accesso alla fonte, questa è una cattiva pratica e introduce rischi inutili. Ad esempio, il rischio di utilizzare accidentalmente parti dell'ambiente di produzione durante l'esecuzione dei test.

L'unica opzione vincente non è giocare. Non fornire una configurazione predefinita.

Al contrario, è parte del processo di generazione / distribuzione per fornire la configurazione corretta. Si dice "Il problema con questo è che di default dà una build rotta perché questo file di configurazione è mancante fino a quando non viene creato. Vogliamo una build funzionante che possa essere inviata a VSTS per l'implementazione. "No. La parte della build è uno script di pre-build che crea il file di configurazione. Potrebbe essere semplice come copy config.buildServer config . È irragionevole aspettarsi che il codice venga eseguito senza alcuna procedura specifica per l'ambiente.

Quindi una configurazione "standard" potrebbe essere:

• file web.config con le impostazioni per lo sviluppo locale
• git per il controllo del codice sorgente
• build e versione su TeamCity link
• pacchetto build con OctoPack
• pubblica il pacchetto sul feed nuget interno
• deploy pacchetto con octopus link
• sovrascrive le impostazioni di web.config nel polpo con variabili con ambito ambientale.

Ovviamente ci sono opzioni alternative per ogni passaggio, ma questo ti dà una build che puoi lavorare su build con versioni locali, che possono essere implementate in ambienti e impostazioni di configurazione specifiche dell'ambiente che sono al di fuori del controllo del codice sorgente.