Helpful Information

[sglock]

This article is also available in English: FAQ for FirstSpirit Release Management

Softwareentwicklung bei e-Spirit erfolgt auf Grundlage eines kontinuierlichen Verbesserungsprozesses. Ziel ist es, Kunden neue Funktionen schneller zur Verfügung zu stellen, agil und bedarfsgerecht zu entwickeln und die Qualität der Software weiter zu erhöhen. Das bedeutet u.a.:

• Neue Features und Erweiterungen werden unmittelbar nach Abschluss von Entwicklung, Testing und Dokumentation veröffentlicht – unabhängig von der Versionsnummer.
• Große Erweiterungen werden – wenn möglich – inkrementell ausgerollt: Auch wenn ein Feature noch nicht seinen vollen geplanten Funktionsumfang erreicht hat, wird eine erste Version veröffentlicht, sobald sie einen nutzbaren Mehrwert liefert („Minimum viable product“). Ergänzende Features und Komfortfunktionen werden sukzessive in den nachfolgenden Releases ergänzt.
• Es gibt keine „Big Bang“ Releases mehr: Durch die sofortige Veröffentlichung der Features verteilt sich der Output der Softwareentwicklung gleichmäßig über die Zeit.

Das aktuelle Vorgehen hat Auswirkungen auf den gewohnten Umgang mit FirstSpirit Versions-Updates und zieht neue Best Practices nach sich.

Wann kommt die nächste FirstSpirit-Version und wie heißt sie?

Bereits seit 2016 veröffentlicht e-Spirit etwa monatlich eine neue FirstSpirit-Version. Diese Taktung wird weiterhin beibehalten. Alle Releases sind grundsätzlich gleichwertig, eine funktionale Unterscheidung in „Maintenance“, „Release“, „Minor“ und „Major“-Builds gibt es nicht mehr. Der konsequente Einsatz agiler, inkrementeller Prozesse und die Auswirkungen auf den Funktionsumfang lässt sich als gleichmäßige Treppenstruktur darstellen:

Jedes Update enthält neue Features und Fixes, die detailliert in den Releasenotes erläutert werden. Jedes Update zur Fehlerbehebung bringt somit in der Regel auch einen verbesserten Funktionsumfang der Software mit sich.

Zukünftig spielen Versionsnummern nur noch eine technische Rolle, zum Beispiel bei der Kommunikation zwischen Kunden, Partnern und Technical Support. In der Außenkommunikation und vertrieblich spielt die Ankündigung neuer Versionen keine Rolle mehr – stattdessen stehen Features im Vordergrund.

Bis Mitte 2018 wird die (technische) Versionsnummer nach dem bestehenden Muster fortgeschrieben, das heißt die „R“-Nummer erhöht sich mit jedem Release, also zum Beispiel „5.2R9“, „5.2R10“ usw. Ab Juni 2018 erfolgt die Bezeichnung der aktuellen Version nach dem Muster <JJJJ>-<MM>, also z.B. FirstSpirit 2018-06. Die (Major-) Versionsnummer 6 wird nicht vergeben.

Welches Update-Vorgehen empfiehlt e-Spirit Kunden?

e-Spirit empfiehlt grundsätzlich, jedes FirstSpirit-Update zu installieren, um die maximale Leistungsfähigkeit der Software nutzen zu können. Auch Bugfixes werden immer in der neuesten Software-Veröffentlichung ausgerollt. Jedes Release wird von uns auf Kompatibilität zur vorhergehenden Version getestet, so dass großflächige manuelle Tests in der Regel nicht notwendig sind. Es besteht keine Verpflichtung jedes Update installieren zu müssen, jedoch bedeutet ein Überspringen mehrerer Versionen eine vergleichsweise große Differenz zwischen den Softwareversionen und steigert die Wahrscheinlichkeit von Auswirkungen auf Betrieb und Benutzung. Geplante Updates sollten nicht in Erwartung einer Major-Version aufgeschoben werden.

