Software ist nicht perfekt und wird auch ständig weiter entwickelt. Das führt dazu, dass bestimmt Konfigurationen der Software sehr viele Generationen überleben müssen. Problem dabei ist, dass durch neue Erkenntnisse Defaults geändert werden, neue Parameter notwendig werden, und dass es eben generell schwer ist den Benutzer bei Upgrades zu unterstützen:
Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten.
Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren.
Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind.
- Welche Parameter müssen hinzugefügt werden
- Welche Defaults haben sich geändert
- Für welche Version ist die Konfiguration
Anwendungen haben dann die Möglichkeit entweder den Start zu verweigern, bis das Konfigurationsfile angepasst wurde, oder sich wie die alte Version der Anwendung zu verhalten.
Welche alternative Strategien existieren? Nun eine Möglichkeit ist die Konfiguration der Anwendung zu trennen in Defaults (vom Hersteller) und Änderungen (installationsspezifisch). Damit kann der Hersteller neue Defaults ausliefern und muss nicht ermitteln welche Parameter der Anwender geändert haben möchte. Der Nachteil dabei ist allerdings, dass der Anwender sich natürlich auf bestimmte Defaults verlassen hat, und wenn diese geändert werden (typisches Beispiel: der Default für einen wenig benutzen Netzwerk Server wird von "on" auf "off" gendert. Der Anwender hatte in seiner Konfiguration die Option nicht überschrieben, da der Default ja OK war. Nach einem Update der Software kommt es zu einem Funktionalitätsverlust, weil der Benutzer nicht dazu agehalten wurde, sich über die geänderte Sematik zu informieren.
Somit bleibt so oder so nur eine ausführliche Dokumentation der Änderungen. Üblicherweise geschieht dies in Release Notes, die zu umfangreichsind um die wichtigen von den unwichtigen Informationen zu trennen. Deswegen ist für den Anwender dabei hilfreich eine Versionsnummer zu sehen, die sein File aktuell hat, die von der Anwendung erwartet wird, und welche Änderungen dazu notwendig sind.
Angenommen wir haben folgendes initiale File:
Beim Start einer neuen Software Version gibt es folgende Fehlermeldung:
Das Konfigurationsfile /etc/conf besitz die Version=1. Diese Anwendung benötigt die Version=4. Bitte nehmen Sie die notwendigen Änderungen anhand des kommentierten Templates /etc/conf.sample vor.
Damit bleibt dem Anwender jetzt die Möglicheit sein Logfile folgendermassen anzupassen:
Denn, er hat den neuen Parameter loglevel hinzugefügt, hat den netserver Parameter dessen Default sich geändert hat überschrieben mit dem benötigten Wert damit die Netzwerk Funktionen weiter bereit stehen. Die Änderung des Defaults für das basedir kann der Anwender bewusst ignorieren.
D.h. er weiss, dass er das Default für netserver überschreiben muss um die Funktionalität zu erhalten, und dass er den loglevel parameter angeben muss. Er entscheidet sich dafür sein basedir beizubehalten. Durch die Modifikation des version= parameters signalisiert der Administrator der Anwendung, dass er sich mit dem Upgrade befasst hat.
Das ganze läßt sich nicht nur auf Konfigurationsfiles anwenden, sondern auch auf andere Objekte die eine bestimmte Sematik eines Containers voraussetzen. So werden IT-Systeme deutlich besser über längere Zeiten pflegbar.
# /etc/conf
Version=1
# netserver=off
basedir=/root
Beim Start einer neuen Software Version gibt es folgende Fehlermeldung:
Das Konfigurationsfile /etc/conf besitz die Version=1. Diese Anwendung benötigt die Version=4. Bitte nehmen Sie die notwendigen Änderungen anhand des kommentierten Templates /etc/conf.sample vor.
# /etc/conf.sample
basedir=/var
loglevel=4
# Versions
# 1 Initial Version
# 2 Added required Parameter loglevel (0-5)
# 3 Changed Default for netserver=on to off
# 4 changed default for basedir to /var
Version=4
Damit bleibt dem Anwender jetzt die Möglicheit sein Logfile folgendermassen anzupassen:
# /etc/conf
Version=4
basedir=/root
netserver=on
loglevel=0
Denn, er hat den neuen Parameter loglevel hinzugefügt, hat den netserver Parameter dessen Default sich geändert hat überschrieben mit dem benötigten Wert damit die Netzwerk Funktionen weiter bereit stehen. Die Änderung des Defaults für das basedir kann der Anwender bewusst ignorieren.
D.h. er weiss, dass er das Default für netserver überschreiben muss um die Funktionalität zu erhalten, und dass er den loglevel parameter angeben muss. Er entscheidet sich dafür sein basedir beizubehalten. Durch die Modifikation des version= parameters signalisiert der Administrator der Anwendung, dass er sich mit dem Upgrade befasst hat.
Das ganze läßt sich nicht nur auf Konfigurationsfiles anwenden, sondern auch auf andere Objekte die eine bestimmte Sematik eines Containers voraussetzen. So werden IT-Systeme deutlich besser über längere Zeiten pflegbar.
Trackbacks
Trackback für spezifische URI dieses Eintrags
Keine Trackbacks
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-10@eckenfels.net
Read More
2010-03-27 20:24
2010-03-27 19:43
2010-03-27 10:56
2010-03-27 03:10
2010-03-17 01:46
2010-02-02 20:16
2010-01-10 18:07
2010-01-10 15:43
2010-01-10 15:13
