General
Sometimes, regardless of the possibilities offered by “the cloud”, you want to host important services yourself. For me as a software and DevOp engineer, this applies to my source code. For this reason, I host my GitLab instance myself. Since the GitLab package for DSM provided by Synology is outdated, I will explain here how to install the latest version of GitLab on a DiskStation using Docker.
Read more “GitLab on a DiskStation”
GitHub
GitLab has recently made a great name for itself in the world of project management software (read this article for a comparision between several source code management systems). Unfortunately, the possibilities for monitoring statistics are still relatively simple at present. For this reason I started a collection of small Python-scripts, which can be integrated in a munin monitoring environment. The code is open source and can be viewed and downloaded on GitHub at https://github.com/MatthiasLohr/munin-plugins-gitlab. Contributions are highly welcome!
General
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 mit 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.