© Julien Chiari| 123RF.com

Open Project integriert Github in sein Projektmanagement. Seit der im März erschienenen Version 13.4 lassen sich Planung, Priorisierung und Pull Requests direkt aus dem Versionskontrollsystem im Projektmanagement verwalten.

Die Vorteile von Open-Source-Projekten liegen oft auf der Hand, doch nicht immer gibt es handfeste Beispiele, die sie auch in der Praxis belegen. Wenn dann allerdings eine Community-Entwicklung, vielleicht sogar eine, die auf Eigeninitiative eines einzelnen Entwicklers zurück geht, ihren Weg in den Mainstream großer OSS-Projekte findet, erregt das Aufsehen.

Genau das passierte im Fall von Open Project und Gitlab. Benjamin Tey (Btey, [1]), ein erfahrener Open-Project-Entwickler und Git-Experte, hatte vor drei Jahren damit begonnen, die beiden Open-Source-Projekte miteinander zu verheiraten – und damit durchschlagenden Erfolg. Der Hersteller von Open Project [2] war schnell begeistert von der Idee, half und lobt Teys Arbeit heute noch in den höchsten Tönen. “Dieser Beitrag der Community verkörpert die Essenz von Open Source – gemeinschaftliche Entwicklung, kontinuierliche Verbesserung und geteilte Innovation”, schwärmt Niels Lindenthal, Gründer und Geschäftsführer der OpenProject GmbH. Man habe auf der “hervorragenden Arbeit von Benjamin Tey aufgebaut und das Plugin weiter verbessert”, indem man automatische Tests und einen Migrationspfad hinzugefügt habe. Die Integration des Gitlab-Plugins direkt in den Kern von Open Project bringe vor allem für Entwicklungsteams deutliche Vereinfachungen.

Die nach eigener Aussage “führende freie und quelloffene Projektmanagementsoftware” bezeichnet die Gitlab-Integration in seine Version 13.4 als einen Meilenstein, der “DevSecOps mitten hinein in unsere Kernfunktionalität bringt”. “Nahtlos integriert” sei nun die Koordination zwischen Projektmanagement und Softwareentwicklung, die Planung und Spezifikation von Softwareprojekten noch enger mit dem Entwicklungsprozess verbunden. Wer das testen will, greift am besten zu Debian Bookworm, das inzwischen schon die Version 13.4 mitbringt (Abbildung 1).

Abbildung 1: Auch schon in Debian Bookworm: Die Ende März erschienene Open-Project-Version 13.4 bringt die Gitlab-Integration samt Konfigurationshilfe »openproject reconfigure«.

Ein wenig Vorsicht ist jedoch geboten: Wer bereits vorher schon das Community-Modul von Btey nutzte, sollte die Modulkonfiguration entfernen, bevor er auf die neue, fest eingebaute Version umsteigt. Die “historischen” Daten von vorher bleiben dabei allerdings erhalten, nur die Anbindung muss der Admin erneut vornehmen – das Datenmodell hat sich nicht verändert.

Besserer Überblick dank Gitlab

Die Gitlab-Integration erlaubt es allen Entwicklern und Beteiligten eines Softwareprojekts, in einem eigenen Modul den Gesamtstatus von Softwareentwicklungsprojekten zu verfolgen – von der anfänglichen Planung und Priorisierung von Anforderungen hin zur Ausführung von Pull Requests in Gitlab. Dem Anwender zeigt Open Project eine eigene Registerkarte in der Detailansicht des Arbeitspakets mit allen Aktivitäten, die auf Gitlab stattfinden und mit dem Arbeitspaket in Verbindung stehen (Abbildung 2).

Abbildung 2: Eine eigene Registerkarte zeigt die Funktionen der Gitlab-Integration in Open Project.

So können Sie Verknüpfungen zwischen Open Project und Gitlab in beide Richtungen erzeugen: beispielsweise Branches, Merge-Requests und Issues in Gitlab in und mit Arbeitspaketen in Open Project verwalten, bestehende Merge-Requests in Gitlab automatisch mit der Arbeitspaket-ID aus Open Project kennzeichnen lassen, den Status Update der Merge-Requests überwachen und direkt aus Open Project zu ihnen in Gitlab navigieren sowie den Status Ihrer Gitlab-Pipelines anzeigen lassen, zusätzlich zur Integration der Pull Requests.

Eine eigene Registerkarte für Gitlab

Open Project präsentiert Ihnen auf einer Registerkarte sämtliche mit einem Arbeitspaket verknüpften Merge Requests inklusive deren Status (“Bereit” oder “Merged”) und Zustände (“Erfolg” oder “In der Warteschlange”) der für Merge Requests konfigurierten Gitlab-Aktionen (Abbildung 2). Ein Arbeitspaket kann dabei mit mehreren Merge Requests verknüpft sein, genauso kann ein Anwender Merge Requests mit mehreren Arbeitspaketen verknüpfen. Open Project hilft Ihnen aber ebenso beim Branchen und liefert die Informationen beim Öffnen, Mergen und Schließen der Requests. Abbildung 3 zeigt das im praktischen Einsatz für das Opendesk-Projekt des ZenDiS [3], Abbildung 4 den Überblick eines laufenden Projekts (MR steht dabei für Merge Request, also quasi Pull Requests).

Abbildung 3: Die Integration geht in beide Richtungen: In Open Project kann der Verantwortliche jetzt jederzeit nachvollziehen, was im Git-Repository vor sich geht.

Abbildung 4: Gleichzeitig kann der Verantwortliche aber auch über die Strukturen des Projektmanagements von Open Project auf die Daten zugreifen.

