Teil 2/5: Wie wir Gitlab für Projektmanagement und die Entwicklung nutzen
Moin!
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 kann man dafür sorgen, dass alle Entwickler 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 der aktuelle Stand gepusht, sodass die anderen Teilnehmer sich den Stand holen und lokal installieren können. Um eine lauffähige Installation zu erhalten, führen sie die im ersten Newsletter erwähnten Schritte im Schnelldurchlauf durch (.env anpassen, npm install, gulp konfigurieren).
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 Etwickler 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.
Manche Projekte erfordern es, 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 oder Datenbank-Zugänge.
Ich weiß, dass wir damit nur an der Oberfläche von Gitlab kratzen, weil es noch so viel mehr kann. Eine weitere Aufgabe, für die wir Gitlab nutzen, werde ich dir in einem der nächsten Newsletter noch verraten.
Vorher will ich aber darauf eingehen, wie wir Deployer nutzen, um Projektstände auf einer STAGE und dem LIVE-Server zu veröffentlichen.
Achte auf den Betreff Teil 3/5: Wie wir Deployer für die Veröffentlichung nutzen.
Viele Grüße und bis nächste Woche,
Dennis