[Erfahrungsbericht] Wie erfolgt die Freigabe einer Hauptversion - Geschichte der V4

[StefanW]

Verehrte Foristen,

es gibt derzeit eine Reihe Diskussionen mit Kunden zu den Verzögerungen mit der V4. Damit ich dann einfach auf den Artikel verweisen kann, habe ich das Themengebiet aufbereitet, auch um der häufigen Behauptung entgegenzutreten, die V4 hätte es ohne VISU "sehr viel früher" gegeben.

Hierzu ein paar Informationen im Allgemeinen und im Speziellen, wie das mit der V4 gelaufen ist bzw. noch laufen wird. Bitte festschnallen. Ist lang, aber ich denke, auch sehr interessant, für jeden, der ein wenig ins Labor der Entwicklung sehen will und auf was alles zu achten ist. Weil es ist viel mehr, als man meinen würde.

An alle professionellen Entwickler: Das ist eine Kurzdarstellung für Endkunden. Bitte verzeiht mir Ungenauigkeiten und Vereinfachungen.


Wann ist Software fertig?

Die kurze Antwort: Software ist dann fertig, wenn man sich dazu entscheidet.

Tatsächlich gibt es eine Reihe objektiverer Kriterien, aber auch diese sind Ergebnis eines umfassenderen Entscheidungsprozesses der letztlich eine Antwort auf die eigentliche Frage ist:


Was soll eine Software denn "können"?

Allgemein würde man sagen: Berechnungen oder Datenmanipulationen ausführen.

Im Detail sind es eine Menge ALLGEMEINER Eigenschaften, die Software beim Timberwolf erfüllen soll:

- Stabile und Robuste Funktion
- IT-Sicherheit (Verschlüsselung, Authentifizierung usw.)
- Erweiterbarkeit / Pflegbarkeit der Software
- kurze Reaktionszeiten bei der Bedienung
- Effektive Ressourcennutzung
- Upgradebarkeit der installierten Software durch Nutzer, auch bei großen Sprüngen
- Übernahme früherer Daten und Konfigurationen durch Nutzer, auch bei großen Sprüngen
- Einfach und flexibel bedienbar
- Schützt Benutzer vor nicht erlaubter und warnt vor ungünstiger Konfiguration
- Kontextsensitive Hilfe
- Selbe Funktionalität über alle Architekturen
- Häufige Upgrades zum geringstmöglichen Preis

Nichts davon ist selbstverständlich und muss einzeln erarbeitet werden. Zum Beispiel war die Software des WireGate Servers zwar robust in der Funktion, aber die Software war null erweiterbar (darum mussten wir ja auch neu entwickeln).

Die speziellen Eigenschaften richten sich nach der jeweils zu implementierenden Funktion. Hier gibt es keine allgemeine Aussage, weil für 1-Wire sind die Anforderungen andere als für Modbus.


Was bedeutet Stabil & Robust?

Unter Stabilität und Robustheit verstehen wir:

1. Die Software funktioniert stabil, bei jeder Konfiguration, die der Nutzer vornimmt
2. Die Software ist robust gegenüber beliebigen - auch falschen - Daten die jedes angeschlossene andere Geräte sendet
3. Die Software übersteht im laufenden Betrieb alle, auch aufwändigen Änderungen an der Konfiguration sowie durch extremere Veränderungen wie Restore, Upgrade usw.

Ich denke, wir sind uns sicher alle einig, dass eine Software, die nicht stabil und auch gegenüber fremden Einflüssen völlig robust funktioniert, gerade in einer Automatisierung, keinen Sinn macht.

Daher war die Vorgabe an die Entwicklern von Beginn an, dass die drei wichtigsten Leistungsmerkmale des Timberwolf Servers lauten: Robust, Robust, Robust. Und so kennt Ihr den Timberwolf Server auch.

Sehen wir uns an, was wir dafür tun müssen und wie das - übrigens massiv - unsere Entscheidungen beeinflusst.


Gefahr für Stabilität und Robustheit

Es gibt nichts schlimmeres für die Stabilität und Robustheit einer ausgereiften, bekannten und stabilen Software, als etwas an dieser zu ändern und diese dann im laufenden Betrieb beim Kunden auszutauschen. Das ist, vor allem bei umfangreichen Änderungen, das maximale Risko.

