And the winner is…

GitLab!

Vielen dürfte das Problem nicht mehr ganz so am Herzen bzw. eher in der Magengrube liegen wie früher: Der Betrieb, oder noch herausfordernder, die Wahl einer Projekt-Verwaltungs-Software ist inzwischen Dank GitHub und einer Vielzahl kostenloser wie frei zugänglicher Open-Source-Lösungen heutzutage kein Problem mehr. Früher (aus meiner Perspektive am Anfang meiner universitäten und beruflichen Laufbahn) war das nicht ganz so leicht.

Vielleicht erinnern sich einige noch an Trac: Ticket-System, Wiki, Verwaltung des Code-Repositories – und das alles webbasiert. Für mich als Entwickler damals beim ersten Kontakt ein Meilenstein der Software-Entwicklung, da man eine zentrale Anlaufstelle für Code, Aufgaben und weiterführenden Informationen hatte. Wenn man als Team jedoch mehrere Projekte zu stemmen hatte, kam man dabei auch schon recht schnell an die Grenzen von Trac: Pro Projekt musste eine neue Instanz eingerichtet werden, ein automatisches Setup oder gar eine komplette Verwaltung über das Webinterface war nicht ohne Weiteres möglich. Ein bis dato noch nebensächliches, kleines Manko: Trac war limitiert auf SVN, Git, damals gerade dabei bekannt zu werden, war auch nur durch mehr oder weniger stabil laufende Plugins nutzbar.

Auf der Suche nach einer Lösung für die Multiprojektfähigkeit, ohne jedesmal einen Administrator bemühen zu müssen, landeten wir dann bei Redmine. Webbasiertes Einrichten von Projekte, nach späteren Updates sogar der Möglichkeit mehrere Repositories pro Projekt anzulegen – und nebenbei natürlich Unterstützung für Git – sorgten recht schnell für eine Migration aller Trac-Projekte hin zu Redmine. Kleiner Schönheitsfehler hierbei: Die Repositories mussten immernoch per Hand initialisiert werden.

Ein Kollege unseres Teams kam dann auf die Idee, mal mit Git herumzuspielen, und – wenn man schon dabei ist – einfach mal GitLab auszuprobieren („Ich hab‘ da mal was gehört…“). Kurzum: Trotz der gerade erst erfolgten Migration auf Redmine waren gerade die kollaborativen Funktionen von GitLab in Kombination mit Git Killer-Features, welche sehr schnell gute Argumente für eine erneute Migration der Projekte auf den Tisch brachten. Recht schnell wurde die Plattform auch außerhalb des Teams und auch über die Abteilung hinweg genutzt. Entsprechend dem aktuellen Funktionsumfang von GitLab richteten wir noch Backup-Prozesse etc. ein, Änderungen am Kern der Software waren aus unserer Sicht nicht notwendig. Alles, was wir brauchten, war eben dabei. So beschränkte sich die Tätigkeit des Teams auf Benutzung (für die Entwicklungs-Projekte, die wir betreuten) sowie das Management (Server-Betrieb, Wartung, Updates, Migrationen und Schulungen) der Plattform.

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.