Was sind die bewährten Methoden von GitLab Flow?

Wenn Softwareentwicklungsteams die Lieferung schnellstmöglich vorantreiben wollen, kann dies zu unübersichtlichen oder komplexen Workflows führen. Unternehmen, die von einem anderen Versionskontrolle-System umgestiegen sind, haben es besonders häufig mit schwierigen Prozessen zu tun, die die Entwicklung verlangsamen können. Wenn Teams GitLab Flow verwenden, können sie funktionsorientierte Entwicklung und Feature-Branches mit Ticketverfolgung nutzen, um sicherzustellen, dass jedes Teammitglied effizient arbeitet. Mit diesen Tipps für GitLab Flow können Softwareentwicklungsteams den Prozess vereinfachen und ein effizienteres und saubereres Ergebnis erzielen.

Die Verwendung von Feature-Branches ist eine einfache Entwicklungsmethode, um den Quellcode sauber zu halten. Wenn ein Team erst kürzlich von SVN auf Git umgestiegen ist, ist es an einen Trunk-basierten Workflow gewöhnt. Bei der Verwendung von Git sollten Entwickler(innen) für alles, woran sie arbeiten, einen Branch erstellen, damit Mitwirkende den Code-Review-Prozess vor dem Zusammenführen problemlos starten können.

Manche Entwickler(innen) richten ihr CI so ein, dass es nur das testet, was in den main-Branch zusammengeführt wurde. Das ist aber zu spät im SDLC, und alle – von den Entwickler(inne)n bis zu den Produktmanager(inne)n – sollten sich darauf verlassen können, dass die Tests des main-Branch immer grüne sind. Es ist ineffizient, wenn Entwickler(innen) main testen müssen, bevor sie mit der Entwicklung neuer Funktionen beginnen.

Wenn du an einem feature-Branch arbeitest und neue Commits hinzufügst, führe sofort Tests durch. Wenn die Tests sehr lange dauern, versuche, sie parallel laufen zu lassen. Dies tust du serverseitig in Merge Requests, indem du die komplette Testsuite durchführst. Wenn es eine Testsuite für die Entwicklung und eine andere nur für neue Versionen gibt, lohnt es sich, [parallel] Tests einzurichten und sie alle auszuführen.

Teste nicht alles am Ende einer Woche oder eines Projekts. Code Reviews sollten so früh wie möglich stattfinden, weil die Entwickler(innen) dann eher Probleme erkennen, die später im Entwicklungszyklus Probleme verursachen könnten. Da sie die Probleme früher erkennen, fällt es ihnen leichter, Lösungen zu finden.

Wenn das Entwicklerteam nicht jedes Mal main bereitstellen will, kann es einen production-Branch erstellen. Anstatt ein Skript zu verwenden oder es manuell zu machen, können Teams die Automatisierung nutzen oder einen bestimmten Branch haben, der eine Produktionsbereitstellung auslöst.

Entwickler(innen) sollten tags verwenden, damit CI eine Aktion durchführt, statt das Repository zu ändern. Wenn Teams detaillierte Metriken benötigen, sollten sie einen Serverbericht haben, in dem neue Versionen ausführlich beschrieben werden.

Jedes Tag sollte eine neue Veröffentlichung erstellen. Diese Praxis gewährleistet eine saubere, effiziente Entwicklungsumgebung.

Wenn Entwickler(innen) einen öffentlichen Branch pushen, sollten sie ihn nicht rebasen, denn das macht es schwierig, beim Cherry Picking die Verbesserungen und Testergebnisse zu erkennen. Manchmal wird dieser Tipp ignoriert, wenn jemand am Ende einer Code Review darum bittet, etwas zu reduzieren und zu rebasen, damit es leichter zurückzusetzen ist. Im Allgemeinen gilt jedoch die folgende Richtlinie: Der Code sollte sauber sein, und der Verlauf sollte realistisch sein.

Dieser Tipp verhindert lange Branches. Entwickler(innen) checken main aus, erstellen eine Funktion, erstellen einen Merge Request und zielen auf main. Sie sollten vor der Zusammenführung und der Beseitigung von Zwischenschritten eine vollständige Überprüfung vornehmen.

Wenn jemand einen Fehler gefunden hat, wäre es problematisch, ihn in der gerade veröffentlichten Version zu beheben anstatt im main-Branch. Um das zu vermeiden, sollten Entwickler(innen) die Änderungen immer in den main-Branch pushen und dann in einem anderen patch-release-Branch cherry picken.

Die Entwickler(innen) sollten nicht nur schreiben, was sie gemacht haben, sondern auch, warum sie es getan haben. Noch nützlicher ist es, zu erklären, warum diese Option gegenüber anderen gewählt wurde, damit zukünftige Mitwirkende den Entwicklungsprozess besser verstehen können. Das Schreiben von ausführliche Commit-Nachrichten ist für Code Reviews und die zukünftige Entwicklung nützlich.