Release Plan

direkt zu aktuellen Terminen

Unter einem Release ist hier die Veröffentlichung einer neuen Version des Testcenters zu verstehen. Beim Einsatz des Testcenters z. B. in aufwändigen Server-Umgebungen ist es wichtig zu wissen, zu welchen Zeitpunkten Releases mit welchen Eigenschaften erfolgen. Erst auf dieser Grundlage kann man ergänzende Maßnahmen wie Sicherheits-/Penetrationstests und Lasttests planen.

Hinweis

Die Ausführungen auf dieser Seite beziehen sich auf das IQB-Testcenter. Durch die Modularisierung nach dem Verona-Prinzip kann es Programmierungen geben (Player), die ebenfalls für die Testdurchführung erforderlich sind. Deren Release-Planung wird hier nicht thematisiert.

Versionierung

Für das Testcenter wird eine Versionierung nach dem Prinzip der Semantischen Versionierung verwendet. Danach besteht die Versionsangabe aus drei Zahlen und einem optionalen Suffix. Beispiele: 12.0.4, 15.4.0-beta.

  • Die erste Zahl wird Hauptversion oder MAJOR genannt. Wenn diese Zahl hochgezählt wird, gibt es Änderungen an Schnittstellen und Datenformaten, die grundsätzlich die Installation, die Anbindung an andere Softwarelösungen sowie die Nutzung von Datenobjekten betreffen. Es könnte sein, dass die neue Hauptversion die alten Daten nicht mehr verarbeiten kann. Hinweise hierzu sowie ggf. Migrationsstrategien sind dann im Rahmen der Veröffentlichung dokumentiert.
  • Das Hochzählen der zweiten Zahl (sog. MINOR) nennt man Funktions-Update. Es handelt sich um eine Erweiterung der Funktionen ohne Beeinträchtigung der Kompatibilität zu früheren Versionen.
  • Die letzte Zahl nennt man PATCH, was soviel bedeutet wie Beheben eines Fehlers. Es gibt nur Änderungen, die dem mit MAJOR.MINOR erwartete Funktionieren des Systems sicherstellen. Dazu zählt auch der Austausch einer Komponente, die zwar nicht Teil der Programmierung ist, aber Teil der Auslieferung ist.
  • Wenn die Versionsangabe mit einem Suffix endet, handelt es sich nicht um eine reguläre Freigabe. Die Veröffentlichung ist dann eine Vorabversion, die Fehler bzw. nicht erwartetes Verhalten enthalten kann. Die Veröffentlichung wird vorgenommen, um in vielen technischen Umgebungen das System installieren und ausprobieren zu können. Am IQB werden folgende Suffixe verwendet:
    • alpha: Der Kreis der Nutzerinnen und Nutzer soll die implementierten Funktionen prüfen. Manchmal zeigt sich dabei, dass die Anforderungen unklar waren oder es tauchen neue Ideen oder Sichtweisen auf. Nach der alpha gibt es also ggf. noch grundsätzliche Änderungen an den Funktionen.
    • beta: Die Diskussion über die Funktionen ist abgeschlossen, das IQB hat aber die Software-Tests noch nicht abgeschlossen. Insbesondere erfolgen hier manuelle Tests. Prüfungen einer beta-Version können Fehler in der Implementierung aufzeigen.
    • rc: Bei einem Release Candidate sind die Prüfungen am IQB abgeschlossen. Es folgen nun Prüfungen durch Partner bzw. in ungewöhnlichen Umgebungen. Hier sind auch Last- und Sicherheitstests anzusiedeln.

Grundsätze

