Releasezyklen / Versionierung / Staging

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.

Die Tests laufen immer auf den aktuellen Kundenmodellen ab, die ebenfalls weiter entwickelt werden damit die Abwärtskompatibilität gewährleistet werden kann, und nicht auf dem Produktivstand beim Kunden!

Es ist deshalb wichtig, dass beim Updateprozess der folgende Ablauf eingehalten wird:

  1. Test-System aktualisieren, inkl. Kundenmodelle
  2. Kundentest-Programm ausführen
  3. Vom Kunden testen lassen
  4. Kopie Test → Prod
  5. Kundentest-Programm ausführen
  6. Meldung an I-AG, dass Produktivschaltung stattgefunden hat

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