Blog / #teamShadow / Was ist ein Release-Prozess?
Was ist ein Release-Prozess?

Was ist ein Release-Prozess?

Hier kommt ein Q&A mit unserem Deputy CTO, Arnaud Sourious, in dem wir alles besprechen, was mit unseren Bereitstellungsabläufen zu tun hat.

2. April 2021 zuvor veröffentlicht

Wie versprochen, schreiten wir in dieser Zeit des Übergangs weiter voran. Wer Fortschritt sagt, sagt technologischen Fortschritt, und wer technologischen Fortschritt sagt, sagt Release-Prozess. 

Kommt dir diese Einleitung weit hergeholt vor? Keine Sorge, der Rest des Artikels könnte kaum ernster sein! 

Heute haben wir die Ehre, Arnaud Sourioux alias "Six" willkommen zu heißen. Als stellvertretender CTO weiß er alles, was mit Release-Prozessen zu tun hat. 

Bevor ein neues Update oder eine Bugfix für deinen Shadow erscheint, müssen wir vorher einen ganzen Prozess einrichten und verwalten. Unsere Updates durchlaufen die recht typischen Phasen "Insider", "Alpha" und "Beta", bevor sie in "Prod" (Produktion) übergehen und für alle Nutzer veröffentlicht werden. 

Nun, da du die Grundlagen kennst, lass uns zu unserer Frage-und-Antwort-Runde (Q&A) übergehen, in der wir mehr ins Detail über diese verschiedenen Versionen gehen und dir den ganzen Rest der Prozedur genauer erklären werden:

Q: Wie läuft die Veröffentlichung eines Updates für Shadow ab? Ist das schon immer so gewesen?

Nein, der Prozess war nicht immer so. Wir ändern die Art und Weise, wie wir die Dinge angehen stetig. Vor 2 Jahren, als ich zu Shadow kam, haben wir die Updates bspw. nahezu sofort veröffentlicht, sobald sie fertig waren! 

Dann haben wir versucht, die Versionen zwischen der Anwendung, dem Client, dem, was der Benutzer sieht, und den Diensten in Shadow zu synchronisieren. Wir haben viel industrialisiert und nutzten Tools, die uns dabei halfen, wie z. B. Gitlab.

Dann kam die JB-Ära, in beschlossen wurde, nur noch eine Produktionsversion pro Monat zu veröffentlichen, so dass wir uns jede Woche auf einen anderen Aspekt von Shadow konzentrieren konnten. Zum Beispiel ist Woche 2 eines jeden Monats dem "Client-Anwendungs"-Teil gewidmet, also der Desktop-, Box-, Mobile- und TV-Version. Woche 3 konzentriert sich auf die Komponenten in Shadow: den Streamer und alle Dienste, die Shadow am Laufen halten.

Was die Veröffentlichung eines Updates betrifft: Als erstes müssen wir festlegen, welche Funktionen wir in die erste Version aufnehmen wollen. Was die Fehler betrifft, so beheben wir sie nach und nach, so dass alle Fixes, in dieser Version enthalten sind. Wir entscheiden über unsere Inhalte im Voraus, um sicher zu sein, dass sie enthalten sein werden.

Q: Wofür gibt es die Insider-, Alpha- und Beta-Versionen?

In der Testphase beginnen wir immer damit, unser Update an unsere "Insider" zu versenden. Der Vorteil ist, dass wir ihnen direkt den Code schicken können, den ein Entwickler gerade erstellt hat, wir müssen keine "echte Version" für sie erstellen. Dadurch können sie schon 20 Minuten, nachdem ein Entwickler sie geschrieben hat, auf eine Version zugreifen.

Die Alpha ist ein eingefrorener Code (kein Test), aber wir können ihn 3 Mal pro Tag anpassen.

Für eine echte Beta-Version müssen wir durch eine QA-Phase gehen. Die QA muss alles testen und uns sagen, ob es funktioniert, ob es für die Beta in Ordnung ist, oder ob es aufgrund der gefundenen Fehler nicht akzeptabel genug ist.

