Strumento per la memorizzazione della configurazione per ambiente

Ho un requisito per memorizzare le informazioni di configurazione in base all'ambiente in uno strumento.

Questo è uno strumento con una GUI per aggiungere / aggiornare i valori di configurazione (ad es. Stringhe di connessione). Questo dovrebbe avere un valore predefinito ed essere in grado di cambiarlo in base a diversi ambienti.

Dovrebbe esserci un'API per recuperare questi valori di configurazione durante la distribuzione in un particolare ambiente da aggiungere all'applicazione.

Ho cercato per un po 'e non riesco a vedere alcuno strumento adatto a questo conto. Ci sono dei suggerimenti?

Nota : attualmente le impostazioni sono nelle variabili TeamCity e la distribuzione avviene tramite script PowerShell.

— Tim
fonte

In cambio di cose pagate? Hai qualche sistema di gestione della configurazione? cosa usi per distribuire?

— Tensibai,

Le opzioni a pagamento saranno configurate. Attualmente le impostazioni sono nelle variabili TeamCity e la distribuzione avviene tramite script PowerShell.

— tim

Non strettamente una risposta, quindi un commento - hai preso in considerazione l'utilizzo di Octopus Deploy per le distribuzioni in quanto ti consente di gestire la configurazione ambientale in modo altamente flessibile.

— Richard Slater,

Se si utilizza un sistema di controllo del codice sorgente ramificato, come ClearCase, è possibile semplicemente ramificare i file con modifiche, è possibile esaminare le strategie per la gestione delle modifiche OSD (dipendenti dal sistema operativo) in VCS. Se usi git, dovresti continuare a reimpostare costantemente i rami non predefiniti. Alcuni strumenti di configurazione hanno impostazioni per ambiente tramite variabili. In Ansible ho file con valori predefiniti variabili e overlay per ambienti non di produzione. Non memorizzare alcuna impostazione negli strumenti CI, dovrebbero essere tutti in VCS. Comprese le configurazioni TC.

— Jiri Klouda,

consiglia di memorizzare tutta la configurazione con sorgente. disponiamo di più servizi azzurro e utilizziamo la sintassi della trasformazione azzurro per tutte le personalizzazioni dell'ambiente. vedi msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx . E lo facciamo effettivamente con PowerShell al momento della distribuzione come parte dell'installazione. A seconda di dove si è agganciati alla pipeline, è possibile farlo prima di mettere i bit sulla scatola o, per le password, dopo. Usiamo Azure Key Vault per i segreti in modo che non vengano mai visualizzati nel controllo del codice sorgente.

— Nessun rimborso Nessun

Esistono molti strumenti che possono fare qualcosa del genere, inclusi strumenti di gestione della configurazione come Chef, Ansible o Puppet; e strumenti KVS come Console ed ecc. È inoltre possibile integrarlo come passaggio di creazione nel server CI o evitare di risolvere il problema utilizzando la configurazione live in fase di esecuzione su un archivio di configurazione esterno (di nuovo, qualcosa come Console o etcd o qualsiasi altro database).

— Adrian
fonte

Forse un repo diverso? Uno con filiali per QA, UAT, Prod (di né altro). Un repository diverso dai normali repository "Codice come codice" e "Infrastruttura come codice".

È altamente sfumato. Quanto config per env. È alternato tra le versioni? Se tali stati di attivazione / disattivazione mantengono lo stato nonostante le distribuzioni binarie. Per quale cliente, cliente, ospite o utente mantenere la configurazione?

Ho scritto un sacco di articoli sul blog (e prototipi / demo) sull'argomento in 5 anni - comprese le interfacce utente per la commutazione (se ne hai bisogno).

— paul_h
fonte