Andererseits wünschen unsere Kunden genau dass, neue Funktionen und Leistungsmerkmale. Auch in bestehenden Systemen. Auch bitte möglichst gleich und selbstverständlich alles stabil.

==> Tatsächlich sind das diametrale Anforderungen. Weil frische neue Software schnell ausrollen und gleichzeitig deren Stabilität sicherzustellen geht nicht. Wirklich nicht. Und man kann, wenn man Stabilität und Robustheit ernst nimmt, an den Prozess auch keine Kompromisse machen, weil sonst wird es nicht robust.


Architektur des Timberwolf Servers - um das Problem einzugrenzen

Es war von Anfang an - und ist es heute noch - die größte Herausforderung, der wir nahezu täglich begegnen, wie alle gewünschten Eigenschaften an die Software erfüllt werden sollen UND wie wir sicherstellen, dass diese auch Stabil und Robust ist.

Denn es war von Anfang an klar, dass es häufig neue Upgrades geben soll. Also musste die Architektur auch darauf ausgelegt werden.

Wir haben deshalb das Design des Timberwolf Servers speziell auf diese Anforderung ausgelegt - mit einer ganzen Reihe von Details. Maßgeblich sind dabei die Realisierung in Microservices, einem Multi Client Konfig System und einem leistungsfähigen n:m Change Propagation System. Das bedeutet, die Software in möglichst kleine, einzelne Module aufzuteilen und ein Nachrichtensystem dazwischen, für die Zusammenarbeit dieser kleinen Module. Zum einen soll damit erreicht werden, dass bei Ausfall eines Moduls, nicht auch die anderen Module in "Mitleidenschaft gerissen" werden und zum anderen sind kleine Module einfacher wartbar und mit geringerem Aufwand und vor allem unabhängig voneinander, austauschbar.

Was einfach klingt, ist es jedoch nicht. Wir haben ca. 5 bis 7 Mannjahre nur an diesem Architekturmerkmal entwickelt. Erst letzte Woche hatte ich ein Gespräch mit einem Kunden, der selbst in der embedded Entwicklung tätig ist und der wollte u.a. wissen, mit welchem Trick wir eigentlich diese unglaubliche Erweiterbarkeit der Timberwolf Software hinbekommen (das was im vorherigen Absatz steht).


Neue Herausforderungen durch diese Architektur

Allerdings führt eine solche Architektur zu einer immensen Herausforderung, weil dadurch ein System entsteht, das in seiner Gesamtheit nicht mehr prädiktiv gerechnet wird, also in dem Sinne, das der Entwickler nicht mehr vorhersehen kann, was wie in welcher Reihenfolge abgearbeitet wird. Insbesondere im Verhältnis aller Module untereinander. Dies wird durch die Multi-Prozessor-Architektur noch verstärkt.

Zum Vergleich: Damals beim WireGate Server gab es damals ein großes Perl-Script, das in einer großen Schleife ausgeführt wurde. Es konnte zwar fremde Module zuladen, aber die grundsätzliche Reihenfolge der Verfahrensschritte - KNX-Pakete empfangen, 1-Wire auslesen, KNX-Pakete senden, war stets gleich, immer in der gleichen Reihenfolge und sehr deterministisch, auch weil es ein Single-Prozessor-System war.


Schwierige Vorhersagbarkeit über die Stabilität und Robustheit von Software

Durch diese Architektur der Microservices im Timberwolf Server in Verbindung mit dem Multitasking-Multiprozessor-System gibt es keine festgelegte oder vorher abschätzbare Reihenfolge mehr.

Das ist sehr viel herausfordernder als man meinen möchte und weil wir das berücksichtigen müssen und auch wesentlich für unsere Abschätzung der Stabilität einer neuen Software ist, sollten wir uns das näher ansehen.

