Vielleicht bist du schonmal über den Begriff “Release Manager” gestolpert und hast dich gefragt, was eigentlich dahinter steckt. Release Manager planen und koordinieren die Veröffentlichung einer Software und führen diese letztendlich auch durch. Das gilt auch für Opencast. Alle sechs Monate wird eine neue Version von Opencast veröffentlicht und das begleiten jeweils zwei Release Manager. Was genau das bedeutet haben wir für dich in diesem Artikel zusammengefasst.
Regelmäßige Software-Releases sind essenziell, um die Sicherheit, Stabilität und Funktionalität der Software zu gewährleisten. Für Opencast bedeutet das also, dass alle sechs Monate eine neue Version released wird. Immer die beiden neuesten Versionen werden parallel entwickelt. Das heißt aktuell bekommen die Opencast Versionen 18 und 19 monatlich kleine Updates, die sogenannten Minor Releases, die dann kleine Verbesserungen und neue Funktionalitäten mit sich bringen. Als nächstes wird Opencast 20 released. Sobald Opencast 20 veröffentlicht ist, bekommt 18 keine weiteren Updates mehr.
Der Vorgang der Releases muss überwacht und geleitet werden. Genau da setzt der Release Manager an - oder um es genau zu nehmen, zwei Release Manager. Denn bei Opencast arbeiten jeweils zwei Release Manager von unterschiedlichen Institutionen zusammen, um eine optimale Qualität gewährleisten zu können und sich ggf. vertreten zu können.
Release Manager bei Opencast sind für circa ein Jahr aktiv. Sie bereiten das Haupt-Release (Major Release) vor, führen dieses durch und kümmern sich im Nachgang um weitere Updates für ihre Version. Zusätzlich kommen organisatorische Aufgaben rund um die Releases auf sie zu wie Koordination und Kommunikation in der Community sowie das Treffen von Entscheidungen bezüglich ihrer Opencast-Version.
Wer Lust hat, die Rolle des Release Managers auszuführen, sollte sich bei Opencast bereits aktiv eingebracht haben und sich auskennen. Da es immer zwei Release Manager pro Version gibt, reicht es jedoch völlig aus, wenn einer der beiden Erfahrung mitbringt. Als zweite Person werden gerne neue Leute aus der Community gefragt, die weniger Erfahrung haben und viel Engagement mitbringen. Release Manager können sich allein oder zu zweit freiwillig für die nächste Version melden - stehen mehr als zwei Release Manager zur Wahl, wird in der Community abgestimmt.
Zumindest einer der beiden Release Manager sollte ebenfalls Committer sein. Committer sind diejenigen Entwickler:innen, die auf dem Repository auf GitHub, wo der Code von Opencast liegt, Schreibrechte besitzen. Nur mit diesen Schreibrechten kann man direkte Änderungen vornehmen bzw. die Änderungsvorschläge von anderen Entwickler:innen (Pull Requests) annehmen. Wer für die Rolle eines Committers infrage kommt, muss von einem anderen Committer vorgeschlagen werden und durch eine Wahl im Kreis der bestehenden Committer bestätigt werden.
Die Aufgabenbereiche eines Release Managers lassen sich ganz grob in zwei Bereiche aufteilen: Zum einen kümmert er sich um das Major Release, also die Veröffentlichung der neuen Opencast Version (die Opencast Releases zum Herunterladen gibt es hier: https://github.com/opencast/opencast/releases) und im Anschluss daran liegen die regelmäßigen Minor Releases in seiner Verantwortung. Zum anderen gehören die administrativen Aufgaben dazu. Wir schauen uns das Ganze mal etwas genauer an.
Die erste Tätigkeit von Release Managern ist üblicherweise die Bekanntgabe der genauen Release Schedule, also der Zeitpunkte für Feature Freeze (siehe weiter unten), Major Release etc.. Diese bewegen sich in einem bestimmten Rahmen, darin ist aber für die Release Manager noch ein gewisser Spielraum enthalten.
Kontinuierlich über die gesamte Zeit der Tätigkeit haben die Release Manager ein Auge auf die offenen Pull Requests für ihre Version. Steht ein PR seit mehreren Wochen offen, muss nachgesehen werden, warum er noch nicht angenommen wurde. Das kann verschiedene Gründe haben: Vielleicht wurden Änderungen gefordert, die noch nicht umgesetzt werden konnten oder es gibt grundsätzliche Unklarheiten oder Bedenken zur Art der Umsetzung. Vielleicht hat sich aber bisher auch einfach niemand für ein Review gefunden. Der Release Manager behält den Überblick über die ausstehenden Pull Requests und kümmert sich um die zeitgemäße Umsetzung dieser - oder eventuell darum, ungeeignete Vorschläge zu schließen. Insbesondere ist es auch Aufgabe der Release Manager, zu entscheiden, ob eine bestimmte Änderung für ihre Version von Opencast geeignet ist. In wichtigen und dringenden Fällen tragen Release Manager auch selbst Patches bei, z.B. um Sicherheitslücken zu schließen.
Zu den Aufgaben zählt auch die Teilnahme am wöchentlichen Dev Meeting. Mindestens einer der beiden Release Manager sollte dabei sein, um den aktuellen Stand durchzugeben, Fragen zu klären und alle auf dem Laufenden zu halten.
Auch in der Öffentlichkeit können und sollen die Release Manager auftreten. Zum Beispiel wird auf dem alljährlichen Opencast Summit üblicherweise ein kurzer Vortrag zur neuesten Version von Opencast, den darin enthaltenen Features, sowie anderem Wissenswerten gehalten. Manchmal werden auch zu Demo-Zwecken Minor Releases live auf der Konferenz erstellt.
Bevor wir zum tatsächlichen Release kommen, werfen wir einen Blick auf den Aufbau des Repositories. Es wird unterschieden zwischen den Branches der aktuellen Versionen, wo aktuell beispielsweise Version 18 (legacy) und Version 19 (stable) liegen. Daneben gibt es den Develop Branch. Im Dev Branch liegt jeweils die nächstfolgende Version (also hier zum Beispiel die Version 20, nach dem Release im Frühjahr dann die Version 21), die nach Belieben angepasst und verändert werden kann. Etwa einen Monat vor Release der nächsten Version passiert der Feature Freeze. Dabei wird die Version, die demnächst veröffentlicht werden soll, vom Dev Branch in einen eigenen Branch abgespalten und sozusagen “eingefroren“. In diesem Branch dürfen ab dem Moment keine gravierenden Veränderungen mehr erfolgen, damit nichts mehr kaputt geht.
Die Phase zwischen Feature Freeze und Release soll von der Community genutzt werden, um die neue Version zu testen und ggf. noch Bugfixes durchzuführen. Dafür stehen die Testserver develop.opencast.org, stable.opencast.org & legacy.opencast.org zur Verfügung. Hier laufen jeweils die beiden aktuell supporteten Versionen und die zukünftige Version (develop=20) mit ihrem letzten Stand.
Nach dem Feature Freeze erfolgt die Übersetzungsphase. Opencast ist in verschiedenen Sprachen verfügbar. Alle neuen Features und Funktionen müssen ebenfalls übersetzt werden, bevor sie veröffentlicht werden. Neue Sprachen müssen zu mindestens 80 Prozent übersetzt werden, um Einzug in Opencast zu erhalten. Für Übersetzungen ist das Projekt auf Freiwillige angewiesen, die der jeweiligen Sprache mächtig sind.
Nun kann also das Release erfolgen. Zusätzlich zum Hauptrepository müssen neue Versionen für die Nebenprojekte Admin UI und Editor erstellt werden und diese im Opencast-Repository eingetragen werden. Dieser Prozess ist heutzutage größtenteils automatisiert.
Dann testen die Release Manager zunächst die Version lokal nochmal, bevor sie sie auf Github veröffentlichen. Für die häufigsten Linux-Betriebssysteme wie Debian und Red Hat werden zusätzlich entsprechende Pakete erstellt. Außerdem wird die Dokumentation veröffentlicht: Während im Changelog alle Änderungen enthalten sind, fassen die Release Notes die wichtigsten geänderten Konfigurationen und neue Features zusammen. Diese Informationen können hier eingesehen werden: docs.opencast.org. Jedes neue Release wird außerdem automatisch mit Erscheinen im Matrix-Channel der Community angekündigt.
Mit dem Release der Version 20 fällt Version 18 aus dem Support-Fenster, sodass dann nur noch die drei Versionen 19 und 20 Updates bekommen. Der Dev Branch ist dann die Vorlage für Version 21, die in weiteren sechs Monaten released wird.
Und auch nach dem großen Release der neuen Version ist für die Release Manager noch lang nicht Schluss. Etwa einmal im Monat stehen Minor Releases an, um weitere kleine Funktionen zu ergänzen, Fehlfunktionen auszusortieren und Opencast stets aktuell zu halten.
Dabei ist es praktisch, wenn sich beide Release-Manager-Paare zeitlich aufeinander abstimmen, um zuverlässig alle Änderungen für die älteste noch supportete Version (legacy) in die neuere Version (stable) zu übernehmen. Das bedeutet: Alle neuen Änderungen aus z.B. der Version 18.8 sind auch in der Version 19.2 enthalten.
Das Ganze läuft bis zum Ende der Version, die die Release Manager betreuen. Für die Release Manager der Version 20 heißt das: Dienst bis circa Mai 2027. Denn die Version 20 läuft ab dem Release nicht nur sechs Monate, sondern parallel zur Version 21 nochmal sechs weitere Monate. Für die letzten 6 Monate gelten für die Version, die nun als legacy gilt, nochmal rigidere Regeln für neue Änderungen, um das Produkt möglichst stabil zu halten und das Auftreten von neuen Problemen zu vermeiden.
Neue Release Manager werden alle halbe Jahre meist verzweifelt gesucht, obwohl die eigentliche Tätigkeit häufig gar nicht so viel Zeit in Anspruch nimmt. Gerne fassen euch auch andere Community-Mitglieder unter die Arme, wenn ihr euch unsicher fühlt. Also traut euch. 😉
Der elan e.V. hat in der Vergangenheit bereits häufiger Release Manager gestellt, aktuell z.B. für Opencast 18 und 20. Wir unterstützen unsere Mitarbeitenden in der Community-Arbeit, weil wir wissen, dass genau das die Basis unserer gesamten Arbeit bildet. Gleichzeitig fördern unsere Kunden diese Arbeit über die Communitybeiträge in ihren Verträgen. Dafür bedanken wir uns. 🙂
