Wie wir Gitlab fürs Projektmanagement nutzen [Klassik]

Moin!

Ab und zu verschicke ich besonders reaktionsreiche oder (in meinen Augen) wertvolle Flaschenposten erneut. So auch heute.

***

Heute möchte ich dir ein wenig davon erzählen, wir wir Gitlab für das Projektmanagement und die Arbeit im Team an Projekten nutzen. Falls du noch nicht mit Gitlab gearbeitet hast, dann ist diese Mail genau richtig für dich.

Ich weiß es gibt unzählige Projektmanagement-Lösungen da draußen. Wir haben viele Jahre mit Basecamp gearbeitet, bevor wir zu Gitlab (einer Alternative zu Github, die sich allerdings auch selbst hosten lässt) gewechselt haben.

Denn während Basecamp zwar super in Zusammenarbeit mit (Design-)Agenturen war, musste die Zusammenarbeit im Entwickler-Team schon frühzeitig auf anderem Wege stattfinden.

Das Problem: Wie lässt sich dafür sorgen, dass alle Entwickler:innen stets den aktuellen Stand der Entwicklung haben ohne sich gegenseitig in die Quere zu kommen?

Die Lösung: Eine Versionierung über Git, über die sich jedes Team-Mitglied jederzeit den aktuellen Stand holen (pullen) bzw. die eigenen Änderungen übergeben (commit + push) kann. Das ist die Kernfunktion von Gitlab, neben ein paar, nicht weniger wichtigen Funktionen.

Nachdem also eine neues Projekt angelegt und alle Projektmitglieder eingeladen sind, wird vom Hauptentwickler (das bin meistens, aber nicht immer ich) der aktuelle Stand gepusht, sodass die anderen Teilnehmer:innen sich den Stand holen und lokal installieren können. Um eine lauffähige Installation zu erhalten, führen sie folgende Schritte im Schnelldurchlauf durch: .env anpassen, npm install, gulp bzw. webpack konfigurieren (dazu demnächst mehr).

Da alle Dateiänderungen in Gitlab dokumentiert sind, lassen sich so grundsätzlich auch alle Änderungen diskutieren bzw. optimieren („Warum hast du das so gemacht?“). Das ist zu Anfang weniger wichtig, aber je älter das Projekt wird, desto wichtiger wird diese Funktion. So lassen sich auch Kontroll-Möglichkeiten einrichten, wenn z.B. neue Entwickler:innen an einem älteren Projekt mitarbeiten. Hier würden dann theoretisch auch die Merge Requests ins Spiel kommen, die bei uns aber bisher fast keine Rolle spielen.

Außerdem nutzen wir natürlich die Tickets in Gitlab: für Absprachen, Diskussionen und um auf Probleme (z.B. fehlende Ressourcen wie Logo oder Schriften) aufmerksam zu machen. Auch werden Fragen zur Funktionsweise oftmals als Tickets angelegt, einer Person zugewiesen und besprochen.

Bei vielen Projekten werden diese Tickets dann noch Meilensteinen zugeordnet, damit ersichtlich wird, wann diese Aufgaben Priorität haben und wann sie voraussichtlich fertigstellt werden.

Ein paar Projekte erfordern zusätzlich, dass wir Dokumentationen führen. In diesen Fällen nutzen wir die Wiki-Funktion, um diese zentral zu pflegen. In anderen Projekten hinterlegen wir dort Zugangsdaten, z.B. für den SSH-Zugriff mit Public Key oder Datenbank-Zugänge.

Ich weiß, dass wir damit nur an der Oberfläche von Gitlab kratzen, weil es noch sooo viieell meeehr kann*. Nutzt du Gitlab für deine/eure Projekte?

Viele Grüße und bis nächste Woche,
Dennis

* Wir nutzen es zum Beispiel auch für wöchentliche Backups der Websites unserer Wartungsvertragskund:innen.