Nehmen wir zur Vereinfachung an, es gibt nur ein Modul für 1-Wire, eines für Modbus, eines für MQTT usw. (tatsächlich sind es mehrere). Ich denke, es ist nachvollziehbar, dass es schon einen Unterschied macht, ob ein 1-Wire-Sensor alle fünf Minuten abgefragt wird oder 10 Sensoren alle 30 Sekunden. Weil im letzteren Fall benötigt es durchschnittlich mehr Rechenzeit (genauer, punktuell alle 30 Sekunden). Tatsächlich kommt es aber auch darauf an, ob nun ein Ziel-Objekt verknüpft ist mit einem Sensor oder mehrere. Oder Berechnungen angestellt werden. Oder Filter. Das dann auch mit Modbus, MQTT und allem anderen.

Jedes Modul tut zwar seine Aufgaben für sich das, was es tun sollte, aber im Verhältnis zu anderen Modulen weitestgehend unabhängig. Dennoch verarbeiten mehrere Module gleiche Daten parallel (weil z.B. mit gleichen Objekten verknüpft) oder sind zu mehreren an der Verarbeitung der selben Daten beteiligt und müssen teils in der richtigen Reihenfolge bzw. im Rahmen eines gewissen Timings zusammen arbeiten. Allerdings ist gar nicht vorhersehbar, welcher Teil des Programmcodes von welchem Modul (und auch vom OS) zu welchem Zeitpunkt und in welcher Reihenfolge im Prozessor (genauer in welchem Kern) durch diese asynchrone Parallelisierung abgearbeitet wird.

Tatsächlich können einzelne Prozesse deshalb andere "überholen" und dies KANN dazu führen, dass Module zeitlich unpassend zusammenarbeiten. Dieses Problem hatten wir mit Einführung des 3500er, weil einzelne Prozesse plötzlich deutlich schneller abgearbeitet wurden. Auch die Einführung der 10-fach schnelleren SSD im 3500XL hat erneut zu einem anderen Timing geführt, wodurch wir die Software anpassen mussten, indem Funktionen eingebaut wurden, mit denen die Module sich gegenseitig bremsen bzw. untereinander informieren oder eben dagegen robust gemacht werden, wenn Daten zu anderen Zeitpunkten kommen, als vorgesehen bzw. bislang getestet.

Bei jedem einzelnen Timberwolf Server läuft die Software anders und völlig individuell. Zum Teil völlig anders. Der eine hat 100 Stück 1-Wire Sensoren mit 20 verschiedenen Taktzeiten, der andere dafür mehr KNX Objekte die beliebig eintrommeln, der dritte Server mehr Modbus, ein anderer ganz viel MQTT. Und jede beliebige Mischform. Die Unterschiede in der Abarbeitung von Software dürften von Server zu Server teils extrem sein.

Dieses "nicht deterministische Rechnen" der Software ist ein großes Problem für die Vorhersage hinsichtlich Stabilität und Robustheit einer neuen Software. Das Problem wird noch verstärkt, weil die Software für die verschiedenen Architekturen 32/64 Bit und Intel/ARM GANZ ANDERS kompiliert wird und auch im Prozessor anders rechnet. Es werden schon die Daten in einer anderen Reihenfolge im Speicher abgelegt (Big Endian vs. Litte Endian), die Prozessoren haben unterschiedliche Fähigkeiten hinsichtlich der Op-Codes (CISC vs. RISC), andere Fähigkeiten der Co Prozessoren und die Kernels unterscheiden sich dann auch noch. Von der unterschiedlicher Hardware der Interfaces noch gar nicht sprechen.

Dieses "nicht deterministische Rechnen" der Software ist eine große Herausforderung für Vorhersage und Test der Stabilität und Robustheit einer neuen Software. Deshalb geht es nicht ohne langwierige Tests und hier reden wir von hunderttausenden bis Millionen Betriebsstunden einer Software, bis man eine halbwegs statistisch gesicherte Aussage treffen kann.

Zu diesem Thema haben sich schon viele Leute den Kopf zerbrochen, es gibt unzählige Bücher und Abhandlungen und man könnte sicherlich seitenlang darüber schreiben. Dies soll nur ein kurzer Abriss sein, um Euch zu zeigen, welche Herausforderungen sich durch leistungsfähige Architekturen auf Multi-Prozessorsystemen mit Multi-Threading-Betriebssystemen ergeben. Leistungssteigerung durch Parallelisierung ist toll, aber auch eine Herausforderung.


