Bei git hat man ein distributed Versionscontrolsystem. D.h. jeder kann
seine eigene git Instanz lokal auf seinem Rechner haben, damit arbeiten
und später alles zu der git Instanz hochladen, die als zentrale Git
Instanz ausgewählt wurde.
Was ich mich nun frage ist, ob es so etwas auch für Bug-, Issue- und
Projektmanagementsysteme gibt?
Also eine Projektmanagementsystem das verteilt arbeiten kann?
Bei dem ich also bspw. eine Hauptinstanz habe.
Davon holen sich alle Teammitglieder die derzeitige Listen und Inhalte
zu aktuellen und geschlossenen Bugs, Issues und Todos runter.
Lokal arbeiten sie dann mit einer eigenen Instanz der
Projektmanagementsoftware weiter.
In dieser können sie Bugs, Issues und Todos abarbeiten oder neue
hinzufügen.
Und irgendwann laden sie ihre Änderungen auf die Hauptinstanz wieder
hoch, also mergen alles.
Der ein oder andere wird sich jetzt fragen wozu man das brauchen könnte.
Immerhin kann man eine Projektmanagementsoftware auch einfach auf einen
Server ins Internet stellen und so alles zentral verwalten.
Und bei einer verteilten Projektmanagementsoftware kann man ja nicht
verhindern, dass zwei Leute am gleichen Bug arbeiten, also würde
doppelte Arbeit gemacht werden, was kontraproduktiv ist.
Nun, das mag alles sein, in meinem speziellen Fall will ich aber meine
Projektmanagementsoftware an verschiedenen Orten ohne Internetverbindung
haben.
Nur der Rechner wird hin und hergeschleppt. D.h. auf dem könnte man die
Projektmanagementsoftware auch installieren, aber dem Rechner fehlen die
Eigenschaften eines NAS auf dem die zentrale Instanz des
Projektmanagementsystem laufen soll.
D.h. auf dem NAS soll die zentrale Instanz der Projektmanagementsoftware
laufen und ab und zu müssen die Daten im Projektmanagementsystem der
zentralen Instanz auf dem NAS natürlich aktualisiert werden, wenn ich
mit einer lokalen Kopie auf dem Rechner gearbeitet habe.
So etwas wäre bspw. auch im mobilen Betrieb mit dem Notebook sehr
praktisch.
Dann könnte man unterwegs an seinen Bugs arbeiten, die Bugs in der
Projektmanagementsoftware als "done" markieren und dann, wenn man wieder
Zuhause ist, alles ins zentrale Projektmanagementsystem mergen.
Ohne so eine Funktion hat man nämlich unterwegs keinen Zugriff auf seine
Bugs oder Issues, wenn das Projektmanagementsystem Zuhause nur im
lokalen Netzwerk hängt und nicht per Internet erreichbar ist oder man
unterwegs einfach kein Internet hat.
Dafür wäre eine Projektmanagementsoftware die wie git verteilt arbeiten
kann optimal.
Gibt es so etwas?
Idealerweise als Open Source Software?
Nano schrieb:> Bei git hat man ein distributed Versionscontrolsystem. D.h. jeder kann> seine eigene git Instanz lokal auf seinem Rechner haben, damit arbeiten> und später alles zu der git Instanz hochladen, die als zentrale Git> Instanz ausgewählt wurde.>> Was ich mich nun frage ist, ob es so etwas auch für Bug-, Issue- und> Projektmanagementsysteme gibt?> Also eine Projektmanagementsystem das verteilt arbeiten kann?
Fände ich auch ganz praktisch, kenne ich aber leider nicht.
Generell ist der Aufwand für solch ein verteiltes System aber auch viel
höher als bei den einfachen Dateien, die mit git verwaltet werden. Bei
git werden keine Verknüpfungen zwischen den Dateien berücksichtigt,
daher kann man jede Datei einzeln versionieren.
Die meisten Projektmanagementsysteme basieren aber auf einer
SQL-Datenbank. Es gibt zwar DBMS, die eine Multi-Master-Replikation
anbieten, aber damit ist nicht das Problem der aggregierten Daten
gelöst.
Wenn also zu einem Bug-Eintrag mehrere Datensätze mit den gearbeiteten
Stunden erfasst werden, wird die Summe häufig in dem Bug-Eintrag selbst
aufsummiert, damit die Performance der Anzeige steigt.
Bei einem zentralen System ist das auch kein Problem, läuft ja alles in
einer Transaktion ab. Bei einem verteilten System müsste man aber eine
Fehlerbehandlung einbauen für den Fall, dass die Summe im Bug nicht mehr
mit der Summe der einzelnen Stunden-Datensätze übereinstimmt. Dieser
Fall tritt auf, wenn zwei Benutzer fast zeitgleich ihre Daten hochladen
und am gleichen Bug gearbeitet haben.
Das ist noch ein sehr einfaches Beispiel, das man mit einem Trigger
lösen könnte. Es gibt viele andere Situationen, die ein manuelles
Eingreifen erfordern.
Machbar ist das also, aber ziemlich aufwändig. Vielleicht hat es schon
einmal jemand umgesetzt, habe ich aber noch nicht gesehen.
Sebastian schrieb:> Gibt es. Eher zu viel als zu wenige, und es wird schwer eins> auszusuchen> das alles kann was du willst und dann auch noch gepflegt wird.>> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc.
Danke für den Link.
Ich bin jetzt mal alle durchgegangen, aber da scheint wohl nichts
wirklich brauchbares dabei zu sein, was mit Trac oder Redmine mithalten
kann.
Die meisten Projekte sind verweist, d.h. die Links laufen in einen 404
Error oder ähnliche Fehlermeldungen.
Von dem was übrig bleibt ist vieles nur ein Kommandozeilentool, also
kein Bugtracker mit Webinterface, bei einigen war der letzte Code Commit
vor 5 Jahren. Das ist also nichts, womit man seine eigenen Projekte
pflegen will.
Einige weitere Projekte sind Plugins für bekannte Bugtrackingsysteme
bzw. Commandline Tools für solche, die sicherstellen, dass der git
commit auch eine Bug ID enthält.
Manches Tool hat nicht die verteilte Fähigkeit, die ich suche.
Und eines ist sogar dabei, bei dem der Quellcode nicht mehr da ist, weil
der Hosting Dienst gitorius auf dem der Quellcode gehostet wurde,
eingestellt wurde.
Im großen und ganzen war leider nichts dabei was ich suche oder
zumindest meinen Erwartungen entspricht. Schade, aber trotzdem Danke für
den Tipp.
Nano schrieb:> Bei dem ich also bspw. eine Hauptinstanz habe.> Davon holen sich alle Teammitglieder die derzeitige Listen und Inhalte> zu aktuellen und geschlossenen Bugs, Issues und Todos runter.>> Lokal arbeiten sie dann mit einer eigenen Instanz der> Projektmanagementsoftware weiter.> In dieser können sie Bugs, Issues und Todos abarbeiten oder neue> hinzufügen.> Und irgendwann laden sie ihre Änderungen auf die Hauptinstanz wieder> hoch, also mergen alles.
evtl dokuwiki (mit lokalem server), gitbacked-plugin und evtl.
markdowku?
da dokuwiki nur mit text-dateien arbeitet kann man das auch (recht)
problemlos lokal ohne web-frontend davor bearbeiten/lesen/erstellen.