Wie unterstützt e-Spirit kurze Update-Zyklen?

Wichtiges Ziel der Softwareentwicklung bei e-Spirit ist es, Inkompatibilitäten und Migrationsaufwände zu vermeiden bzw. diese softwareseitig zu kompensieren. Grundsätzlich sollen FirstSpirit-Updates mit geringem Aufwand möglich oder vollständig automatisierbar sein. Eine Vielzahl von Software-Mechanismen (zum Beispiel automatische Downloads und Updates, API zum automatisierten Rollout, VCS-Anbindung etc.) unterstützt Entwickler auf technischer Ebene. Zusätzlich stellt e-Spirit Know-how und Best Practices zur Implementierung kurzer Update-Zyklen bereit.

Innerhalb der Software minimieren mehrere Sicherheitsnetze das Risiko von Nebeneffekten bei Updates. Neben der manuellen Qualitätssicherung setzen wir auf eine hohe, automatisierte Testabdeckung in der Entwicklung. Sollte ein Release dennoch zu unerwünschtem Verhalten der Software führen, kann in vielen Fällen auch nach einem Update per Feature Toggle (siehe unten) das alte Verhalten punktuell reaktiviert werden, bis in einem späteren Release eine Lösung bereitgestellt ist.

Wie werden inkompatible Software-Änderungen zukünftig gehandhabt?

In der Vergangenheit war das (sehr seltene) Ankündigen und Ausrollen inkompatibler Änderungen an Minor- oder Major-Versionen geknüpft. Durch den Entfall dieser Mechanismen gilt in Zukunft ein Timebox-Prinzip, bei dem solche Änderungen mindestens sechs Monate vorher in den Releasenotes angekündigt werden. Wie bisher können in einer Übergangsphase alte und neue Funktionen parallel genutzt werden, um einen reibungslosen Übergang zu ermöglichen.

Was ändert sich für Verwender von FirstSpirit 4.x?

Für die veraltete Version 4.2 gilt, dass schwerwiegende Bugs in der Software im Rahmen der Wartung weiterhin behoben werden. Es werden jedoch keine Updates ausgerollt, um FirstSpirit 4.2 zu aktuellen Java-Versionen, Datenbanken, Betriebssystemen oder anderen Drittsystemen  kompatibel zu machen. So ist beispielsweise FirstSpirit 4.2R4 ausgelegt auf Java 6; diese Java-Version wird vom Hersteller nicht mehr geupdated und auch der (kostenpflichtige) „Extended Support“ läuft in absehbarer Zeit aus, sodass ein sicherer 4.2-Betrieb nicht dauerhaft gewährleistet ist. Zudem werden auch Produkterweiterungen (z.B. Content-as-a-Service) nicht für die 4.2er Linie angeboten.

e-Spirit rät dringend dazu, 4.2-Installationen auf die neueste FirstSpirit-Version upzudaten. Je früher ein Update durchgeführt wird, desto besser. Vorerst haben wir die Wartung von FirstSpirit 4.2 über das ursprünglich geplante End-of-Life (Juni 2017) hinaus verlängert. Wir behalten uns vor, die Wartung jederzeit auslaufen zu lassen.

Gibt es eine Beta-Phase der nächsten FirstSpirit-Version?

Durch die inkrementelle Weiterentwicklung innerhalb eines Software-Entwicklungsstrangs („trunk-based development“) gibt es prinzipiell keine Möglichkeit, eine Beta-Version oder einen DEV-Build zu verwenden. Wir empfehlen, die jeweils neueste FirstSpirit-Version zu nutzen, um alle Features testen und nutzen zu können und beispielsweise eigene FS-Module zu entwickeln. Teilweise werden neue Funktionen im Rahmen einer Ramp-up-Phase Interessenten vor der General Availability zur Verfügung gestellt, um gemeinsam mit e-Spirit Erfahrungen in echten Szenarien zu sammeln. So haben wir beispielsweise bei der Einführung von FirstSpirit CaaS oder beim Thema „Verteilte Entwicklung“ in enger Zusammenarbeit mit Pilotkunden den Echtbetrieb der Produkte getestet, die laufenden Entwicklungen optimiert und so eine hohe Marktreife bei der Einführung erreicht.

