Dieses Kapitel beschreibt den verwendeten Staging-Zyklus. Es ist für die Qualitätssicherung wichtig, dass alle die in den Update-Prozess involviert sind, diesen gut verstehen.

Releasezyklen

Die Weiterentwicklung des REST-Server findet laufend statt, die Release-Zyklen sind kurz. In der Regel haben diese eine Grössenordnung von einer Woche. Das heisst es wird laufend entwickelt, getestet, ausgeliefert. Die Weiterentwicklung wird so durchgeführt, dass die Abwärtskomatibilität gewährleistet ist.

Versionierung

Die Programme sind mit einer 4-teilige Versions-Nr versehen, z.B. 15.2.3.22351.

Die erste Zahl gibt die Hauptnummer wieder. Stimmt diese mit der installierten Version überein, ist die neue Version kompatibel mit der vorhandenen, wenn gleichzeitig die aktuellen Kundenmodelle installiert werden. Ist diese Zahl anders, kann es Inkompatibilitäten haben, muss aber nicht. Zu diesen sogenannten Major-Releases werden detailierte Beschreibungen ausgeliefert.

Die mittleren 2 Ziffern dienen der internen Planung.

Die letzte Zahl der 4-teiligen Versionsnummer ist die Revisions-Nr. Diese wird immer in den Jira-Tickets angegeben und ermöglicht somit eine Überprüfung, ob ein bestimmtes Ticket schon in der vorhandenen Version integriert ist.

Staging

Sämtliche Funktionalität, die in Kundenprojekten spezifiziert ist, wird über maschinelles Testing vor jeder Auslieferung verifiziert. Diese Tests decken nicht 100% aller möglichen Situationen ab, technisch ist das auch nicht möglich. Die Erfahrung der letzten Jahre hat aber gezeigt, dass neue Fehler sehr selten sind.

Es ist trotzdem wichtig, dass vor jedem Update eines Produktivsystems zuerst das Test-System aktualisiert wird, inkl. Kundenmodelle, und auch noch einmal vom Kunden getestet wird.

Wird alles für gut befunden, wird der Test-Stand auf den Produktiv-Stand kopiert. Gleichzeitig muss der I-AG mitgeteilt werden, dass eine Produktiv-Migration stattgefunden hat, damit in der internen Entwicklung die Kundenerweiterungen ebenfalls vom Test- in den Produktiv-Bereich kopiert werden kann.

Der Produktivstand beim Kunden wird also bei der I-AG versioniert. Das erlaubt eine zusätzliche Qualitätssicherung, liefert eine Historisierung der Änderungen, und ermöglicht im Notfall ein Downgrade auf den alten Stand.