In der modernen Softwareentwicklung – gerade beim Release neuer Versionen – müssen wir ein und dieselbe Anwendung oft mit unterschiedlichen Konfigurationen ausrollen. Je nachdem, wo die Software läuft und welche weiteren Faktoren oder Anforderungen mitspielen, können diese Konfigurationen das Verhalten Ihrer Anwendung verändern. Typische Beispiele sind verschiedene Standorte, neue Sprachräume oder abweichende Anwendungsfälle.
Developer's Choice
**Software-Konfigurationen erklärt**
Wenn ich von unterschiedlichen Konfigurationen spreche, sollte man eines im Hinterkopf behalten: Der Großteil der Software ist identisch. Nur einige vergleichsweise kleine Teile unterscheiden sich. Nehmen wir an, Sie betreiben eine Einzelhandelskette und müssen Software auf den Kassenstationen ausrollen. Die meisten Deployments sind gleich – Sie brauchen nicht für jede Kasse je nach Filiale eine komplett andere Software. In Einzelfällen kann das zwar vorkommen, ist aber die Ausnahme.
Zurück zur Konfiguration. Bleiben wir beim Beispiel der Kassenanwendung. Jede Station, auf der die Anwendung läuft, braucht eine eindeutige Kennung – das ist Konfiguration. Verschiedene Länder erfordern unter Umständen unterschiedliche Standardsprachen – wieder Konfiguration. Und natürlich brauchen auch die Engineers ihre eigene "Dev-Umgebung" – erneut leicht abweichende Konfigurationen. Die Software bleibt in allen Fällen dieselbe. Sie sehen, worauf es hinausläuft.
Sämtliche Änderungen am Quellcode legen wir ohnehin in einer Versionskontrolle ab. In manchen Fällen kompilieren wir den Quellcode über einen Prozess in unterschiedliche Binärartefakte, Archive oder Docker-Container. Der Grund ist einfach: So lässt sich die jeweils passende "Version" der Software effizienter verteilen.
Trennen, um zu optimieren
Das verteilte Software-Artefakt muss zur Konfiguration der jeweiligen Laufzeitumgebung passen. Meist sind dabei verschiedene Konfigurationsbestandteile auf unterschiedlichen Ebenen relevant, oft mit einer gewissen Hierarchie. Diese Konfiguration kann auf unterschiedlichen Wegen in die Anwendung gelangen: über Umgebungsvariablen, durch das Laden vordefinierter Konfigurationsdateien, über Antworten auf hartkodierte oder (über einen anderen Mechanismus) "konfigurierte" API-Aufrufe und vieles mehr.
Der Kerngedanke: Diese Konfiguration ist dynamisch und verändert sich im Laufe der Zeit. Natürlich könnten Sie die GESAMTE Konfiguration zusammenpacken und gemeinsam mit der Anwendung jedes Mal ÜBERALL ausrollen. Doch das ist Verschwendung – und lässt sich deutlich besser machen. Der Schlüssel: Deployment und Release der Konfigurationsdaten erfolgen in einem eigenen Rhythmus, getrennt von der Anwendung selbst.
Und genau darin liegt die zentrale Optimierungsidee – die Versionskontrolle und das Management der Konfigurationsdaten vom Anwendungscode zu entkoppeln. Diese Trennung funktioniert am besten, wenn die Konfiguration einen eigenen Versionierungsort bekommt und ein separater Deployment-Prozess für das Ausrollen und Freigeben von Konfigurationsänderungen existiert – entkoppelt vom Anwendungs-Deployment und in einem eigenen Rhythmus.
Wie sehen Sie das?
Danke fürs Lesen! Bleiben Sie mit uns in Kontakt – folgen Sie dem DoiT Engineering Blog , dem DoiT LinkedIn-Kanal und dem DoiT Twitter-Kanal . Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com .