Perché memorizzare la configurazione dell'app in un file di dati anziché codice esp. quando si utilizza l'integrazione continua?

Question

Perché memorizzare la configurazione dell'app in un file di dati anziché codice esp. quando si utilizza l'integrazione continua?

#1 da (3 voti)

1

Si consideri la seguente procedura CI:

Le build vengono solo distribuite (semi) automaticamente.
Tutte le modifiche sono controllate dalla versione.
La configurazione è fissa per ambiente.

Perché utilizzare i file di dati (* .config in .NET) rispetto al codice per la configurazione?

Sì, tecnicamente sarebbe "hard-coded", sebbene sia ancora centralizzato piuttosto che disperso (le buone pratiche sono ancora valide). Il vantaggio è che otterresti una maggiore quantità di verifiche in fase di compilazione. Forse anche alcuni test unitari.

Possibili ragioni contro:

Gli utenti (avanzati) possono essere autorizzati a modificare alcune configurazioni manualmente (ad esempio impostazioni grafiche dettagliate nei giochi x86).
Potrebbe essere utile vedere quale è la configurazione senza andare al repository di origine quando l'applicazione si arresta all'avvio?
Esiste una differenza tra il tipo di impostazioni della "stringa di connessione" e il tipo di impostazione "inversione del contenitore di controllo"?

continuous-integration xml configuration continuous-delivery settings

posta Den 10.06.2016 - 10:45

fonte

1 risposta

Leggi altre domande sui tag continuous-integration xml configuration continuous-delivery settings

Utilizzare HttpUtility.HtmlEncode o creare un metodo di estensione Relazione di classe interna ed esterna: la classe esterna dovrebbe essere amica di quella interiore?

score 3 · Answer 1

Al momento ho i miei file di configurazione nel processo di compilazione, tuttavia ogni volta che avrò l'opportunità li esternerò.

Ecco una risposta generale :

Perché il cliente potrebbe aver bisogno di cambiare alcuni parametri senza avere una nuova consegna.

Diciamo che usiamo un database, e per un motivo specifico, il cliente vuole cambiare il database in modo che punti a un nuovo database. Questo considerando che ha un team che gestisce l'ambiente di produzione e non è possibile toccarlo direttamente, questo è abbastanza comune. Quindi è necessario disporre di file esterni.

Inoltre, a seconda di dove lavori, potresti non essere autorizzato a conoscere gli accessi e le password della configurazione di produzione. Quindi è anche una questione di sicurezza.

Nel tuo caso ,

Se sei veramente sicuro di avere le mani nell'ambiente e nessun altro è autorizzato a toccarlo senza il tuo consenso. Puoi tenerli, ma avrai bisogno di una nuova versione del tuo prodotto ogni volta che alcune modifiche di configurazione per un ambiente.