Warum GitLab?

GitLab bietet eine umfassende, integrierte Lösung, die es Entwickler*Innen ermöglicht, sich auf das Wesentliche zu konzentrieren: das Coden.
Mit Funktionen wie automatischer CI/CD, integriertem Issue Tracking und einer umfangreichen API können Entwicklerteams effizienter arbeiten und sich besser organisieren.

Wir nutzen intern Gitlab - allerdings sollten die meisten Aspekte auch auf GitHub übertragbar sein.

Beispiel: Automatisierung mit GitLab CI/CD

Ein prägnantes Beispiel ist die GitLab CI/CD-Pipeline. Durch die Einrichtung von Pipelines können Teams den Workflow automatisieren, von Linting und Testing bis hin zum Deployment. So wird sichergestellt, dass jede Codeänderung den festgelegten Qualitätsstandards entspricht.

Wir nutzen intern Gitlab - allerdings sollten die meisten Aspekte auch auf GitHub übertragbar sein.

Verbesserter Git Flow mit GitLab

Agilität ist nicht nur ein Schlagwort, sondern eine Notwendigkeit. Effektive und effiziente Workflows sind das Rückgrat erfolgreicher Projekte. Mit GitLab haben wir die Möglichkeit, unsere Entwicklungsprozesse zu revolutionieren und zu optimieren. In diesem Abschnitt beleuchten wir, wie wir den klassischen Git Flow angepasst haben, um unsere Arbeitsweise zu verbessern und unseren Entwicklungsprozess nahtlos zu gestalten.

Durch die Implementierung einer verbesserten Branch-Strategie, effektiverer Merge Requests (MRs), eines durchdachten Issue Trackings und der Integration einer CI/CD Pipeline in GitLab, haben wir nicht nur unsere Produktivität gesteigert, sondern auch die Qualität unserer Software im Blick. Diese Methoden ermöglichen es uns, Projekte transparenter und kollaborativer zu gestalten und gleichzeitig die Übersichtlichkeit und Effizienz unseres Entwicklungsprozesses zu erhöhen.

1. Branch-Strategie

Unsere verbesserte Branch-Strategie nutzt die Ticket-ID im Branch-Namen. Dies erhöht die Nachvollziehbarkeit und verbindet Änderungen direkt mit dem entsprechenden Issue.

Beispiel: feature/#123-neues-feature


2. Merge Requests (MRs)

MRs sind das Herzstück unseres Workflows. Jeder MR wird automatisch mit dem entsprechenden Issue verlinkt, was Transparenz und Traceability verbessert. Wir setzen auf Code Reviews, um Qualität und Wissenstransfer im Team zu fördern.

Praxisbeispiel: MR-Templates

Nutzen Sie MR-Templates, um konsistente und informative Merge Requests zu erstellen. Ein gut strukturiertes Template sollte Abschnitte für die Beschreibung der Änderungen, Testergebnisse und relevante Screenshots oder Logs enthalten.

3. Issue Tracking

GitLab Issues helfen uns, den Überblick zu behalten. Durch die Verwendung von Labels und Milestones können wir den Fortschritt unserer Projekte effizient verfolgen.

Beispiel: Automatisierung mit Labels

Setzen Sie automatische Aktionen mit Labels ein, um den Workflow zu beschleunigen. Zum Beispiel könnte das Hinzufügen des Labels "Review" automatisch ein Code Review auslösen.

4. GitLab’s CI/CD Pipeline

Die Integration von CI/CD in GitLab ermöglicht es uns, Tests und Deployments automatisch auszuführen. So können wir schneller liefern und gleichzeitig die Qualität sicherstellen.

Beispiel: Pipeline-Konfiguration

Nutzen Sie .gitlab-ci.yml, um Ihre Pipeline individuell anzupassen. Von einfachen Linting-Prozessen bis hin zu komplexen Deployment-Strategien lässt sich alles einrichten.

Hätten Sie noch eine Konfiguration?

Es gibt darüber hinaus noch zwei Einstellungsmöglichkeiten bei einem Merge Request.

• "Delete source branch when merge request is accepted."
• "Squash commits when merge request is accepted."

Nach dem Merge den Source-Branch zu löschen halte ich in fast allen Fällen für sehr sinnvoll, da ansonsten irgendwann eine endlose Zahl von Branches existiert und niemand mehr sagen kann, welche davon relevante Inhalte enthalten. Natürlich gibt es Fälle, wo es sinnvoll ist, den Branch zu behalten - aber wie man weiß, bestätigen Ausnahmen die Regel.

Praktischerweise kann man diese Einstellung standardmäßig in den Projekteinstellungen aktivieren:

Settings → General → Merge requests → "Enable 'Delete source branch' option by default"

Ich bin neuerdings ebenfalls ein Fan davon, Commits beim Merge zusammenzuführen. Voraussetzung ist, dass von dem aktuellen Branch nicht weiter abgezweigt wurde und dass nur genau eine Person hieran gearbeitet hat. Squashing bedeutet, dass alle Änderungen dieses Branches als ein einziger Commit ohne Änderungshistorie innerhalb des Branches im Zielbranch landen. Der Nachteil ist offensichtlich: Hat jemand sehr kleinteilige und gut dokumentierte Commits erstellt, gehen diese Informationen verloren. Auf der anderen Seite enden mit Squashing fast nur komplette Features und Bugfixes im Dev- bzw. Masterbranch. Gibt es ein Problem auf einem System ist es somit recht einfach herauszufinden, welcher Commit der Übeltäter ist. Dazu kommt, dass viele Entwickler eher knappe Commit-Messages schreiben. Da stellt für mich ein einzelner Commit mit allen Änderungen und ggf. einer umfangreicheren Beschreibung den größeren Mehrwert da.

TL;DR

1. Merge Requests (MR) nutzen
   
2. Gitlabs "WIP"-Prefix im MR-Titel verwenden
   
3. Falls Gitlab issues verwendet wird
   
   1. Branch-Namen mit Ticket-ID und Hashtag ("feature/#27-my-awesome-feature")
      
   2. Ticket-ID mit führendem Hashtag in MR-Titel verwenden
      
4. "Delete source branch"-Option in den Projektsettings aktivieren
   
5. Bei der MR-Erstellung "Squash commits" aktivieren, wenn nur eine Person an dem MR gearbeitet hat und keine Kind-Branches existieren

Community und Dokumentation

Für weitere Informationen und tiefergehende Tutorials empfehlen wir die offizielle GitLab-Dokumentation und die GitLab-Community.