Neue Software vs. Upgrade laufender Komponenten

Unsere Architektur spielt dort ihren Vorteil aus, wenn es darum geht, neue Software hinzuzufügen. Weil ein weiteres Modul im System meldet sich dort an und läuft getrennt von den anderen. Zwar ändern sich auch hier die Verhältnisse untereinander und deshalb muss man das auch testen, aber die Prognose ist dann, wenn sich die Ressourcenbelastung nicht völlig ändert, eher gut und dafür haben wir diese Architektur auch erschaffen.

Das sieht aber GANZ ANDERS aus, wenn eine bestehende Komponenten, die bei vielen Kunden bereits im Einsatz ist, im laufenden Betrieb und bei beliebiger unterschiedlicher Konfiguration ausgetauscht werden soll. Im laufenden Betrieb! Hier müssen wir als Hersteller maximale Vorsicht an den Tag legen, weil ein schlechtes Upgrade kann tausende Server über Nacht lahmlegen. Genau davor wollen wir unsere Kunden und uns selbst auch schützen.

Dies ist der Punkt, um den es in diesem Beitrag eigentlich geht, wir kommen nun zum Kern der Probleme mit der V4.


Kritische Updates mit Firmware V4

Was wegen der vielen Diskussionen um die neue VISU übersehen wird ist, dass wir mit der Firmware V4 drei krasse Veränderungen vorgenommen haben, die für die Stabilität und Robustheit als kritisch einzustufen sind (was für die Timberwolf VISU als neues Modul übrigens nicht gilt).

1. Neue Betriebssystemkomponenten und Security-Algorithmen

Es wurden mehrere Dutzend Betriebssystemkomponenten einem Upgrade unterzogen, auch weil wir eine Reihe von Bibliotheken für neuere Crypto-Algorithmen benötigt hatten, damit wir mit der V4 die Entschlüsselung von passwortgeschützten ETS6 Dateien umsetzen konnten.


2. Komplett überarbeitete Logikengine (plus Logikmanager)

An der überarbeitenen Logikengine V4 hatten wir bereits seit 2021 gearbeitet. Insbesondere ging es darin um einen enormen Umbau um die Textunterstützung zu ermöglichen, aber auch Verbesserungen hinsichtlich Timing-Themen und auch eine überarbeite Diagnose. Diese Änderungen sind umfassender, als es für die neuen Leistungsmerkmale erscheinen mag.

Ich möchte an dieser Stelle betonen, dass es nichts schlimmeres für einen Automatisierungsserver gibt, als dessen zentrale Logikengine bei Kunden auszutauschen. Jedes Unternehmen macht um soetwas einen großen Bogen, weil das kann alles ruinieren, was man ein Jahrzehnt lang an Vertrauen seitens der Kunden erarbeitet hat. Dagegen ist ein großes OS Update ein Kindergeburtstag. Jeder Kunde hat seine Logik völlig anders konfiguriert und etliche hundert Timer sind aktiv und laufen. So eine Logikengine beim Upgrade im laufenden Betrieb zu stoppen und durch eine andere zu ersetzen, unter Beachtung tausender aktiver Status (die Mehrzahl von "der Status" ist "die Status", mit langem u gesprochen u, als wäre es ein doppel-u) ist extrem fehlerträchtig und sehr kritisch. Dieses ist im Labor nur schwer prüfbar, weil jeder Kunde ganz eine andere Konfiguration hat und auch der momentane Betriebszustand zu jeder Millisekunge ein anderer ist.


3. Stark überarbeitete Cloud-Anbindung wg. IFTTT

Vor IFTTT hatten wir nur eine sehr rudimentäre Cloud-Anbindung für Zertifikatstausch und ein klein wenig Telemetrie sowie Elab ID. Mit IFTTT kam nun der Austausch von Objektveränderungen sowie Regelanassungen in beiden Richtungen hinzu plus einer aufwändigen Authentifizierung.

Dadurch wurde auch das Anmeldesystem im Timberwolf Server komplett überarbeitet und erweitert.

