1 Kommentar // Lesezeit: 9 min.
Es ist schon einige Zeit her, dass wir uns mit dem Thema Gitlab auseinander gesetzt haben. Wir nutzen Gitlab bei sgalinki Internet Services schon für eine lange Zeit und wir sind sehr zufrieden damit.
Entgegen allen Vorurteilen begebe ich mich auch als Entwickler recht gern auf Konferenzen. Wo sonst kann man in der kürze der Zeit soviel Gleichgesinnte treffen? Der Austausch ist in der heutigen, schnelllebigen Zeit, eines der wichtigsten Dinge und gibt uns das Rüstzeug und die Inspiration um unsere alltäglichen Aufgaben zu meistern.
Ich habe mich auf dem ein oder anderen Event nun schon mit viele Kollegen anderer Unternehmen unterhalten und manche Diskussion oder Fragen kommen immer wieder auf.
Fragen wie zum Beispiel:
- Wie verwaltet ihr die Repositories?
- Führt ihr Code-Reviews durch und wenn ja, wie setzt ihr das um?
Fragen die verständlich sind. Nicht jede kleine Agentur hat die Möglichkeiten immer die neusten Technologien sofort zu verwenden. Oftmals fehlt einfach die Zeit, um sich mit diesen Themen auseinanderzusetzen. Doch Versionierung und Code-Reviews sind ein Thema, dass die alltägliche Arbeit dermaßen erleichtert, so dass sich das Investment für die Einrichtung schnell auszahlt.
Doch wie machen wir das ganze nun? Um auf die Fragen einmal zurückzukommen.
Wir von sgalinski Internet Services verwenden schon recht lange das Versionierungssystem Git und verwalten unsere Git-Repositories mit Hilfe der Open-Source-Software Gitlab.
Vor nicht allzu langer Zeit habe ich einmal eine Einführung zu Gitlab geschrieben. Schaut sie euch doch bei Interesse noch an. Heute jedoch soll es in meinem Beitrag mehr um das Thema Merge-Requests drehen.
Gitlab Merge-Requests
Gitlab enthält seit der Version 2.0 ein Feature namens Merge-Request. Einige werden Merge-Requests eher unter dem Terminus Pull-Request kennen. Die Plattform Github verwendet diesen Begriff und prägt ihn durch ihre große Verbreitung sehr.
Doch technisch gesehen ist ein Merge-Request nichts anderes als ein Pull-Request.
In einem Merge-Request stellt ein Entwickler oder ein Entwicklungsteam eine Anfrage zum "mergen" eines Entwicklungszweiges in den Hauptzweig. Dieser Entwicklungszweig kann mehrere Commits enthalten.
Somit wird das Thema Merge-Requests erst richtig interessant, wenn das Entwicklungsteam nach dem Feature-Branch-Workflow arbeitet. Denn für einen Merge-Request benötigen wir einen anderen Git-Branch.
Sie wollen mit Spezialisten im Thema Webentwicklung auf Augenhöhe sprechen?
Kurze Beschreibung des Feature-Branch-Workflow
Auch beim Arbeiten nach dem Feature-Branch-Workflow stellt der Master-Branch die zentrale Projekt-Historie dar. Doch anstatt direkt in den lokalen master zu commiten, erstellen die Entwickler beim arbeiten an einem neuen Feature immer einen neuen Branch.
Feature-Branches sollten einen klaren und verständlichen Namen besitzen. In vielen Unternehmen gibt es Konventionen für die Branch-Namen. Zum Beispiel könnte ein Branch-Name sich wie folgt zusammensetzen:
{type}-{Zusammenfassung in 2-3 Worten}-{ticket id}Nach dieser Konvention hätten wir für unseren Blog-Artikel (der auch im git versioniert wird) folgenden Branch "feature-gitlab_merge_request-4711".
Git macht keinen technischen Unterschied zwischen dem Master- und den Feature-Branches. Bedeutet das Entwickler wie sie es auch vom Arbeiten auf dem Master-Branch kennen commiten, stashen, und cherry-picken können. Man hat also keine Nachteile, sondern nur Vorteile durch den Feature-Branch.
Feature-Branches sollten jedoch nicht nur lokal verwendet werden. Man pusht sie ebenso zum zentralen Repository, wie wenn man auf dem Master arbeitet. Nur so können auch andere Entwickler des Teams mitarbeiten oder das Feature testen. Ganz nebenbei hat man so auch ein super Backup der lokalen Commits. Man weiß schließlich nie was mit einem Rechner passiert.
Ihr arbeitet also an einem Projekt und habt die Aufgabe eine REST-API zu entwickeln. Um die anderen Entwickler am Projekt nicht zu behindern erstellt ihr euch dementsprechend einen extra Featue-Branch.
git checkout -b feature_rest-api-4711 origin/masterDiesen Entwicklungszweig könnt ihr bisher nicht mit Kollegen teilen, da er nur lokal vorliegt. Somit wäre die logische Konsequenz ihn gleich nach dem Erstellen an das zentrale Repository zu pushen.
git push -u origin feature_rest-api-4711Nun könnt ihr wie gewohnt arbeiten und commitet eure Arbeit in regelmäßigen Abständen. Denkt dran: "commit small commit often" und spätestens am Ende des Arbeitstages einen "git push" ausführen.
Soviel einmal zum Feature-Branch-Workflow an sich. Doch irgendwann ist auch das komplizierteste Feature umgesetzt und muss den Weg in den Master-Branch finden. Hier kommen wir nun zum eigentlichen Thema Merge-Requests zurück. Denn ein Feature, wie eine REST-API, sollte schon gewissenhaft getestet und von mehr als nur einem Entwickler gesichtet werden.
Braucht Ihr Unternehmen einen Webspezialisten, mit dem es auf Augenhöhe sprechen kann?
Merge-Requests anlegen
Da wir unser Feature nun entwickelt haben und es in unseren Hauptzweig verschoben haben wollen, erstellen wir einen neuen Merge-Request in Gitlab. Man könnte auch den Branch einfach selbst in den Master mergen, nur dann verwehrt man sich einem anständigen Dialog mit den Kollegen. Denn die Gitlab Merge-Requests können auch hervorragend für Reviews genutzt werden.
Wenn ihr den Branch gepusht habt, ist in Gitlab ein Button zum Erstellen eines neuen Merge-Requests. Diesen Button findet ihr unter Projects, Activity, Files, Commits und natürlich direkt bei Merge-Requests. Man kann es also nicht übersehen.
Zum Erstellen des neuen Merge-Requests muss das folgende Formular ausgefüllt werden.
Wir haben eine recht simple Benutzeroberfläche durch Gitlab und können somit nicht wirklich etwas falsch machen. Die Branches sind vorausgewählt und in der Regel müssen wir hier nichts anpassen. Es sei denn wir haben uns verklickt und wollten für den falschen Branch einen Merge-Request erstellen.
In unserem Fall wollen wir den feature-rest_api-4711 Branch in den Master gemerged haben. Dafür müssen wir nun nur eine aussagekräftige Beschreibung zu unseren Anpassungen verfassen. Wir notieren in diesem Schritt auch immer die Schritte zum erfolgreichen einrichten. Denn es kann vorkommen, das die Tester erst noch Anpassungen an der Datenbank oder anderen Systemen vornehmen müssen um ein neues Feature testen zu können. Es ist somit wichtig den Kollegen alle nötigen Informationen zu geben, damit sie dieses neue Feature testen können. Es ist zudem gleich eine gute Dokumentation für später. Man könnte diese Informationen auch in einer Markdown Datei im Dokumentationsverzeichniss des Projektes ablegen.
Für die Beschreibung des Merge-Requests könnt ihr übrigens auch Markdown verwenden.
Neben der Beschreibung des eigentlichen Vorgangs könnt ihr den Merge-Request einem Kollegen zuweisen. Dieser erhält eine Benachrichtigung, dass er diesen Merge-Request sichten und freigeben soll. Falls es einmal nötig sein sollte, dass mehrere Personen benachrichtigt werden sollen, so kann man in der Beschreibung mit "/cc @all" oder "/cc @sgalinski" auch noch weitere Personen benachrichtigen. Diese können jedoch dann den Merge-Request in der Regel nur voten und ihn nicht schließen.
Wenn ihr alles gewissenhaft ausgefüllt und dokumentiert habt müsst ihr einfach nur den "Create Merge-Request" Button drücken und schon kommt der Review-Prozeß für eure tolle REST-API in Gang.
Wir haben Jonas Quinn als Hauptverantwortlichen zugewiesen und nur er oder du selbst kannst den Merge-Request nun akzeptieren.
Die anderen Personen, welche durch das CC eine Mail bekommen haben, können die Anpassungen kommentieren und mit +1 oder -1 voten.
So bekommt man, auch wenn Jonas Quinn keine Zeit hatte den Review durchzuführen, von den anderen Beteiligten Feedback und kann nach vielen guten Wertungen auch selbst guten Gewissens den Merge-Request akzeptieren.
Bei uns findet Jonas Quinn ein wenig Zeit und schaut sich den Merge-Request und die Commits einmal an. Er kann seine Kritik nun direkt in den Code-Diffs oder als normalen Kommentar am Merge-Request äußern.
Durch diese Art der Kommunikation kann man sehr gut und gezielt Code-Reviews durchführen. Andere Kollegen sehen oft Probleme, die man selbst nicht bedacht hat oder haben Verbesserungsvorschläge die noch eingearbeitet werden können. Ein Merge-Request ist nicht fertig wenn man ihn erstellt hat. Die Bemerkungen von Jonas Quinn kann man nun einfach in seinem Feature-Branch bearbeiten.
Oder wenn es nichts anzupassen gibt auch einfach nur beantworten. Nach dem Feedback von Jonas ist unser Merge-Request erst einmal runtergewertet worden. Jonas hat mit dem Kommentar :thumbsdown: dafür gesorgt das der MR eine negative Wertung hat.
Ihr könnt dies an dem kleinen Symbol sehen.
Da Markus wirklich sehr spärlich dokumentiert hatte, wird dies nun mit einem weiteren Commit im Feature-Branch angepasst. Dieser Commit wird automatisch im Merge-Request angezeigt.
Markus kann nun noch die Kommentare von Jonas beantworten und somit die Diskussion am Laufen halten. Es ist das Ziel das bestmögliche Produkt zu liefern und dazu sind in der Regel mehr als zwei Augen wichtig.
Man kann schön im Stream sehen wie die Entwickler auf einfache Art und Weise Probleme direkt am Code besprechen können. Jonas wird nun über den aktuellen Status benachrichtigt und kann dann nochmals den Review bewerten.
Jonas hat unsere Anpassungen, neben Nolan, der sich auch nach seiner E-Mail eingeschaltet hat, für gut befunden und wir können nun mergen. Bei den Bewertungen ist darauf zu achten, dass das ":thumbsup:" oder ":thumbsdown:" als Erstes im Kommentar gegeben wird und nicht am Ende. Sonst wird es nicht ausgewertet. Das Abwerten von Jonas wurde durch sein ":thumbsup:" nun aufgehoben und unser Merge-Request hat zwei gute Bewertungen.
Nun kann Markus entweder selbst den Merge-Request akzeptieren, oder er wartet bis Jonas es tut.
Beim Akzeptieren des MR sollte man noch einiges beachten:
Wir haben in der Beschreibung des MR viel dokumentiert um es den Testern möglichst einfach zu machen. Wenn wir nun allerdings einfach den grünen Button drücken, dann bekommen wir eine ziemlich ausführlich commit message in unserem Master-Branch. Das wollen wir nicht und daher passen wir die commit-message noch nachträglich an.
Wir möchten auch nach dem merge in den Master den Feature-Branch nicht weiter nutzen und klicken daher auch die Checkbox zum Löschen des Quell-Branches an.
Das sollte nun ungefähr so aussehen. Wenn dem so ist sind wir bereit für den letzten Schritt. Wir klicken den "Accept Merge Request" Button.
Gitlab wird nun automatisch die Anpassungen in den Master-Branch überführen, den Feature-Branch für uns löschen und wenn wir ein Ticket genannt haben das Ticket aktualisieren (in diesem Fall schließen).
Wie man sehen kann haben wir unsere REST-API nun erfolgreich in den Master gemerged und das Feature somit abgeschlossen.
Ich hoffe, dass ich euch mit diesem Artikel ein wenig zeigen konnte, wie man mit Git und Gitlab seinen Arbeitsprozess optimieren kann.
Wir lieben Gitlab!
Kontaktieren Sie uns!
Wir sind eine Digitalagentur, die sich auf die Entwicklung digitaler Produkte spezialisiert hat. Unsere Kernthemen sind Webseiten und Portale mit TYPO3, eCommerce mit Shopware und Android und iOS-Apps. Daneben beschäftigen wir uns mit vielen weiteren Themen im Bereich Webentwicklung. Kontaktieren Sie uns gerne mit Ihren Anliegen!
Kommentare
Maximilian Mayer
am 10.09.2015Super Artikel, Markus :-). Super Artikel, Markus :-).