Vergleich zwischen Software Development Tool Suites

Wir leben nicht nur in interessanten Zeiten, was die verschiedenen Gesundheitssysteme der Erde betrifft, sondern auch wie wir heute programmieren. Zugegeben, das heutige Blog Thema ist nicht annähernd so wichtig wie das eben Genannte aber dennoch erleichtern uns verschiedene Tools oder teilweise sogar Eco-Systeme unsere Arbeit sehr. Alle Mitarbeiter der CIIT arbeiten mit der JetBrains Software und können damit alle ihre Vorteile nutzen. Egal, ob es um den Build Server geht oder darum die gegenseitigen Code Reviews mit UpSource zu optimieren. Die Software Pakete, die wir nutzen, kosten natürlich etwas. Die GitLab Server bringen aber ähnliche Softwarepakete mit, allerdings sind diese kostenlos. Daher dachten wir uns, vergleichen wir doch beide miteinander. Das Resultat könnt ihr hier nachlesen.

Kapitel 1: Issue Verwaltung

JetBrains bietet prinzipiell ein in sich geschlossenes, System. Auch GitLab kann sich sehen lassen. Gehen wir Schritt für Schritt alles durch. Wir starten unseren Vergleich mit der Erstellung von Issues. In Gitlab ganz einfach unter dem Punkt „Issues“ zu finden. Ein Vorteil den GitLab definitiv hat ist, dass alles in einem Programm ist. Wenn sie von YouTrack zu UpSource springen wollen, müssen sie das über Untermenüs oder über den JetBrains Hub machen. Das wäre ein klares Plus für GitLab, aber wir sind ja noch nicht am Ende unseres Artikels.

Der Aufbau des neuen Issues in GitLab ist einfach und simpel. Ich würde auch soweit gehen, dass er alles hat was man benötigt. Der Titel, die Beschreibung und auch die Eckdaten für die Programmierer sind klar zu erfassen.

Ein großes Manko, das wir hier haben ist, dass GitLab out of the box kein Agile beherrscht. Natürlich kann man statt Milestones den Sprint eintragen und das Duedate immer am Ende des Sprints. Dennoch spiegelt das Look and Feel nicht den „Normalzustand“ eines Agile Teams wie in Scrum wieder. Dennoch vergessen Sie nicht, dass sie das gratis dazubekommen! Für einen Indie Entwickler oder ein kleines Softwarestudio kann das durchaus vollkommen ausreichend sein. Im Vergleich zu JetBrains fallen hier die tausend verschiedenen Tools und Steuerelemente sofort auf.



Sobald ich YouTrack öffne und auf den New Issue Button klicke, komme ich mir oft so vor als wären die Möglichkeiten grenzenlos. Egal ob Sie lieber Commandos per Console eingeben, Issues verlinken, taggen oder User zuweisen wollen, alles funktioniert recht einfach und durch die gut durchdachte UI/UX Erfahrung die YouTrack bietet finden sie es auch ohne groß googeln zu müssen.



YouTrack bietet hier wesentliche Komfortfeatures, die man auch sinnvoll im Alltag verwenden kann. Wenn sie z.B. eigene Tags erstellen wollen die spezifisch für ein Projekt gültig sind, können sie das ganz einfach machen. Wir unterscheiden hier beispielsweise zwischen Kunden- und Consulting-Projekten. Damit können Sie dann Suchen durchführen, Bulk Updates oder ihren Kunden (sofern er Zugang hat) mit einem Mausklick informieren, dass er etwas zu tun hat. Klicken wir auf den Tag „Feedback“ bekommt der im Projekt hinterlegte Kunde/in sofort eine E-Mail. Damit wir uns nicht mehr zu lange mit diesem einem Thema beschäftigen, machen wir hier noch einen Vergleich zwischen der Issue Verwaltung von GitLab und YouTrack. Der Unterschied zwischen beiden Software Paketen ist nicht so groß. Das GitLab Board bringt alle Basics und ein bisschen mehr. YouTrack bringt zusätzlich etliche Features, die für den Entwickler und Kunden sinnvoll sind, mit. Diese erleichtern vor allem die Kommunikation intern im Team, als auch zwischen allen Projektmitgliedern.