Release-Pfade

  • Der Ort der Veröffentlichung ist GitHub.com.
  • Es ist die Markierung Latest gesetzt für die letzte sog. stabile Version. Diese sollten alle installieren, die neu das IQB-Testcenter auf eigener Infrastruktur nutzen möchten. Auf diese Version beziehen sich Dokumentation und Handreichungen.
  • Jede Veröffentlichung einer neuen stabilen Version erhält einen ausführlichen Text, der die Änderungen gegenüber der Vorversion beschreibt.
  • Alle Versionen mit einem Suffix gelten als Vorabversion und erhalten die Markierung Pre-release.
  • Sollte in besonderen Fällen Patches für eine frühere, nicht als Latest markierte Version veröffentlicht werden, ist diese Version weder als Pre-release noch als Latest markiert.
  • Bei der Veröffentlichung einer Vorabversion wird nur kurz beschrieben, welchen Zweck sie hat.
  • Ältere Hauptversionen werden nicht weiterentwickelt und erhalten keine Patches. In besonderen Fällen und in Abstimmung mit dem IQB kann davon abgewichen werden.
  • Stabile Versionen können Funktionen enthalten, die noch in der Entwicklung sind. Diese sind als Preview in der Release-Dokumentation markiert und sind nach der Installation bzw. dem Update deaktiviert. Über ein dokumentiertes Verfahren werden sie aktiviert bzw. zugänglich. Diesen Weg geht das Entwicklerteam, wenn es frühzeitig Rückmeldungen aus dem Nutzerkreis für neue Funktionen erhalten möchte oder eine bestimmte Änderung, für die eine Hauptversion erforderlich wäre, früher verfügbar machen möchte.
  • Funktionen, die mit der nächsten Hauptversion entfallen oder grundlegend überarbeitet werden, können in einem stabilen Release als deprecated markiert werden. Diese Markierung erfolgt im Text des Releases.

Termine und Planung

  • Einmal im Jahr im März wird eine Hauptversion veröffentlicht.
  • Hauptversionen werden mit den beabsichtigten Funktionen mindestens ein halbes Jahr vorab angekündigt (s. u.).
  • Mit der neuen Hauptversion wird die jährliche VERA-Pilotierung durchgeführt (entspr. Umstellungsplan beginnend 2026 mit Primarstufe).
  • Funktions-Updates werden nach Bedarf und nach verfügbaren Ressourcen veröffentlicht.
  • Funktions-Updates werden mindestens 1 Monat vorab angekündigt (s. u.).

Aktuelle Termine

Nächste Hauptversion 16

  • Termin: 1.3.2025
  • Geplante Änderungen:
    • Das Testcenter kann in einer Kubernetes-Umgebung eingesetzt werden. Dies führt zu Änderungen in der Auslieferung.
  • Vorabversion am 20.12.2024: Hier ist die Kubernetesfähigkeit grundsätzlich hergestellt (Gewährleistung der Ausfallsicherheit über mehrere Server hinweg), es können aber noch keine Container mehrfach gefahren werden
  • Vorabversion am 1.2.2025: Gewünschte Funktionsfähigkeit hergestellt, Testungen beginnen
  • Anmerkung: Das IQB wird mit dieser Version ausführliche Lasttests durchführen und daraus Empfehlungen ableiten, ob und wie mit dem Einsatz von Kubernetes Nutzeffekte erreicht werden können.

Nächstes Funktions-Update 15.4

  • Termin: 20.12.2024
  • Geplante Änderungen:
    • Die Programmierungen zur adaptiven Testdurchführung sind komplett überarbeitet, um das Erstellen der Steuerskripte stark zu vereinfachen.
    • In der Testleitungskonsole gibt es UX-Verbesserungen.
  • Vorabversion am 1.12.2024: beta für die manuelle Erprobung

Ausblick

  • Für die nächste Hauptversion 17 im März 2026 sind folgende Änderungen geplant:
    • Umstellung der Admin-Anmeldung auf OpenID Connect. Die Kommunikation mit Servern wird über ein JWT-Application-Token gewährleistet.
    • Im Jahr 2025 wird ein neues UI/UX des Testcenters entwickelt und mit der Version 17 implementiert. Es ändern sich in diesem Zusammenhang einige Endpunkte der API.
Zurück nach oben