Release Management Software - OpenProject

Selbstverständlich verwenden wir als Softwareunternehmen unser eigenes Produkt, um unsere Releases zu planen und zu verwalten. OpenProject-Anwender wissen, dass wir versuchen, häufig zu releasen, um regelmäßig einen inkrementellen Mehrwert zu schaffen. Wie managen wir also unsere Releases und wie funktioniert OpenProject als Release Management Software? Im Folgenden zeigen wir Ihnen einige Aspekte, wie wir unsere Releases planen und umsetzen.

Planung in der Release-Management-Software

Grundlage der Release-Planung

Grundlage für unsere Arbeit in OpenProject ist wie üblich die Arbeitspaketliste. Um unsere Releases zu verwalten, verwenden wir verschiedene Arten von Arbeitspaketen: Release, Epic, Phase, Milestone, Task, Feature, Bug, Idea, Implementation, Documentation, Testing, Code Maintenance. So können wir alles festhalten, was für eine neue Version geplant und erledigt werden muss. Wir beginnen im Planungsprozess von ganz oben nach ganz unten. Fügen Sie Ideen hinzu, machen Sie sie zu Epics, fügen Sie Features und Meilensteine hinzu, planen Sie ein Release usw. Mit der Arbeitspaketliste können Sie jederzeit Arbeitspakete hinzufügen und ändern. Und alle Änderungen und Ergänzungen werden immer in allen Modulen in OpenProject reflektiert.

Auf Basis der Arbeitspaketliste speichern wir verschiedene Ansichten der Arbeitspaketliste, die durch Filter erstellt werden, um bestimmte Informationen schnell überprüfen zu können.

Roadmap

Wir verwenden zwei Roadmaps für das Release-Management. Die erste ist ein Gantt-Diagramm, das die Epics und Releases anzeigt. Auf diese Weise kann der Nutzer den Entwicklungsschwerpunkt von OpenProject nachverfolgen und sehen, wann bestimmte Features geplant sind.

Gantt-Diagramm mit Epics und Releases

Weiterhin verwenden wir das Roadmap-Modul in OpenProject, um den Überblick darüber zu behalten, was für ein Release getan werden muss und was bereits erledigt wurde. Alle Arbeitspakete nach Release werden angezeigt und geben einen genauen und aktuellen Stand der Entwicklung wieder. Abgeschlossene Arbeitspakete werden als durchgestrichen angezeigt. Je näher Sie einem Veröffentlichungsdatum kommen, desto mehr Details zeigt diese Roadmap, da die Anzahl der Arbeitspakete zunimmt.

roadmap 12.21 und 12.3.0 mit individuellen Arbeitspaketen in Listenform

Release Planung

Im Release-Plan halten wir fest, wann die nächsten Releases geplant sind, ohne weitere Details. Er dient dazu, jedem im Team einen schnellen Überblick über den Zeitplan zu verschaffen. Er ist natürlich in das Release Management integriert, da es sich hier um eine Gantt-Diagramm-Ansicht mit eingestellten Filtern handelt.

Arbeitspaket-Liste mit angezeigten Filteroptionen

Entwicklung und Testen in der Release-Management-Software

Ausgehend von der Planung, die fortlaufend ist und ständig angepasst wird, gehen wir in mehreren Iterationen in die Entwicklung über.

Produktentwicklung, Verbesserungen und Bug Fixes

Alle Arbeitspakete durchlaufen einen definierten Prozess von der Spezifikation über die Entwicklung bis hin zum Testen und zum Abschluss. Sie können diese Arbeitsabläufe nach Ihren Bedürfnissen in OpenProject einrichten.

Arbeitspaket-Liste mit Drop-down-Optionen

Während der Arbeit an Funktionen, Verbesserungen und Fehlerbehebungen nutzt das Team die OpenProject-GitHub-Integration. Sie ermöglicht es, die Arbeitspakete mit Pull Requests in GitHub zu verknüpfen, sodass immer die neueste Entwicklung einsehbar ist. In der Detailansicht des Arbeitspakets werden die GitHub-Actions und der entsprechende Pull-Request angezeigt.

Arbeitspaket-Detailansicht mit GitHub Aktionen in Kommentaren

Agile Boards

Manchmal verwendet das Entwicklungs- und Dev Ops Team auch gerne ein agiles Board, um seine Aufgaben zu visualisieren. In diesem Beispiel handelt es sich um eine einfaches Board zur Priorisierung von Arbeitspaketen.

Board mit vier Listen und Arbeitspaketen

QA der Release-Entwicklung

Sobald ein Arbeitspaket seinen Status auf “Merged” geändert hat, beginnt die Qualitätssicherung. Wenn eine Funktion erfolgreich getestet wurde, setzt das QA-Team den Status auf “Tested”. Wenn das QA-Team feststellt, dass eine Funktion nicht gemäß den Abnahmekriterien funktioniert, wird das Arbeitspaket auf “Test failed” gesetzt und an die Entwickler zurückgegeben. Wenn es Fehler gibt, die nicht unbedingt mit den Abnahmekriterien übereinstimmen, wird ein Bug Report erstellt. Wir verfolgen den Status des Arbeitspakets, indem wir nach allen offenen Arbeitspaketen filtern und nach Status sortieren.

nach Status sortierte Arbeitspaketliste

Darüber hinaus verwenden wir eine Arbeitspaketliste um Fehler zu priorisieren.

Arbeitspaket-Liste der Fehler

Release Checkliste

Um sicherzustellen, dass alles abgedeckt ist, verwenden wir für jede Veröffentlichung eine Checkliste. Dabei handelt es sich im Grunde um eine Arbeitspaketliste mit Meilensteinen, die leicht abgehakt werden können. Sie dient quasi als To-Do-Liste. Auf diese Weise stellen wir sicher, dass alle Tests durchgeführt werden, die Kommunikation mit unseren Nutzern vorbereitet ist und alle technischen Aspekte der Bereitstellung des neuen Releases berücksichtigt werden.

Arbeitspaket Release-Checkliste mit Meilensteinen

Überwachung und Verbesserung in der Release-Management-Software

Wir stellen die neueste Version von OpenProject nach umfangreichen Tests zuerst auf der Community bereit. So kann unsere Community die Funktionen zuerst testen, wertvolles Feedback geben und Fehler melden. Danach werden unsere Enterprise-Editionen freigegeben: Wir veröffentlichen das Release für die Enterprise-On-Premises-Version und stellen die Enterprise-Cloud bereit. Wir bieten unseren Enterprise-On-Premises-Kunden Unterstützung beim Upgrade auf die neueste Version. Automatisierte Tests, sorgfältiges Monitoring und Patch-Releases gewährleisten die höchste Qualität unserer Releases.

Unser OpenProject Projekt ist öffentlich verfügbar, zögern Sie nicht, ein bisschen mehr zu durchsuchen oder lesen Sie sich den Release-Prozess in unserer Dokumentation durch.