Das Board in GitLab zeigt uns Issues und ihren jeweiligen Status relativ einfach an. Man kann damit filtern und den Issue direkt in ein neues Label ziehen. Hier gilt wieder: das ist eigentlich alles was man braucht. Das Board erinnert mich aber relativ stark an ein Trello Board. (https://trello.com/en)



JetBrains zeigt hier wieder, dass jahrelange Entwicklung natürlich auch viel mehr Features mit sich bringt. Die Tasks werden anhand ihres „States“ in die verschiedenen Sprints aufgelistet. Es kann im Sprintboard (dort wo „No Affected Versions“ steht) ein neuer Sprint angelegt werden und das neue Board ist fix fertig hergerichtet.



In GitLab muss hier jedes Mal ein neues Board erstellt werden. Es gibt eine „Add Default Boards“ Möglichkeit.

Fazit: Für ein kleines Team oder ein Unternehmen ist GitLab wahrscheinlich ein super Start, um Issues anzulegen und mit dem Kunden über solche Boards kommunizieren zu wollen. Durch die starken Einschränkungen im Bereich Customization und Usability kann das für große Teams und Unternehmen aber relativ schnell „entnervend“ werden.  

Kapitel 2: Code Reviews

Die Reviews werden bei uns im Haus mit UpSource gemacht. Klären wir für alle Leser die Frage, was sind Code-Reviews oder Peer-Reviews?

Reviews sollten normalerweise vor dem Commit in den Release Branch gemacht werden. Wenn man kein Review Tool hat setzen sich zwei Teammitglieder vor einen PC oder in einem Raum mit Beamer/TV und gehen die Code Änderungen der letzten Tickets durch. Das ist ein wenig aufwendig, weil man sich in großen Unternehmen einen Raum buchen und den Zeitraum mit den Kollegen abstecken muss.

Vor allem in der Corona Krise ist das noch etwas umständlicher. Natürlich kann man via Skype oder Teams den Code miteinander durchgehen. Allerdings ist das ohne zusätzliche Software, die diesen Prozess unterstützt aus meiner persönlichen Sicht etwas mühsam.

Das Großartige an Code Review Tools sind die zusätzlichen Möglichkeiten, die sie bieten. Normalerweise müssen sich zwei Teammitglieder gegenseitig einladen und können dann ein Code Review durchführen. Bei UpSource und GitLab gibt es die Möglichkeit das Tool selbst entscheiden zu lassen welche Teammitglieder zum Review eingeladen werden. Es ist auch nicht erforderlich, dass beide Teammitglieder verfügbar sind, da ganz einfach im Code Kommentare eingetragen werden können. Sie sind auch nicht mehr darauf angewiesen, wann genau sie diese Code Reviews durchführen. Das ist für alle Mitarbeiter in einem Team eine Erleichterung. Die Screenshots, die ich hier für meinen Vergleich verwende, sind von GitLab und JetBrains öffentliches Material. Fangen wir mit JetBrains Upsource an, da wir im vorherigen Blog Eintrag mit GitLab begonnen haben:



Wie wir hier sehen können gibt es rechts einen News Feed, der die letzten Commits und seine Reviews anzeigt. Man kann nach Reviews filtern und alles ganz klar nachverfolgen. Wenn man auf einen der Issues klick kommt man auf eine detaillierte Ansicht im Code. Dort wird angezeigt wer den Code commited hat und was genau die Änderungen sind. Hier wird auch klar und deutlich was am Code geändert wurde. Wenn Sie jetzt eine Zeile markieren würden könnten sie ein Kommentar einfügen.



Sehen wir uns jetzt die Möglichkeiten in GitLab an. Hier haben Sie zwei Möglichkeiten ein Code Review zu machen. Entweder Sie verwenden den Blame Button in den Commits wie hier in meinem Beispiel, oder Sie können bei einem Merge Request verschiedener Repositorys einen direkten Vergleich machen. Das funktioniert aber nur bei einem direkten Merge zwischen zwei verschiedenen Branches.



Die letzte Möglichkeit ist aus der Liste von Commits das jeweilige auszuwählen. Damit kommen Sie direkt in eine Detailansicht, ganz ähnlich wie bei der UpSource Ansicht. Nur mit weniger Details.



In der Detailansicht des Issues können Sie jetzt ganz einfach ihre Review Anmerkungen angeben. Mit Klick auf die Zeile können Sie dann einfach zusätzliches Material, wie Bilder, hinaufladen oder einfach eine Message zu ihrem „Finding“ angeben. Das ist praktisch und wir können natürlich auch sofort unserem Kollegen per E-Mail benachrichtigen, dass etwas nicht passt, indem wir ihm ein Kommentar in seinen Code schreiben.



Fazit: Im zweiten Teil unserer Serie haben wir gesehen, dass die GitLab Integration nur ein paar Schwächen gegenüber der Bezahlvariante von JetBrains besitzt. Diese Features sind für größere Projekte sicher unabdingbar. Für kleinere Projekte reicht die GitLab Integration aber aus.