Es gehört zu unserer Vorgehensweise, dass wir bei neuen Firmware-Trains die kritischen Änderungen mit den ersten Insider Versionen ausrollen. Damit diese über den Release-Zyklus am längsten getestet werden.


Test kritischer Upgrades auf Stabilität und Robustheit

Im Prinzip wird das auf der Welt überall gleich gemacht: Tests erfolgen mit möglichst viel Betriebszeit auf vielen verschiedenen Maschinen unter möglichst unterschiedlichen Konfigurationen und auch unterschiedlichen Testern. Wie zuvor beschrieben, läuft Software auf jedem Timberwolf Server in völlig anderer Reihenfolge, mit anderem Timing und anderer Konfiguration und Daten. Die mögliche Bandbreite kann man nicht im Labor austesten, es geht nicht ohne einen längeren Feldtest.


Unsere Entscheidung im Frühjahr 2023

Im Frühjahr haben wir die Entscheidung getroffen, dass wir nicht nur die neue Timberwolf VISU entwickeln, sondern haben auch die - häufig kritisierte - Entscheidung getroffen, dass diese Bestandteil der V4 werden soll.

Für diese Entscheidung gab es diese Gründe:

1. Es war zu diesem Zeitpunkt klar, dass die neuen Leistungsmerkmale der V4 aus IP1 bis IP3 bei weitem nicht unsere Kriterium für Stabilität erfüllen, schließlich waren kritische Komponenten erst kurz vorher (bei der IP3 drei Wochen davor) erstmalig bereitgestellt worden.

2. Wir gingen damals davon aus, dass wir in weniger als einem halben Jahr mit einer ersten Version der VISU fertig werden könnten (allerdings damals noch ohne Kameraüberwachung und vieler weiterer Details, die als Kundenwünsche dann erst im Laufe der Entwicklung dazu kamen).

3. Um das hehere Ziel aus 2. zu erreichen, wollten wir vor allem auch effizient sein und deshalb einen wochenlangen Freigabeprozess mit etlichen IPs und RCs einsparen. Wer sich an die V 3.5 erinnert, dort hat der Releaseprozess - von nahezu Featurecomplete bis alles fein und robust - sich fast über ein halbes Jahr gezogen.

Getäuscht haben wir uns beim Aufwand für die VISU. Aber unsere kritische Einschätzung zur Robustheit und mangelnden Reife der Änderungen aus IP1 bis IP3 haben sich als richtig erwiesen. Wir sind im Nachhinein sehr froh, das wir hier vorsichtig geblieben sind.

Sehen wir uns das näher an.


Probleme mit der Logik aus der IP2

Fehler in der Logik-Engine

Wie sich im Laufe des Jahres 2023 gezeigt hat, führten die Änderungen an der Logik-Engine - durchaus erwartungsgemäß, daher testen wir ja ausführlich - zu heftigen Problemen. Wir waren konfrontiert mit einer Reihe kleiner, aber wegen schwieriger Reproduzierbarkeit, auch nerviger Fehler. Insgesamt mussten wir mit den unermüdlichen Testern - an dieser Stelle geht ein fettes Dankeschön an die Power-Tester raus - fast ein halbes Dutzend Versionen der Logikengine ausrollen und testen. Die Problemfelder waren hierbei zeitabhängige Logiken und Probleme mit Aufzeichnungen im Doktormodus nach Erzeugung nicht darstellbarer Zahlen durch fehlerhafte Logikmodule (insbesondere Custom Logiken). Ausgerollt wurden diese ganzen Überarbeitungen der Logik erst mit der IP 5 an die Insider am 21. Dezember 2023.

Manche dieser Fehler waren kritisch. Wir sind ziemlich froh, dass es die ursprünglich mit IP 2 veröffentlichte Logik Engine nicht in eine freigegebene Hauptversion geschafft hat. Wir suchen derzeit übrigens noch einen weiteren Timing-Fehler, der bei einem Tester auftritt, sich aber bislang nicht fassen läßt. Also so ganz durch sind wir mit der Logik Engine, 14 Monate nach dem erste Rollout noch nicht. Diese lange Zeit liegt nicht daran, dass wir schlecht arbeiten, sondern die Fehler waren teils schwer greifbar und sind in den Labortests seit 2021 nicht aufgetreten und im Feld auch nur bei etwa 5% der Tester.

