Aus aktuellem Anlass möchte ich hier ein paar Gedanken zum Thema Konfigurationsdatenverwaltung in Softwareprodukten aufschreiben

Was meine ich damit?

Ich meine damit die Anforderung, die es in fast jedem Softwareprojekt gibt - Das Produkt selbst ist keine starre Lösung, die nur eine Aufgabe immer wieder auf die gleiche Art und Weise erledigt, sondern eine Matritze - ein Template - zur Erfüllung ähnlich gearteter Aufgaben in variierender Form - welche der möglichen Varianten letztlich zur Anwendung kommt wird über Konfigurationsdaten gesteuert.

Die Konfigurationsdaten können bei typischen interaktiven Anwendungen durch den Anwender über eine GUI modifiziert werden. Bei Serveranwendungen sind die Konfigurationsdaten für die Anwendung selbst meist ineiner Konfigurationsdatenquelle verfügbar,auf die die Anwendung im Allgemeinen nur lesend zugreift.

Es kann so sein, dass es von einer Software verschiedene Instanzen gibt, die alle auf dieselbe Konfigurationsdatenquelle zugreifen, wobei aber jede Instanz eine andere Variante der zugrundeliegenden Verarbeitung durchführen soll. In diesem Fall müssen die Instanzen eine eigene Identität haben, die von der Konfigurationsdatenquelle beim Heraussuchen der passenden Konfigurationsdaten berücksichtigt wird.

Was ist der Anlass für diesen Aufschrieb?

Der Auslöser für diesen Artikel ist ein Vergleich zwischen verschiedenen Projekten, an denen ich in der Vergangenheit das Privileg hatte, mitarbeiten zu dürfen und die dieses Problem auf die meiner Meinung nach schlechteste mögliche Weise gelöst haben:

Die Konfigurationen residieren in einer relationalen Datenbank - teilweise sogar in demselben Schema wie die fachlichen Daten. Es existiert sowohl zur Modifikation der Konfiguration wie zur Abfrage lediglich ein proprietäres - in Teilen schlecht oder gar nicht dokumentiertes - proprietäres Protokoll, das auch noch unter einer riesigen Ladung Komplexität verborgen ist.

Welche Lösung stelle ich zur Diskussion?

Randbedingungen

Ich möchte hier zunächst anmerken, dass ich nicht behaupte, alle Softwareprodukte mit einem Wisch zu verbessern. Ich kenne mich am besten mit der Programmiersprache Java aus. Aber ich bin auch der Meinung, dass nicht jedes Problem wie ein Nagel aussehen darf, nur weil einem die Farbe des Hammerstiels gefällt.

Datenbank Pro und Contra

Die erste frage, die sich mir stellt ist - muss es wirklich eine Datenbank sein? Meine Antwort lautet ganz klar: Nein! Weder sind die Konfigurationsdaten so zahlreich, dass ich die speziellen Mechanismen einer Datenbank benötige, um elaborierte Anfragen zu stellen, noch so komplex strukturiert, dass ich dafür eine eigene Abfragesprache benötige. Es reichen einfache Textdateien - diese haben den Vorteil, menschenlesbar zu sein und außerdem mit Kommentaren angereichert werden zu können.

Komplexität

Die Komplexität einer Landschaft, in der - wie beschrieben - für separate Instanzen Variationen der Konfigurationen vorgehalten werden müssen, muss aber auch vonder vorgeschlagenen Lösung abgebildet werden können. Es muss möglich sein, die Konfigurationen auf einfache Art und Weise zu modifizieren. Gleichzeitig ist es wünschenswert, die Versionshistorie der Konfigurationen nachvollziehbar zu machen. Und man sollte auf einfache Art und Weise Variantender Konfigurationen pflegen können.

All das könnte man durch Einsatz eines Versionmanagementsystems wie etwa Git erreichen - und damit meine ich nicht, das Ablegen der Konfigurationsdaten zusammen mit den Quelltexten sondern ein separates Repository, das nur den Konfigurationen gewidmet ist.

Die Nachvollziehbarkeit ist durch den Einsatz von Git sofort gegeben. Die Komplexität kann durch Branching abgebildet werden: Konfigurationen, die für alle Instanzen gleich sein sollen werden auf dem Master gepflegt und solche, die von Instanz zu Instanz variieren sollen werden in instanzspezifischen Branches gepflegt. So ist sogar die hierarchische Vererbung von Konfigurationsitems durch die Verwendung von Branches möglich.

Standards, Dude - Standards!

Was mich in den diversen eingangs schon beschriebenen Projekten immer sehr gestört hat war die unfassbare Komplexität der proprietären Lösungen - selbst wenn die Konfigurationen einfach nur ausgelesen werden sollen (Ich schweige jetzt mal von den teilweise furchtbaren Mitteln zum Ändern der Konfiguration).

Falls man jetzt einfach ein fetch oder pull eines Repository ausführt und dann die Textdateien (im Fall von Java-Anwendungen: Properties-Dateien) einliest, die die Konfigurationen enthalten, kann man einfach auf ein oder mehrere entsprechende Properties-Objekte zugreifen.

Das Management der Konfigurationen ließe sich über die Änderung der enthaltenen Dateien realisieren. Es ist möglich, durch entsprechende Vergabe von Rechten auf dem Repository einfach die Möglichkeiten zur Änderung einzuschränken.

Eine interessante Variation dafür wäre, eine entsprechende dünne Schicht zwischen die Properties-Dateien in Git und die zu konfigurierende Anwendung zu legen, die einen Verzeichnisdienst ähnlich LDAP oder ActiveDirectory darstellt.

Aber auch hier ist ganz wichtig: Industriestandards - keine proprietären, unnötig komplexen Monster!