Versionsnummern in einer Datenbank-Appplikation

Laptop, Hände, TasseIn meiner kurzen Reihe über Code Documentation Practice habe ich bereits erwähnt, dass ein Programm eine Versionsnummer haben sollte, und dass diese dem Anwender in einer übersichtlichen und vor allem leicht zu findenden Weise präsentiert werden sollte, z.B. in einem About-Screen. Nun will ich dieses Konzept noch etwas erweitern.

Die zwei Seiten eines Programms

Als Anwender macht man sich über die innere Struktur eines Programms in der Regel keine besonderen Gedanken. Oft genug hat man auch gar nicht die Möglichkeiten, so etwas herauszufinden. Wir Entwickler sehen das naturgemäß anders. Insbesondere während der Programmierung sollten wir diese Struktur immer im Blick behalten.

Werbung

So hat zum Beispiel eine typische Access-Datenbankapplikation wohl immer zwei Teile: Da ist zunächst die graphische Oberfläche, die der Benutzer sieht und mit der er interagiert. Und unter der Haube werkelt der andere Teil, die Datenbank. Man kann dies in einer einzigen Datei kombinieren, aber im Mehrbenutzerbetrieb macht das in dem Artikel “Wo liegt das Backend?” ausführlich beschriebene Prinzip der Aufteilung mehr Sinn. Es gibt natürlich noch weitere Konzepte, wie man eine Applikation gestalten kann, aber ich will es bei diesem einfachen Beispiel belassen.

Es leuchtet sicher ein, dass diese beiden Teile, üblicherweise “Frontend” und “Backend” genannt, zusammen passen müssen. Denn wenn das Frontend versuchen würde, auf eine Tabelle oder auch nur ein Tabellenfeld zuzugreifen, das dort nicht existiert, würde es unnötige Fehler(meldungen) geben. Es gilt nun also zu verhindern, dass solche Konflikte gar nicht erst auftreten.

Zwei Seiten – zwei Versionen

Ich denke, das ist der naheliegende Gedanke. Wenn wir zwei Programmteile haben, sollten auch beide eine Versionsnummer haben. Das beinhaltet natürlich auch, dass beim Start des Programmes das Frontend die Versionsnummer des Backends überprüfen sollte. Wenn beide Versionen nicht zusammen passen (was immer das konkret heißt), muss sich das Frontend weigern, mit diesem Backend zusammenzuarbeiten. Dies muss dem Anwender dann natürlich klar und deutlich mitgeteilt werden – idealerweise mit einem Hinweis, wie das Problem zu beseitigen ist (Update).

Die Frage ist dabei, wer die führende Information beisteuert. Ist es die Datenbank, die “sagt”, welche Applikationsversionen sich zu ihr connecten dürfen? Oder kennt die Applikation die Versionen der Datenbank, mit denen sie zusammen arbeiten kann? Den Gedanken wollen wir später noch mal aufgreifen.

Bei diesem Vergleich kann es grundsätzlich drei Situationen geben:

  • das Frontend ist neuer als die Datenbank
  • beide haben die gleiche Version
  • die Datenbank ist neuer als das Frontend

In dem Falle, dass beide die gleiche Version haben, kann das Programm ganz normal starten. Die beiden anderen Fälle müssen oder sollten eine Meldung an den Benutzer und ggf. eine Blockade der weiteren Ausführung zur Folge haben.

Werbung

Das Prinzip der Versionsnummern

Wie sieht so eine Versionsnumer denn nun aus? Das übliche Verfahren setzt bei Applikationen auf eine Nummer mit bis zu vier Teilen:

  • 1.2.3.4

Das Prinzip wird auf der mehrsprachigen Website Semantic Versioning (deutsche Version hier) sehr gut und ausführlich beschrieben. Dort wird jedoch nur “Major.Minor.Patch” beschrieben. Die vierte Gruppe verwende ich wenn möglich, um die Build-Nummer zu identifizieren. Das ist eine fortlaufende Nummer, die jedesmal, wenn eine herauszugebende Version “gebaut” wird, automatisch erhöht werden sollte. Idealerweise wird dies durch den Buildprozess selbst gesteuert, z.B. durch Jenkins. In manchen Projekten wird statt dessen auch die SVN-Revision verwendet. Dabei muss jedoch berücksichtigt werden, dass die Verwendung dieser Nummer im Rahmen der EXE-Datei-Metadaten maximal 4stellig pro Gruppe sein darf.

Die Frage, ob man diesen Aufwand im Falle der Versionsnummer der Datenbank ebenfalls treiben will, stellt sich natürlich. Bei einer linearen Entwicklung würde vielleicht sogar eine einzelne Zahl ausreichen.

Versionen überprüfen