Wir man an diesem Beispiel sehen kann, ist die Überarbeitung einer Logik-Engine nicht nur aus grundsätzlichen Erwägungen her als kritisch zu bewerten, sondern in der Realität auch tatsächlich und die Tests dafür, um diese Fehler zu finden und nach dem Patch anschließend sicherzustellen, dass solche Änderung einer zentralen Komponente auch im laufenden Betrieb erfolgen kann und unter allen Umständen beim Kunden funktioniert, ist tatsächlich durchaus langwierig. Schließlich beginnt die Testzeit nach jeder Patch, also jeder neuen Version wieder erneut.

Zusammengefasst: Am 16. Dezember 2022 haben wir die Logik Engine V4 aus 2021 mit der IP2 an die Insider Tester herausgegeben und letztlich dauerte es ein volles Jahr, bis wir nach einem halben Dutzend Überarbeitungen und erneutem Tests von einer praktisch fehlerfreien Logikengine ausgehen. Wobei es kein Fehler ist, dass diese neue Logik-Engine noch ein paar Monate bei Insidern läuft bis diese in einer freigegebene Hauptversion landet.


Was wäre wenn - Wann hätte es V4 ohne VISU gegeben

Manche Kunden kritisieren, dass die V4 ohne der Verbündelung mit der VISU viel früher herausgekommen wäre. Manche meinen, bereits im Frühjahr 2023. Das wäre auf keinen Fall so gewesen.

Denn die vorgenommenen Änderungen an der Logik hatten wir als potentiell kritisch eingestuft und es gab parallel dazu auch noch den Anmeldebug, der Mitte Januar 2023 aufgetaucht war. Für diesen konnten wir nie eine klare Ursache finden, im Labor nicht nachstellen und mussten nach Vermutung patchen und deshalb war dafür eine lange Testperiode bei den DEV-Testern nötig, wobei das Problem war, das der Fehler in dieser Gruppe vorher kaum aufgetreten war.

Die letzten großen Fixes zur Logik hatten wir im Dezember mit der IP5 ausgerollt. Hätten wir dem Rollout einer V4 die maximale Prio eingeräumt, dann hätten wir den Logik-Fixe wahrscheinlich bereits im Sept. bis Nov. an die Insider rausgegeben. Allerdings hätte man auch danach noch eine Zeit verstreichen müssen mit Test auf mehreren hundert Insider Servern, bis wir uns damit gut gefühlt hätten.

==> Vermutlich hätte es demnach eine V4 im zwischen Okt. bis Dez. 2023 gegeben (wenn wir diese nicht von vorneherein mit der VISU gebundelt hätten).


Wo wären wir mit der VISU heute (bei V4 ohne VISU)?

Was wäre wenn wir uns nicht entschieden hätten, die VISU in V4 aufzunehmen und hätten die V4 separat ausgerollt. Wo wäre wir dann mit der VISU heute?

Es ist schon anzunehmen, dass ein zwischenzeitliches Release der V4 vor der VISU uns hinsichtlich Entwicklung der VISU ziemlich aufgehalten hätte.

Denn die V4 wird auch etwa drei Dutzend Patches und Verbesserungen an anderen Subsystem enthalten, die alle auch entwickelt werden müssen und erhält auch ein neues Lizenzkontrollsystem. Der Punkt ist, die Hälfte dieser Dinge haben wir noch nicht, weil wir daran derzeit - parallel zur VISU - arbeiten. Hätten wir die V4 aber ohne VISU veröffentlicht, dann hätten wir alle diese Arbeiten schon vorher erledigen müssen, da es unsere Arbeitsweise ist, keine Hauptversion zu veröffentlichen, wenn nicht alle bekannten Fehler erledigt sind. Damit wäre aber im Herbst weniger Zeit für die Arbeiten an der VISU gewesen.

Wir schätzen, dass uns der Prozess der Einarbeitung aller anderen Verbesserungen und Fixes als auch der Test dieser über mehreren IPs und RCs uns in Summe wenigstens sechs Wochen bis wahrscheinlich eher zwei Monate gekostet hätte.

