Tool zum Speichern pro Umgebungskonfiguration

Ich muss Konfigurationsinformationen pro Umgebung in einem Tool speichern.

Dies ist ein Tool mit einer GUI zum Hinzufügen / Aktualisieren von Konfigurationswerten (z. B. Verbindungszeichenfolgen). Dies sollte einen Standardwert haben und diesen basierend auf verschiedenen Umgebungen ändern können.

Es sollte eine API vorhanden sein, um diese Konfigurationswerte während der Bereitstellung in einer bestimmten Umgebung abzurufen und der Anwendung hinzuzufügen.

Ich habe eine Weile gesucht und kann keine Tools sehen, die zu dieser Rechnung passen würden. Gibt es irgendwelche Vorschläge?

Hinweis : Derzeit befinden sich die Einstellungen in TeamCity-Variablen und die Bereitstellung erfolgt über PowerShell-Skripts.

— tim
quelle

Lust auf bezahlte Sachen? Haben Sie ein Konfigurationsmanagementsystem? Was verwenden Sie für die Bereitstellung?

— Tensibai

Bezahlte Optionen werden konfiguriert. Derzeit befinden sich die Einstellungen in TeamCity-Variablen und die Bereitstellung erfolgt über PowerShell-Skripts.

— Tim

Keine reine Antwort, daher ein Kommentar. Haben Sie in Betracht gezogen, Octopus Deploy für Bereitstellungen zu verwenden, damit Sie die Umgebungskonfiguration auf äußerst flexible Weise verwalten können?

— Richard Slater

Wenn Sie ein Quellcodeverwaltungssystem mit geringer Verzweigung wie ClearCase verwenden, können Sie die Dateien einfach mit Änderungen verzweigen und Strategien für den Umgang mit OSD-Änderungen (Operating System Dependent) in VCS untersuchen. Wenn Sie git verwenden, müssen Sie die nicht standardmäßigen Zweige ständig neu gründen. Einige Konfigurationstools verfügen über Umgebungseinstellungen über Variablen. In Ansible habe ich eine Datei mit variablen Standardeinstellungen und Überlagerungen für Nicht-Produktionsumgebungen. Speichern Sie keine Einstellungen in CI-Tools, sie sollten sich alle in VCS befinden. Einschließlich der TC-Konfigurationen.

— Jiri Klouda

empfehlen, alle Konfigurationen mit der Quelle zu speichern. Wir haben mehrere Azure-Dienste und verwenden die Azure-Transformationssyntax für alle Umgebungsanpassungen. Siehe msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx . Und wir tun dies tatsächlich mit Powershell zur Bereitstellungszeit als Teil der Installation. Je nachdem, wo Sie sich in die Pipeline einbinden, können Sie dies tun, bevor Sie Bits auf die Box setzen oder, für Passwörter, danach. Wir verwenden Azure Key Vault für Geheimnisse, damit diese niemals in der Quellcodeverwaltung angezeigt werden.

— Keine Rückerstattung Keine Rückgabe

Es gibt viele Tools, die so etwas tun können, einschließlich Konfigurationsmanagement-Tools wie Chef, Ansible oder Puppet. und KVS-Tools wie Consul und etcd. Sie können es auch als Build-Schritt in Ihren CI-Server integrieren oder das Problem mithilfe der Live-Konfiguration zur Laufzeit mit einem externen Konfigurationsspeicher umgehen (wiederum so etwas wie Consul oder etcd oder eine beliebige Datenbank).

— Adrian
quelle

Möglicherweise ein anderes Repo? Eine mit Niederlassungen für QA, UAT, Prod (von noch mehr). Ein Repo, das sich von Ihren regulären Repos "Code as Code" und "Infrastructure as Code" unterscheidet.

Es ist sehr nuanciert. Wie viel Konfiguration pro Umgebung? Wird zwischen den Veröffentlichungen umgeschaltet? Sollten diese Umschaltzustände trotz binärer Bereitstellungen den Zustand beibehalten. Für welchen Client, Kunden, Gast oder Benutzer pflegen Sie die Konfiguration?

Ich habe über 5 Jahre eine Reihe von Blogeinträgen (und Prototypen / Demos) zu diesem Thema geschrieben - einschließlich Benutzeroberflächen für das Umschalten (falls erforderlich).

— paul_h
quelle