8 min
Folge 8 - Programmierung Eines Eigenen Git - Hosting - Tools Pro-Grammierer-Podcast
-
- Technology
Diese Folge in meinem Programmier-Podcast ist heute ein bisschen anderer Natur. Ich will euch zeigen, wie einfach es ist, sein eigenes Git-Hosting und Projekttool zu entwickeln.
Git ist aus der heutigen Programmierlandschaft nicht mehr wegzudenken. Früher hat man ZIP-Dateien mit Quellcode per E-Mail versandt, wenn man im Team arbeiten wollte. Dann gab es das erste Versionskontrollsystem: CVS. Man konnte Ordner für seine Kollegen sperren. Damit waren schon mal Konflikte unter Kontrolle, dass zwei Nutzer dieselbe Datei bearbeitet haben. Bei der Freigabe der Datei wurde dann die neue Version der Datei verteilt. Blöd nur, wenn der Kollege, der eine Datei gesperrt hat, gerade im Urlaub war.
Es gibt 1-2 Self-Hosting Git-Tools, z.B. das auf Go basierende Gogs, welches wir verwendet haben. Außerdem gibt es in der Cloud noch github.com von Microsoft.
Uns hat das Gogs irgendwann nicht mehr ausgereicht, Alternativen waren zu klobig und mit Features überladen und in die Github-Cloud wollten wir auch nicht mit unseren Firmendaten.
Die Anforderungen an ein neues Git-Tool waren:
• Projektübergreifende Issues, die man von egal-welchem Projekt lösen konnte
• Suchfunktion für Issues
• Kunden-Zugriff mit sichtbaren und unsichtbaren Issues
• Eine intelligente Issue-Priorisierung – wir haben uns entschieden, die Priorität in € zu messen
• Issue-Abhängigkeiten und damit verbundene Priority inheritence: Die Priorität einer Issue in € wird einfach auf die abhängigen Flaschenhals-Issues aufaddiert
Ein eigenes Git-Tool ist im Prinzip nicht schwer zu bauen. Man benötigt einen SSH-Server, auf den man pushen und von dem man pullen darf, sowie ein Web-Frontend für das Projektmanagement und die Issues.
Diese Folge in meinem Programmier-Podcast ist heute ein bisschen anderer Natur. Ich will euch zeigen, wie einfach es ist, sein eigenes Git-Hosting und Projekttool zu entwickeln.
Git ist aus der heutigen Programmierlandschaft nicht mehr wegzudenken. Früher hat man ZIP-Dateien mit Quellcode per E-Mail versandt, wenn man im Team arbeiten wollte. Dann gab es das erste Versionskontrollsystem: CVS. Man konnte Ordner für seine Kollegen sperren. Damit waren schon mal Konflikte unter Kontrolle, dass zwei Nutzer dieselbe Datei bearbeitet haben. Bei der Freigabe der Datei wurde dann die neue Version der Datei verteilt. Blöd nur, wenn der Kollege, der eine Datei gesperrt hat, gerade im Urlaub war.
Es gibt 1-2 Self-Hosting Git-Tools, z.B. das auf Go basierende Gogs, welches wir verwendet haben. Außerdem gibt es in der Cloud noch github.com von Microsoft.
Uns hat das Gogs irgendwann nicht mehr ausgereicht, Alternativen waren zu klobig und mit Features überladen und in die Github-Cloud wollten wir auch nicht mit unseren Firmendaten.
Die Anforderungen an ein neues Git-Tool waren:
• Projektübergreifende Issues, die man von egal-welchem Projekt lösen konnte
• Suchfunktion für Issues
• Kunden-Zugriff mit sichtbaren und unsichtbaren Issues
• Eine intelligente Issue-Priorisierung – wir haben uns entschieden, die Priorität in € zu messen
• Issue-Abhängigkeiten und damit verbundene Priority inheritence: Die Priorität einer Issue in € wird einfach auf die abhängigen Flaschenhals-Issues aufaddiert
Ein eigenes Git-Tool ist im Prinzip nicht schwer zu bauen. Man benötigt einen SSH-Server, auf den man pushen und von dem man pullen darf, sowie ein Web-Frontend für das Projektmanagement und die Issues.
8 min