GitLab für Projektmanagement und Entwicklung
Teil 2 unserer Serie zum Projekt-Workflow — Teil 1 zeigt den Projektstart mit dem Nutshell Starterkit.
Es gibt unzählige Projektmanagement-Lösungen. Wir haben viele Jahre mit Basecamp gearbeitet, bevor wir zu GitLab gewechselt sind — einer Alternative zu GitHub, die sich auch selbst hosten lässt. Denn Basecamp war zwar super für die Zusammenarbeit mit (Design-)Agenturen, aber die Zusammenarbeit im Entwickler:innen-Team musste schon frühzeitig auf anderem Weg stattfinden.
Das Problem: Wie sorgt man dafür, 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.
Projektstart im Team
Nachdem ein neues Projekt angelegt ist und alle Projektmitglieder eingeladen sind, pusht der:die Hauptentwickler:in den aktuellen Stand, sodass die anderen ihn sich holen und lokal installieren können. Um eine lauffähige Installation zu erhalten, genügt ein Schnelldurchlauf durch die Schritte aus dem Starterkit-Setup: .env anpassen, npm install, gulp konfigurieren.
Da alle Dateiänderungen in GitLab dokumentiert sind, lassen sich grundsätzlich auch alle Änderungen diskutieren und optimieren („Warum hast du das so gemacht?“). Zu Anfang ist das weniger wichtig, aber je älter das Projekt wird, desto wichtiger wird diese Funktion. So lassen sich auch Kontrollmöglichkeiten einrichten, wenn z. B. neue Entwickler:innen an einem älteren Projekt mitarbeiten. Hier kämen theoretisch auch Merge Requests ins Spiel, die bei uns bisher aber fast keine Rolle spielen.
Tickets und Meilensteine
Natürlich nutzen wir auch die Tickets in GitLab: für Absprachen, Diskussionen und um auf Probleme aufmerksam zu machen (z. B. fehlende Ressourcen wie Logo oder Schriften). Auch Fragen zur Funktionsweise werden oft als Ticket angelegt, einer Person zugewiesen und besprochen.
Bei vielen Projekten ordnen wir diese Tickets zusätzlich Meilensteinen zu, damit ersichtlich wird, wann Aufgaben Priorität haben und wann sie voraussichtlich fertiggestellt werden.
Wiki
Manche Projekte erfordern eine Dokumentation. In diesen Fällen nutzen wir die Wiki-Funktion, um sie zentral zu pflegen. In anderen Projekten hinterlegen wir dort Zugangsdaten, z. B. für den SSH-Zugriff oder die Datenbank.
Damit kratzen wir nur an der Oberfläche von GitLab. Eine weitere Aufgabe, die GitLab bei uns übernimmt — automatisierte Backups — findest du in Teil 5: Launch, Go-Live und Wartung. Wie wir Projektstände auf Stage und Live-Server veröffentlichen, zeigt Teil 3: Deployment mit Deployer.