Für den Schritt von der Beta zum Offiziellen Release Candidate (öffentliche Version der Shadow App), wird die aktuelle Beta noch einmal gründlich getestet. Wir sind viel strenger bei allen Verhaltensweisen und Fehlern, die während dieser Testphasen gefunden werden.

Diese verschiedenen Versionen werden durchlaufen, um sicherzustellen, dass wir Schritt für Schritt, von Insider über Alpha und Beta hin zum Offiziellen Release Candidate, die Qualität sicherstellen. 

Da wir nicht das gleiche Volumen an Benutzern für jede Phase haben, ist die Auswirkung nicht die gleiche. Wenn wir ein Update oder einen Patch in der Beta-Version senden, sind nur 10 % der Benutzer betroffen, und sie können bei Bedarf zu Alpha oder Prod wechseln.

Q: Wie kommt ein neues Feature von der Insider-Version in die offizielle Version (konkrete Schritte)?

Jedes Mal, wenn eine neue Funktion aktualisiert wird, müssen deren Fertigstellung und das Benutzererlebnis verbessert werden. Die Anforderungen sind in der Alpha nicht die gleichen wie in der Beta oder der offiziellen Version der Shadow App(s).

Zum Beispiel haben wir heute die ARM64 Anwendung für Mac in der Alpha. Sie ist in Alpha, weil es noch nicht alle Funktionen wie bspw. das Quick Menu, Display Management oder andere beinhaltet. Es konnte sehr schnell in der Alpha verfügbar sein, da die fehlenden Features dort kein Problem darstellen. Für die Beta-Version hingegen braucht es ein Minimum an Funktionalitäten. Und für den Offiziellen Release Candidate ist das nochmal ein ganz anderer Schnack.

Q: Gibt es ein festes Datum / Tag für die Releases? Zum Beispiel Freitagabend, weil es Shadow ist?

Wie vorher angesprochen, haben wir 2 Wochen pro Monat in denen wir neue Versionen veröffentlichen. In welcher Woche (2. oder 4. Woche des Monats) etwas veröffentlicht wird, entscheiden wir danach, welche Komponenten wir aktualisieren werden. Je höher der Umfang (Official Release Candidate > Beta > Alpha > Insider), desto mehr wird es am Anfang der Woche veröffentlicht.

Die offizielle Shadow Versionen versuchen wir Montags oder Dienstags zu veröffentlichen. Für Beta Versionen, geben wir uns bis Donnerstags Zeit. Bei der Veröffentlichung unserer Alpha Versionen sind wir weniger streng und veröffentlichen sie möglichst früh. Denn selbst wenn wir sehr schnelles Feedback haben, brauchen wir immer noch Zeit, um Probleme vor dem kommenden Wochenende zu beheben. Denn am Wochenende wird Shadow von unseren Mitgliedern wesentlich mehr genutzt, als unter der Woche. 

Wenn wir ein Update am Montag oder Dienstag veröffentlichen, ermöglicht es uns, die Fehlerbehebungen vor Freitag durchzuführen, wodurch unsere Benutzer eine Beta- oder Official-Version erhalten, die relativ stabil oder frei von den in der Zwischenzeit gefundenen Fehlern ist.

Q: Was ist die größte Herausforderung für das Team, wenn ein neues Update auf den Markt kommt?

Je mehr Teams an der Entwicklung eines Features beteiligt sind, desto schwieriger wird es häufig in der Entwicklung. Denn das erfordert mehr Zusammenarbeit und Synchronisation, welches die Sache schlagartig komplexer macht.

Heutzutage gibt es viele Funktionen, die einfach erscheinen, es aber unter der Haube nicht immer sind. Ein Beispiel:

