Wie verwaltet man Konfigurationsdateien bei der Zusammenarbeit?

Ich schreibe ein kurzes Skript mit ein paar einfachen Variablen oben auf der Seite. Ich möchte mit einem Freund daran arbeiten, aber wir sind uns nicht sicher, wie wir die Variablen verwalten sollen, die geändert werden müssen, nachdem wir jedes Mal für einen von uns gezogen haben, wodurch unnötiger Müll zum Git-Status hinzugefügt wird. Ich habe darüber nachgedacht, einfach verschiedene benannte Zweige für jeden von uns zu erstellen, und dann wird der Master nur Beispiel-Benutzernamen haben, aber es scheint albern, all diese zusätzliche Arbeit beim Zusammenführen machen zu müssen. Wir könnten die Variablen als Optionen an das Skript übergeben lassen, aber das ist weder erwünscht, noch ist es eine Trennung in eine andere separate Konfigurationsdatei. Es wäre großartig, so etwas wie eine .gitignore-Datei zu haben, aber nur ein paar Zeilen in einer Datei zu ignorieren.

Wie lässt sich das elegant bewerkstelligen? Wie wird dieses Problem normalerweise behandelt?

Sie können Änderungen an bestimmten Zeilen einer Datei nicht einfach ignorieren, fürchte ich, also müssen Sie wahrscheinlich eine separate Konfigurationsdatei haben. Im Folgenden habe ich zwei typische Möglichkeiten, damit umzugehen, und eine etwas exotischere aufgelistet:

Haben Sie eine Beispielkonfigurationsdatei in git

Hier würden Sie eine Datei führen config.sample in git als Beispiel, aber die Anwendung würde tatsächlich die Werte in einer Datei verwenden config welches ist in .gitignore. Die Anwendung würde dann einen Fehler erzeugen, es sei denn config ist anwesend. Sie müssen daran denken, Werte in der Beispieldatei zu ändern, wenn Sie neue Konfigurationsvariablen zu Ihrer persönlichen hinzufügen config Datei. In diesem Fall ist es auch eine gute Idee, Ihre Anwendung überprüfen zu lassen, ob alle erforderlichen Konfigurationsvariablen tatsächlich gesetzt sind, falls jemand vergessen hat, ihre zu aktualisieren config Datei nach Änderungen am Beispiel.

Haben Sie eine Datei mit Standardwerten in Git

Sie führen eine Akte config.defaults in git, das so weit wie möglich sinnvolle Standardkonfigurationswerte hat. Ihre Anwendung bezieht zunächst die Konfiguration aus config.defaults und dann ab config (welches ist in .gitignore), um möglicherweise einen der Standardwerte zu überschreiben. Mit dieser Methode würden Sie normalerweise keinen Fehler machen config nicht existieren, sodass die Anwendung sofort einsatzbereit ist für Leute, die sich nicht die Mühe gemacht haben, etwas zu erstellen config.

Verwendung einer einzigen Konfigurationsdatei mit –assume-unchanged

Eine dritte Möglichkeit, die ich in diesem Fall persönlich nicht empfehlen würde, wäre, eine einzelne Konfigurationsdatei, die in git festgeschrieben ist, zu verwenden git update-index --assume-unchanged <FILE>, um Git anzuweisen, Änderungen daran zu ignorieren. (Dies wird weiter in beschrieben diesen nützlichen Blogbeitrag.) Das bedeutet, dass Ihre lokalen Änderungen an der Konfigurationsdatei nicht übernommen werden git commit -a oder komm rein git status.

Eine Python/Django-spezifische Lösung besteht darin, eine gemeinsam genutzte Datei zu haben settings.py Dateien, die in das Repository eingecheckt wird, und eine lokale settings_local.py am Ende importiert settings.pydas einige der Einstellungen mit maschinenspezifischen Werten überschreibt.

In meinem Fall habe ich „config“-Variablen in einer separaten (kleinen) Datei, wie alle anderen Entwickler im Team. Dinge wie der Standort meiner Datenbank usw. werden dort aufbewahrt. Wir fügen den Namen dieser Datei in unsere ein .gitignore damit es nicht versioniert ist, sondern eine “sample_config”-Datei eincheckt, damit Neuankömmlinge eine Kopie erstellen und für ihre eigenen Zwecke verwenden können.

Andere Optionen (nicht elegant, aber möglicherweise hilfreich):

• Verwenden git stash und git stash pop für deine Konfigurationsdatei
• Haben Sie einen Zweig mit dem Namen, sagen wir, Konfig das hat deine lokale Konfigurationsdatei geändert und dann verwendet git checkout config <your config file>

Die zweite Option ist gut, wenn Sie die lokalen Konfigurationsänderungen im Repo (irgendwo) aufbewahren müssen.

Ich habe ein paar kurze Skripte wie dieses und anstatt eine separate Konfigurationsdatei zu erstellen, erstelle ich eine separate Datei setenv.sh (oder setenv.bat). Ich verschiebe die wenigen einfachen Variablen in diese neue Datei und rufe die Datei setenv.sh im Hauptskript auf. Variablen, die sich pro Benutzer nicht ändern, verbleiben im Hauptskript. Je nachdem, wie klein dieses setenv.sh-Skript ist, werde ich entweder eine Dokumentation darüber schreiben, wie diese setenv.sh erstellt wird, oder ein setenv.sh.sample als Vorlage verwenden.

Eine Variation davon besteht darin, keine setenv.sh zu erstellen oder aufzurufen und den Benutzer die im Hauptskript verwendeten Umgebungsvariablen festlegen zu lassen. Das Hauptskript wird sich beschweren, wenn die Variablen nicht existieren.

Einige kurze Skripte wachsen zu großen Skripten heran oder werden zu vollwertigen Anwendungen. In diesem Fall gehe ich den Weg der Konfigurationsdateien. Wir haben eine Anwendung, die Konfigurationsdateien namens Config verwaltet, at http://www.configapp.com. Config hat das Konzept von Umgebungen und Instanzen. In Ihrem Beispiel haben Sie 1 lokale Umgebung und 2 Instanzen. Gemeinsame Variablen gehen in die lokale Umgebung und maschinenspezifische Variablen (Sie und Ihr Freund) gehen in die Instanzen. Das ist ein wenig zu viel für kleine Skripte, funktioniert aber gut für Anwendungen.

Heutzutage verwende ich ENV-Variablen zum Beispiel in Python/Django, Sie können ihnen auch Standardwerte hinzufügen. Im Kontext von Docker kann ich die ENV-Variablen in einer docker-compose.yml-Datei oder einer zusätzlichen Datei speichern, die in der Versionskontrolle ignoriert wird.

# settings.py
import os
DEBUG = os.getenv('DJANGO_DEBUG') == 'True'
EMAIL_HOST = os.environ.get('DJANGO_EMAIL_HOST', 'localhost')