==> Damit würde es damit zum heutigen Zeitpunkt (Anfang Februar) noch keine erste VISU (geschweige denn die dritte Vorabversion) an die Insider geben, weil das Minimum an Funktionen für eine erste Freigabe noch nicht erreicht gewesen wäre.

Mithin hätte es dann zwar eine V4 ohne VISU zu Weihnachten gegeben, aber dann eben keine erste VISU dazu, weil die würde es dann erst so gegen März 24 gegeben haben.


Zusammenfassend

Die Verzögerungen für die Freigabe der V4 liegen NICHT alleine an der Entscheidung, die VISU noch in die V4 zu integrieren, weil es parallel dazu ein größeres Problem mit der Logik und den Anmeldebug gab. Mitte Januar 2024 war klar, dass es lange dauern würde, bis die anderen Leistungsmerkmale der V4, vornehmlich die neue Logik Engine, durch den Reifeprozess sind und der Anmeldebug war auch gerade frisch aufgetreten.

Wir denken zwar, dass es ein Fehler war, die VISU mit der V4 zu bundeln, aber wenn wir das Entwicklungsjahr 2023 Revue passieren lassen, dann wäre es zur Veröffentlichung der V4 auch ohne VISU erst spät im Jahr geworden.

Wie wir heute wissen, ist die V4 ab der IP5 von Weihnachten außerordentlich stabil und das hat sich auch mit IP6 und IP7 bestätigt, es gab nicht ein Problem damit.

==> Alle diejenigen, welche unbedingt Leistungsmerkmale aus der V4 benötigen, die bereits als Insider Preview ausgerollt sind, können diese gerne nutzen, es wird keine Probleme geben. Wer dafür eine Interim Insider Lizenz benötigt, soll an service at elabnet dot de schreiben.

Diejenigen Kunden, welche gerne die die anderen Leistungsmerkmale der V4 ohne VISU gehabt hätten, können ab sofort als Interims Insider diese Funktionen mit gutem Gewissen nutzen, bitte einfach schreiben. Es tut uns leid, dass Uhr einige Monat verloren habt.

Alle diejenigen Kunden, welche die VISU nutzen wollen profitieren von der Zusammenlegung, weil damit die VISU schnellstmöglich (wenn auch später als gedacht) verfügbar war. Zudem stehen die anderen Leistungsmerkmale der V4 auch zur Verfügung, spätestens mit der V5 zu Weihnachten sind wir auch sehr stabil mit der Insider. Nur ein paar Features und ein paar Fixes fehlen noch (das sind nicht Fehler die mit der V4 kamen, sondern noch in der V 3.5.1 enthalten waren, man verschlechtert sich also keinesfalls mit der Insider Version)


Lessons learned

Die Änderungen an der Logik haben wir auf Kundenwunsch vorgenommen. Die Änderungen waren zwar wichtig, aber wenn wir sehen welcher Arbeitsaufwand insgesamt hinter dem Rollout einer so stark umgearbeiteten Logik Engine steht, muss man schon überlegen, wie man das künftig angeht. Für das Monsterprojekt VISU gilt das ebenso, hier hatten wir als neues Modul zwar weniger Testaufwand weil nicht kritisch, aber dafür sehr viel Programmieraufwand, weil alles von neu auf zu erschaffen war.

Künftig werden wir große Projekte für die übernächste oder überübernächste Version einphasen, so dass sich diese nicht mehr bremsend auf ein Release mit schon fertigen Funktionen auswirken können.

Deshalb gibt es dann künftig - nach der V4 - auch zwei bis drei Hauptversionen im Jahr und ca. 20 Insider Versionen. Die Brötchen sind dann kleiner, aber viele Brötchen übers Jahr sättigen mehr, als der große Brotlaib nach einem Jahr.


Wann kommt das Release der V4

Damit kommen wir wieder zum Anfang des Artikels zurück: Es ist eine Frage der Entscheidung.

- Stabilität: Hier sieht es sehr gut aus, es gibt derzeit keine signifikanten Stabilitätsprobleme. Die Installation funktioniert und die fertigen Leistungsmerkmale auch.