Möchten Sie das bewerkstelligen, müssen Sie sowohl Open Project als auch Gitlab für die Integration vorbereiten. In Open Project braucht es einen Anwender mit der Berechtigung, Kommentare zu erzeugen – das wiederum benötigt nur zwei Freigaben: Arbeitspakete zu betrachten und Notizen hinzuzufügen. Beides findet sich unter Rollen und Berechtigungen in der Sektion der Arbeitspakete beziehungsweise Ganttcharts. Allerdings müssen Sie den Nutzer zu jedem Projekt hinzufügen, das es anzubinden gilt.

Abbildung 5: Nur zwei Berechtigungen aus der langen Liste von Open-Project-Projektrollen spielen für die Gitlab-Integration eine Rolle.

Gitlab erwartet dafür ein API-Token von Open Project, das Sie über einen eigenen Dialog für Zugangstoken in den Account-Einstellungen des Gitlab-Benutzers bekommen. Den so erhaltenen Key sollten Sie sofort sichern, er lässt sich nicht erneut abfragen. Brauchen werden Sie ihn später zum Konfigurieren des Webhooks in Gitlab. Jetzt müssen Sie das Gitlab-Modul in den Projekteinstellungen aktivieren, und schon erscheinen alle Informationen aus Gitlab ebenso in Open Project. In Letzterem braucht schließlich noch jeder Nutzer, der diese Informationen angezeigt bekommen muss, die Erlaubnis dazu: Nur wer die Freigabe Show GitLab Content hat, sieht auf dem Gitlab-Tab Inhalte. Idealerweise vergibt der Admin diese Erlaubnis gleich an alle Rollen im System, die den Zugriff benötigen, und spart sich so später Arbeit.

Auf der Gitlab-Seite ist ein Webhook zu aktivieren, über den Sie die Software mit dem API-Key mit Open Project integrieren. Das gelingt unter Einstellungen | Webhooks | Neuen Webhook hinzufügen. Es empfiehlt sich bereits hier, die SSL-Überprüfung in den Netzwerkeinstellungen zu aktivieren, bevor Sie den Webhook hinzufügen.

Die für den Webhook nötige URL muss auf den Open-Project-Server zeigen, aber ergänzt mit »/webhooks/gitlab?key=« und dem zuvor erhaltenen API-Key.

https://myopenproject.com/webhooks/gitlab?key=4221687468163843

Wer Events über den Webhook triggern lassen will, muss das explizit erlauben. Möglich ist das für Push Events, Kommentare, Issues, Merge Requests und Pipeline Events. Arbeiten Sie außerdem in einem lokalen Netzwerk, müssen Sie das der Gitlab-Instanz ebenso mitteilen. Genauer gesagt müssen die Netzwerkeinstellungen im Administrationsbereich erlauben, ausgehende Requests ins lokale Netz zu schicken.

Die Gitlab-Integration benutzen

Um jetzt einen Merge Request zu erstellen, können Sie den dafür notwendigen Branch in Open Project erzeugen. Ihn finden Sie im Gitlab-Tab des Arbeitspakets unter Git Snippets. Von dort kopiert, landet der neue Branch Name per Copy and Paste im Git-Client Ihrer Wahl – schön organisiert und einheitlich benannt nach der Logik, die das Projektmanagement von Open Project vorgegeben hat.

In den Git Snippets bietet Open Project darüber hinaus bereits vorgefertigte Commit Messages an, die den Titel und die URL des Arbeitspakets einbinden. Gitlab wird die erste Commit Message eines Branches für den Vorschlag einer Branch-Beschreibung verwenden. Alternativ arbeiten Sie mit einem Shortcut, beispielsweise steht »OP388« für das Arbeitspaket mit der Open-Project-ID 388. Wer sich an diese Vorgehensweise hält, wird in Open Project damit belohnt, dass er alle mit dem Label versehenen Commits und Issues automatisch auch im Arbeitspaket verlinkt vorfindet. Ist Ihnen das zu viel Information, nutzen Sie »PPID«, was explizit diesen Kommentar vom Veröffentlichen in Open Project ausschließt (“P” wie “privat”). Das funktioniert zudem verschachtelt: Ein Merge Request mit OP-Vermerk wird in Open Project getrackt, inklusive Kommentare, außer denen, die einen PP-Vermerk enthalten (Abbildung 6).

Abbildung 6: Mit Shortcuts wie »OP388« definiert der Programmierer, dass beispielsweise der Kommentar öffentlich sein soll, und überall in Open Project angezeigt werden wird.

Fazit und Ausblick: tief verbunden

Seit Version 13.4 hat Open Project neben der Gitlab-Integration eine Vielzahl anderer neuer Funktionen, Verbesserungen und Fehlerbehebungen an Bord, beispielsweise bei den Projektlisten. Dazu gibt es neue Funktionen des Besprechungsmoduls sowie erstmals eine Antiviren-Funktion (für Kunden der Enterprise On-Premise-Version) und Zwei-Faktor-Authentifizierung mit WebAuthn. Mehr Details dazu lesen Sie in den Release Notes [4], dem zugehörigen Blogpost [5] und dem Systemadministratorhandbuch [6] nach. Kurz vor Redaktionsschluss erschien außerdem das neue Major Release 14, das wir zusätzlich auf die Heft-DVD gepackt haben.

Die Verlinkungen zwischen den beiden Tools gehen recht weit, sowohl das Erstellen von Merge Requests als auch die Informationen zum Status derselben integrieren das jeweils andere Tool. Gitlab und Open Project sind da fast immer nur einen Mausklick entfernt. Ändert sich etwas am Status des Merge Requests, dann findet der Open-Project-Anwender das sofort in seinem Arbeitspaket. Neue Issues erscheinen dort ebenfalls, sobald ein Gitlab-Kommentar mit einer »OPID« versehen wird. (csi)