Dove posizionare le fonti dei file di configurazione

Question

Dove posizionare le fonti dei file di configurazione

#1 da (7 voti)
#2 da (0 voti)

2

Sto sviluppando un'applicazione di servizio Windows C #, che ha diversi file di configurazione per lo sviluppo, per il sistema di produzione, per il sistema di test, come:

Dev.config
Test.config
Prod.config

Ora stiamo utilizzando il sistema di controllo della versione SVN e i file di configurazione memorizzati nelle directory dei progetti:

-trunk
  -MyFooService
    -Configs
      Dev.config
      Test.config
      Prod.config
  -MyFooService2
    -Configs
      Dev.config
      Test.config
      Prod.config

Prima di pubblicare il servizio in produzione, dovresti ottenere il rispettivo file di configurazione da quelle cartelle. Come pensi, è corretto? O i file di configurazione dovrebbero essere collocati in un altro repository? O in un'altra cartella o non dovrebbe essere inserito in VCS?

Oppure potrebbe essere meglio posizionare file del genere:

-trunk
  -src
    -MyFooService
    -MyFooService2
  -configs
    -MyFooService
      -Configs
        Dev.config
        Test.config
        Prod.config
    -MyFooService2
      -Configs
        Dev.config
        Test.config
        Prod.config

c# configuration

posta Alexanderius 08.01.2014 - 09:31

fonte

2 risposte

0

Basandosi sulla risposta di @ fejesjoco, una configurazione solo config per le macchine di sviluppo.

Per gli ambienti, memorizzerei 1 file, come ServiceX.environments sotto il controllo del codice sorgente.

Durante il processo di distribuzione o di generazione, è possibile creare uno script con un file di configurazione basato sul file di ambiente che passa quale ambiente si desidera creare. Ad esempio, forse hai integrazione, qa, prestazioni per ambienti interni. Leggere il file di ambiente, individuare la sezione appropriata e quindi creare un file di configurazione.

Quindi hai un modo coerente per distribuire i file di configurazione in ambienti interni. Inoltre non confonde gli sviluppatori con molti file di configurazione in una soluzione. Vuoi comunque il file dell'ambiente sotto il controllo del codice sorgente, ma non contrassegnarlo come config, quindi se gli inviti cambiano è solo un aggiornamento e check-in.

Per quanto riguarda i clienti esterni o le build, potresti avere un passaggio per creare una configurazione che sia più o meno un modello per loro. Dopodiché, prendono la configurazione e modificano per le proprie esigenze, ma non è necessario archiviarli sotto il controllo del codice sorgente in quanto il cliente esterno dovrebbe mantenerli.

risposta data 08.01.2014 - 18:02

fonte

Leggi altre domande sui tag c# configuration

Come considerare concettualmente e implementare le regole dell'interfaccia utente per numerosi controlli e input di dati? Quanto dovrebbe essere preoccupato un nuovo programmatore con le varie licenze (GPL, Apache, ecc.)

score 7 · Accepted Answer

Quello che abbiamo scoperto è il seguente. Mettiamo solo un file di configurazione sotto controllo di versione. Contiene le impostazioni dell'ambiente di sviluppo. Serve a due scopi. Uno, se uno sviluppatore apre un progetto e lo esegue, dovrebbe funzionare (vedi anche il test di Joel :)). Due, serve solo come modello. Non dovresti effettivamente memorizzare le impostazioni di configurazione attuali nel controllo di versione, ma questi sono due ottimi motivi per fare un'eccezione con le impostazioni di sviluppo, per necessità.

Quando pubblichiamo un progetto su un server, non sovrascriviamo mai i file di configurazione, ci limitiamo a unire le modifiche se ce ne sono. Il problema che stai affrontando è che gli ambienti possono cambiare continuamente, puoi aggiungere nuovi ambienti o modificare quelli esistenti e queste modifiche all'ambiente potrebbero non avere nulla a che fare con il tuo ciclo di sviluppo. Ancora più importante, non abbiamo alcun controllo sugli ambienti dei clienti. Perché dovremmo memorizzare queste impostazioni nel nostro controllo di versione? Quando diamo un progetto pubblicato ai nostri clienti, rinominiamo i file di configurazione in config.sample, sono costretti a modificarlo in base alle loro esigenze.