- Fixes: Wir schätzen, dass wir noch ein bis zwei Dutzend Fixes entwickeln müssen, quer über alle Subsysteme, um alles was gemeldet wurde oder uns selbst bekannt ist, zu beheben. Das sind allesamt keine kritischen Fixes, aber wir wollen es erledigt haben. Das wird mehrere Mannwochen inkl. Dev-Tests und Insider Previews beanspruchen. Man kann das an den derzeitigen IPs sehen, die zwar in der Hauptsache neue VISU Funktionen bereitstellen, aber eben auch Enhancements und Fixes an allen anderen Subsystemen.

- VISU: Grundsätzlich funktioniert die VISU bereits sehr gut, es gibt keine größeren Fehler. Aber es fehlt noch die Mapping-Funktion für nicht boolesche Ausgangswerte und Rückmeldungen und - diese bauen darauf dann auf - noch eine Reihe von weiteren Widget-Varianten, zudem wollen wir die Kameraintegration noch auf mehrere Kameratypen ausweiten.

- Streichliste: Da wir sobald als möglich die V4 nun herausbringen wollen, müssen wir womöglich ein paar einzelne Punkte streichen und auf nachfolgende Releases verschieben, die dafür aber auch schnell kommen sollen. Man muss dann eben auch einen Schnitt machen, weil man kann auch ewig programmieren und genau das ist, was wir nicht mehr tun wollen. Mehr Brötchen anstatt eines großen fetten Brotlaibes. Daher dann auch einen Cut. Wir wollen uns jetzt hier aber nicht festlegen, weil das muss man immer auch im Verhältnis zum Aufwand entscheiden und manche Dinge hängen auch technisch zusammen.

Einen genauen Termin kann ich nicht geben, weil es sind noch mehrere Dutzend kleinerer und mittlerer Punkte zu erledigen, bis alles fein und rund ist. Dazu gehören auch Hilfetexte usw.


Ich hoffe, ich konnte Euch einen interessanten Einblick geben, wie Entscheidungen für ein Release - hier am Beispiel der V4 - getroffen werden und welchen enormen Einfluss kritische Upgrades auf den Zeitverlauf nehmen. Weil Qualität kann man nur ersetzen durch bessere Qualiät und da wollen wir keine Abstriche machen. Wer für sich ausgesucht hat, dass er nur freigegebene Hauptversionen erhalten möchte, möge bitte dafür Verständnis aufbringen, dass der nötige Freigabeprozess sich nicht nach den Wünschen richtet, sondern den technischen Möglichkeiten in einem ziemlich komplexen System und durchaus langen Testreihen unterliegen kann. Dafür kann man sich auf eine freigegebene Hauptversion dann auch verlassen.


lg

Stefan

[thtrp]

Hallo Stefan,

danke für diesen Einblick in eure Vorgehensweise und auch die Erläuterung einiger systemspezifischer Herausforderungen bei euch.

Auch die explizite Aufschlüsselung übergeordneter bzw. grundlegender Anforderung abseits der reinen Funktionalität ist für "nicht-Software"-Menschen sicherlich ein relevanter Einblick. Auch wenn es wie ein Allgemeinplatz klingen mag, erlaube ich mir zusätzlich zu ergänzen, dass viele Aufwände in Innovation (Wie erreiche ich, dass das System das nun tut?) und im Testen bzw. der Stabilisierung liegt (Was muss ich noch tun, damit das System nicht nur im best-case, das tut, was ich will, sondern auch in möglichst allen anderen Fällen?). Oftmals nimmt der eigentliche funktionale Code weniger Platz ein, als das Abfangen von Ausnahmen oder verhindern von Fehlern.

Kurz ging es mir durch den Kopf auch eigene Erfahrungen beim Thema Versions-/Releasemanagement zu schildern (wir haben uns irgendwann von Semver verabschiedet), aber ich halte mich - teils im Sinne der Siebe des Sokrates - zurück, da ich zu wenig über eure Entwicklung und eure Struktur weiß und in einem anderen fachlichen Umfeld unterwegs war.