Seit kurzem haben wir in der NZZ die Rolle des Release Managers eingeführt. Im folgenden Artikel möchte ich erklären warum.

Situation ohne die Rolle des Release Managers

Wir sind mit 12 Entwicklern nach vor ein eher kleines Team. Wir arbeiten schon seit rund 2 Jahren mit Scrum und das funktioniert soweit ziemlich gut. Wir haben schon einige Rollen definiert, wie zum Beispiel Entwickler, Architekt, Reviewer usw. Unsere Sprints dauern 2 Wochen und wir releasen normalerweise jeweils auch alle 2 Wochen eine neue Version unserer Produkte (ausser es gibt irgendwelche Hotfixes).

Unser Ablauf gestaltete sich bis anhin inetwa folgendermassen:

• Ein Entwickler erledigte ein Ticket
• Falls es spezielle Dinge für die Installation/Release zu beachten gab, musste der Entwickler einen Tab mit Release Notes befüllen
• Unser interner Supporter sammelte am Ende des Releases die Release Notes, packte das ganze in gemeinsame Release Notes und unser Hoster installierte dann alles gemäss diesen Release Notes
• Falls es während der Installation (zuerst Staging, dann Produktion) Probleme gab, wurde in unserem gemeinsamen Chat gefragt, ob jemand das Problem lösen konnte

Wie ihr euch sicher vorstellen könnt, lief das teilweise ein bisschen unkoordiniert/unkontrolliert ab. Wir hatten immer wieder mal das Problem, dass sich niemand bzw. alle um ein Lösung gekümmert haben (Wie es halt ist, wenn man im allgemeinen Chat fragt: “Könnte jemand bei dem und dem helfen”.

Wir haben die Situation in der Retrospektive erkannt und versuchten eine Lösung für das Problem zu finden. Das Resultat war, dass wir die Rolle des Release Managers einführten.

Definition des Release Managers

• Hat Verantwortung für einen Release
• Jeweils ein Senior Entwickler übernimmt pro Release die Rolle des Release Managers (alternierend)
• Release Notes werden am Ende eines Sprints zusammengestellt und auf Konsistenz geprüft
• Es werden Schritt für Schritt Anleitungen anhand der Release Notes für den Hoster zusammengestellt
• Tickets und Commits werden überprüft und mögliche Probleme identifiziert z.B.
  • DB Updates, die sich gegenseitig beissen könnten
  • Reihenfolge bestimmen, wie die Projekte installiert werden sollen
• Während der Installation ist der Release Manager Ansprechperson bei technischen Fragen/Problemen
• Bei neuen Erkenntnissen (z.B. auf Staging) werden die Release Notes aktualisiert
• Bei Problemen ist der Release Manager der Koordinator (er muss das Problem nicht selber lösen, aber die Problemlösung koordinieren)
• Ist der Release live, ist der Release Manager auch verantwortlich bei produktiven Problemen die Erstellung von Hotfixes zu koordinieren.

Vorteile

• Pro Release eine verantwortliche Person
• Der Release ist aus technischer Sicht konsistent btw. konsistenter
• Es werden keine Ressourcen verschwendet, da der Release Manager auch gleichzeitig Koordinator bei Problemen ist

Fazit

Seit wir die Rolle des Release Managers eingeführt haben, laufen die Releases insgesamt deutlich koordinierter und ruhiger ab. Gleichzeitig gibt es auch weniger Probleme bei der Installation (Die Anzahl Bugs pro Release kann der Release Manager leider nicht beeinflussen). Für uns hat sich die Rolle und wie wir sie interpretieren bewährt und wir werden in Zukunft so fortfahren.

Feedback

• Habt ihr eine ähnliche Rolle?
• Was sind seine Aufgabengebiete?
• Glaubt ihr, dass sich der zusätzliche Aufwand lohnt?