Wenn wir eine Funktion fürs Quick Menu haben, muss diese in dem Moment, in dem der Benutzer auf das Quick Menu zugreift, von der lokalen Anwendung an den Shadow gesendet werden. Wenn du zum Beispiel die Auflösung im Quick Menu änderst, sendet es die Information an den Renderer, der sie an den Streamer weitergibt. Der Streamer wendet die neue Auflösung an und bestätigt sowohl dem Renderer als auch dem Quick Menu, dass sie korrekt angewendet wurde. Dieser ganze Ablauf, der einem als Anwender sehr simpel erscheint, ist letztlich ein wenig komplexer.

Ein anderes Beispiel wäre ein Feature welches die Virtualisierung und Orchestrierung berührt, wie beim dynamischen Herunterfahren. Hier dauert es gerne mal noch einen Moment länger, weil alle Komponenten in der Lage sein müssen, miteinander zu kommunizieren, damit alles rund läuft.

Q: Warum ist es so kompliziert?

Das Komplizierte ist, ein Bedürfnis des Anwenders tatsächlich technisch umzusetzen. Manchmal ist nicht sofort klar, wie man an die Umsetzung herangehen soll, und so muss man erstmal herausfinden, wie man es macht, wer involviert sein wird und wie lange es dauert. 

Am Ende muss eine neue Funktion nicht nur auf sich allein gestellt, sondern im derzeitigen Gesamtbild und mit möglichen zukünftigen Features funktionieren. Das Ziel ist es, langfristige Lösungen zu finden.

Warum gibt es all diese Schritte und warum kann es so lange dauern? 

Damit es so qualitativ wie möglich sein kann, weil die Nutzer immer anspruchsvoller werden. Als das Produkt zum ersten Mal auf den Markt kam, wussten unsere Mitglieder, dass sie etwas testen, welches noch in der "Ich habe mein Produkt in meiner Garage gemacht"-Phase war. Jetzt, wenn du Shadow bestellst, ist es wie das Abonnement von jedem anderen fertigen Produkts. Entsprechend erwartest du eine ähnliche Qualität.

Zunächst hatten wir nur Insider / Beta / Official, doch wir erkannten, dass wir auch eine eine Alpha-Version benötigen. Das lag daran, dass die gleiche Qualität für die Beta angefragt wurde, die wir für unseren Official Release Kandidaten anlegen. Das war ohne einen weiteren Zwischenschritt schlichtweg nicht möglich.

15 Insider erlaubten es uns nicht das Produkt auf einen Standard zu heben, wie es mit 10% unserer Mitglieder (welche unsere Beta nutzen) möglich ist. Wenn wir heute Bugs in den offiziellen Versionen finden, liegt es häufig daran, dass diese Fehler selbst in der Beta nicht gefunden wurden bzw. wir nicht (genügend) Feedback dazu erhalten haben. Die Anzahl an Testern bzw. Nutzern und deren genutzte Konfigurationen ist hier entscheidend um verschiedenste Fehlerquellen möglichst früh ausfindig zu machen. 

Der schlimmste Fehler der sich in unseren Offiziellen Release Candidate einschleichen kann, ist, dass ein Nutzer den Zugriff auf seinen Shadow verliert. Deshalb versuchen wir, den vorhergehenden Phasen so viel Aufmerksamkeit wie möglich zu schenken.

Q: Hast du eine Gehaltserhöhung verdient? Und was sind deine letzten Worte (für diesen Artikel natürlich)? 

Unsere Teams sind diejenigen, die am meisten Anerkennung und Geld verdienen sollten. Sie sind diejenigen, die den Job machen, wir organisieren einfach alles, was da ist.

Ich denke, wir haben in den zwei Jahren wirklich eine Menge Fortschritte gemacht. Das Team ist gewachsen, weil wir Dinge anders gemacht haben und neue Leute dabei sind. Zwar sind wir manchmal weniger agil und erscheinen langsamer, allerdings haben wir haben an Qualität gewonnen. 

Mit der Veröffentlichung des Dual-Screens (Multi-Screen) noch vor den Winterferien wollten wir zeigen, dass wir auch weiterhin agil arbeiten können und in der Lage sind, großartige Dinge zu tun. Das war für unsere Benutzer genauso wichtig, wie für einige unserer Mitarbeiter!