Das Frontend muss, um die Kompatibilität überprüfen zu können, dabei nicht nur seine eigene Versionsnummer kennen, sondern auch die Information beinhalten, welche Datenbankversion für eine Zusammenarbeit in Frage kommt. Dabei reicht es vielleicht, die minimale Datenbankversion festzuhalten, die dafür erforderlich ist. Im Gegenzug würde das Frontend jede neuere Version einer Datenbank grundsätzlich ablehnen.

Mit diesem Konzept könnte man bedenkenlos neue Versionen der Applikation veröffentlichen, solange sich die Datenbank nicht ändert, und die Prüfung würde immer korrekt arbeiten. Sobald jedoch (z.B. in einem Unternehmensnetzwerk) die zentrale Datenbankdatei aktualisiert wurde, muss zwingend auch deren Versionsnummer erhöht werden. Von diesem Moment an wäre das Frontend dann zu alt und würde den Dienst verweigern.

Doch was ist, wenn ich in der Datenbank nur unwesentliche Ergänzungen machen muss, z.B. den Default-Value eines Feldes, oder ich füge eine neue Tabelle (oder neue Felder in bestehenden Tabellen) hinzu? Müsste dies zwingend alle älteren Frontends aussperren, oder würde hier nicht ein Bereich oder eine Liste von Versionsnummern sinnvoller sein, denen ein Connect mit der Datenbank erlaubt wird?

Strategische Versionierung

Bei der oben bereits gestellten Frage, wer denn der führende Teil des Versionsnummernvergleiches ist, ist ein Blick auf die Infrastruktur hilfreich. Gerade als externer Entwickler werde ich kaum Zugriff auf die Softewareverteilmechanismen eines Unternehmens haben. Auch habe ich es noch nie erlebt, dass ein Administrator sich die Mühe machen wollte, die doch häufiger upzudatenden Access-Applikationen in solche Strukturen zu integrieren. Und überhaupt, was ist denn dieses Access eigentlich? VBA ist doch gar keine richtige Programmiersprache! Solche Überlegungen werden, wenngleich selten ausgesprochen, vermutlich in den Köpfen sein. Dass einige Entscheider sich jedoch gerade wegen der Chance, häufigere Updates zu erhalten, für Access als Plattform entscheiden, wird dabei gern ignoriert.

Apropos “häufige Updates”: Diesen Aspekt der agilen Entwicklung nehmen die Anwender durchaus gerne an, auch wenn z.B. Scrum im Projektmanagement “politisch nicht gewollt” ist.

Dennoch, das Update muss ich nolens volens den Usern überlassen. Zwar kann ich sie dabei bestmöglich unterstützen (Setup-Erstellung, automatische Prüfung, automatisches Anstoßen des Updates), aber die letzte Entscheidung liegt nicht bei mir. Ich würde aber gern die Möglichkeit haben, einzelnen Usern eine neue Version vorab zu geben. Auch kann es bei einer größeren Zahl von Anwerndern sinnvoll sein, nicht alle auf einen Schlag mit dem Update zu versorgen, damit eventuelle Supportfälle sich nicht unnötig häufen.

Aufgrund dieser Überlegungen erscheint es mir sinnvoll, wenn die Datenbank bestimmt, welche Frontend-Versionen mit ihr arbeiten dürfen. Denn auf eine dafür vorgesehene Tabelle der zentralen Datenbank habe ich jederzeit Zugriff und kann Minimum und Maximum (oder die Liste) der erlaubten Versionen jederzeit erweitern. Würde das auf vielen Rechnern installierte Frontend die Kontrolle übernehmen, würde eine neue Datenbankversion diese sofort aussperren.

Die Umsetzung

Nach diesen aufwändigen Vorüberlegungen will ich nun einen Vorschlag zur Umsetzung machen. Dabei möchte ich die sogenannten “Release Notes” mit einbeziehen. Dies ist eine Sammlung von Hinweisen für den Anwender, die jeweils spezifisch für eine bestimmte Version gegeben werden. Darin können z.B. die behobenen Bugs erwähnt werden, ebenso neue Features. Warum also nicht eine Tabelle in die Datenbank einfügen, die neben alle Versionsnummern auch solche Informationen beinhaltet, die man im Frontend oder gar beim Updatehinweis gleich mit ausgeben kann? Diese könnte z.B. so aussehen:

Mit etwas Glück (ich habe es noch nicht versucht) könnte für die Darstellung der Release Notes im Frontend auch ein RTF-Control verwendet werden, dann lebt der Text durch die Formatierung noch etwas auf. Gleichzeitig ließen sich dieselben Informationen in InnoSetup als InfoBeforeFile verwenden und würden so vor dem Updateprozess in gleicher Weise angezeigt.

Parallel dazu muss es natürlich irgendwo die Information geben, welche Version diese Datenbank gerade hat. Auch dazu würde ich der Einfachheit halber eine Tabelle anlegen:

Damit sind nun alle Weichen gestellt, und es geht nur noch darum, die betreffenden Informationen auszulesen und die Reaktionen zu programmieren. Das wird dann in einem der nächsten Artikel besprochen.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

2 × 4 =