Wie werden Feature Toggles eingesetzt?

Feature Toggles (FT, auch Feature Switches genannt) dienen der Risikoabsicherung von Software-Änderungen in bestehenden Projekten. Hierbei können Server-Administratoren während einer Übergangsphase altes und neues Software-Verhalten konfigurativ kontrollieren. FT durchlaufen dabei einen definierten Lebenszyklus:

• e-Spirit implementiert eine Änderung des Software-Verhaltens oder ein neues Feature. Das neue Verhalten wird durch einen FT abgesichert, wenn zum Beispiel Auswirkungen auf Bestandsprojekte absehbar sind oder eine Funktion noch keine ausreichende Test-Abdeckung hat. Hierzu zählen etwa interne Refactorings oder neue Features, nicht jedoch „Schönheitskorrekturen“ oder Dokumentations-Änderungen. Ein zusätzlicher Faktor ist Risikoabschätzung: Basierend auf Vergangenheitsdaten kann für Änderungen eine Wahrscheinlichkeit von Nebeneffekten abgeschätzt werden (Bug Prediction).
• In manchen Fällen hat ein Feature noch nicht den Status der General Availability erreicht, soll jedoch von einzelnen Nutzern selektiv erprobt oder genutzt werden (Ramp-up). Solche Änderungen/Erweiterungen können per FT gelauncht werden: Die entsprechende Funktion ist in der FirstSpirit-Codebase bereits enthalten, durch die Einstellung des FT auf FALSE jedoch standardmäßig deaktiviert. Einzelne Nutzer können das neue Verhalten durch Umschalten des Toggles testen. Durch Rückmeldung der Nutzer erfährt e-Spirit, ob das neue Verhalten ausgereift ist und/oder ob Nebeneffekte auftreten.
• In anderen Fällen steht der FT in einer neuen FS-Version auf TRUE. Alle FirstSpirit-Verwender nutzen standardmäßig das neue Verhalten nach einem Update. Wenn es in einzelnen Fällen zu unerwünschten Nebeneffekten kommt, kann selektiv das alte Verhalten wiederhergestellt werden – somit kann in der Regel ein Server-Downgrade vermieden werden. Durch Rückmeldung von Kunden kann e-Spirit in neuen Releases das Verhalten korrigieren, bis keine Nebeneffekte mehr auftreten.
• Am Ende des Lebenszyklus werden der FT sowie die alten Teile der FS-Codebase dauerhaft aus der Software entfernt, das neue Verhalten somit forciert. Vor dem betreffenden Update muss sichergestellt sein, dass das Bestandsprojekt mit entferntem FT (bzw. FT auf TRUE-Stellung) das erwartete Verhalten zeigt. Im FirstSpirit Error-Reporting können die verwendeten FTs jederzeit von Administratoren ausgewertet werden.

Nach diesem Modell dürfen FT nicht zur dauerhaften Konfiguration von Softwareeigenschaften verwendet werden. FTs sind ein zusätzliches Sicherheitsnetz und nicht Teil des freigegebenen FirstSpirit Funktionsumfangs, somit auch nicht im ODFS dokumentiert. Falscher Einsatz oder ungültige Kombinationen von FTs können Performance oder Softwareverhalten negativ beeinflussen. Aus diesem Grund sollten FT nur in Absprache mit dem e-Spirit Technical Support gesetzt werden, der Kunden, Partner und Projektleiter darüber informiert, wann und wie FTs sinnvoll eingesetzt werden können. So ist sichergestellt, dass Feedback aus Bestandsprojekten unmittelbar in unsere Produktentwicklung einfließt und Administratoren rechtzeitig über die Abkündigung verwendeter FTs informiert werden.