SmartGit

[Shade Of Mine]

pumuckl schrieb:

Als ich nach DVCS mit Bugtracking gesucht hab, kamen auch nur Fossil und Veracity als Ergebnis. Fossil hat mir auf den ersten Blick nicht so gefallen...

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

PS:
rebase ist dafuer da die commit history sauber zu halten.
Du arbeitest an einem feature und hast logischerweise 50mio commits - aber irgendwann ist das feature fertig. dann mergt du das features in den master branch und dank rebase hast du dann nur noch die wichtigen commits drinnen. weil es recht uninteressant ist dass du 20mal die types.h geandert hast weil du zwischen int und short gewechselt bist bis das feature komplett war.

ist natuerlich nicht ein killer feature und man kann auch ohne rebase leben, ich habe es noch nie gebraucht, war aber auch noch nie in so einer situation wo ich features unabhaengig vom master branch entwickelt habe.

[KuhTee]

Shade Of Mine schrieb:

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

Schon lustig. Denn argumente, die in diesem thread gegen smartgit aufgeführt wurden, waren in erster linie ja "Ich mag es nicht wenn die Sachen getrennt sind.". Auch von dir, gleich im ersten antwort post.

[lolhehe]

ich sehe überhaupt keinen grund darin, vcs und bugtracking zu kombinieren. denn bugtracking systeme nutzen ja nicht nur entwickler, sondern je nach projekt auch noch ganz andere personenkreise (PL, QS, keyuser, kunden etc). niemand von denen sollte auch nur in die nähe des vcs kommen!

mir reicht ne lose kopplung zwischen vcs und bugtracking vollkommen aus, indem man z.b. die task nummer in den commits oder branches referenziert. github hat darüber hinaus auch noch nette service hooks zu jira und co.

[EXDW]

TFS macht das sehr geschickt mit dem SCM -> Work items.

[pumuckl]

lolhehe schrieb:

ich sehe überhaupt keinen grund darin, vcs und bugtracking zu kombinieren. denn bugtracking systeme nutzen ja nicht nur entwickler, sondern je nach projekt auch noch ganz andere personenkreise (PL, QS, keyuser, kunden etc). niemand von denen sollte auch nur in die nähe des vcs kommen!

Warum nicht - wenn sie nur bei den Bugs Schreibrechte haben und sonst nicht, ist das doch kein Problem

Ein Grund, Bugtracking mit dem VCS zu kombinieren:
Nehmen wir an, Projekt X hat 5 branches. Ist bei DVS eher die Regel als die Ausnahme. Ein Bug taucht auf (Branch A), der Tester trägt ihn in den zentralisierten Bugtracker ein. Wenn ich Glück habe noch mit dem Hinweis, in welchem Branch er aufgetaucht ist. Ich fixe den Bug auf Branch A und trage das in den Bugtracker ein.
Einen Monat später. Der Bug taucht auf Branch B auf. Der andere Tester findet im Bugtracker den Eintrag und weiß, der Bug ist im Grunde gefixt. Nur warum ist er auf Branch B noch vorhanden? Und auf welchen anderen Branches? Im Bugtracker steht nicht, wo der Fix schon überall reingelaufen ist. Die Entwickler wissen erst recht nicht, auf welchen ihrer Branches der Bug noch vorhanden ist (schließlich haben sie andere Branches als der zentrale Server). Wenn der Fix aber zusammen mit dem Eintrag im Bugtracker im verteilten System liegt, dann wird der Eintrag "Bug gefixt" immer zusammen mit den Fixes auf die verschiedenen Branches gemerget.

Shade Of Mine schrieb:

rebase ist dafuer da die commit history sauber zu halten.
Du arbeitest an einem feature und hast logischerweise 50mio commits - aber irgendwann ist das feature fertig. dann mergt du das features in den master branch und dank rebase hast du dann nur noch die wichtigen commits drinnen. weil es recht uninteressant ist dass du 20mal die types.h geandert hast weil du zwischen int und short gewechselt bist bis das feature komplett war.

Den branch für das Feature brauche ich nirgendwohin zu pushen. Im Master branch gibts nur den einen dicken Commit, mehr sieht der zentrale Server und meine Kollegen nicht. Aber wenn ich später dann merke, dass ich vielleicht doch short statt int hätte nehmen sollen, bin ich froh, wenn ich die History noch hab.

[Shade Of Mine]

KuhTee schrieb:

Shade Of Mine schrieb:

Ich mag es wenn die Sachen getrennt sind. Weil ich mag ja VCS, Bugtracking, Wiki, Milestones, Forum, etc. haben. Das muss nicht alles im selben Tool drinnen sein. Denn die Wahrscheinlichkeit dass das eine Tool alle diese Features gut implementiert ist schon sehr gering.

Schon lustig. Denn argumente, die in diesem thread gegen smartgit aufgeführt wurden, waren in erster linie ja "Ich mag es nicht wenn die Sachen getrennt sind.". Auch von dir, gleich im ersten antwort post.

Nein.
Das sind 2 unterschiedliche Sachen.

Unterschiedliche Tools koennen trotzdem integriert sein. Eine IDE ist ja nichts anderes als eine Sammlung an Tools die sich miteinander integrieren. Daher auch der Name. Da gibt es Plugins die es ermoeglichen mehr Features zu haben -> zB eben Version Control.

Aber wenn das VCS nicht gut ist, nehme ich ein anderes Plugin. Darum geht es.

Integriert muessen die Tools miteinander aber dennoch sein. Ein Commit muss ein Ticket schliessen koennen. Aber dazu muss das Ticketing System nicht zwangslaeufig ein Teil des VCS sein.

[lolhehe]

sehe ich ähnlich. wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

was habe ich denn davon? spart es zeit? nicht wirklich. wenn ich 8h an einem task programmiert habe, breche ich mir sicher keinen zacken aus der krone, wenn ich noch manuell im bugtracker den task schließe, kommentiere oder jemand anderem zuweise. evtl. muss ich ja auch noch meine zeit dort buchen oder die versionsplanung machen für den nächsten release oder oder oder... alles sachen, die nix mit vcs zu tun haben.

solche eierlegenden wollmilchsau tools sind selten toll. was ist denn, wenn man morgen doch einen anderen bugtracker braucht, weil das tool nicht mehr alle anforderungen erfüllt? dann muss man sich gleich auch noch ein anderes vcs suchen. tolle wurst...

github hat btw. ungefähr 238949349 service hooks zur git integration mit anderen diensten, darunter auch viele bugtracker wie jira oder bugzilla.

[mezzo mix]

lolhehe schrieb:

wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

habe mich beim lesen von Shade of Mines kommentar allerdings auch gefragt, wie man vor dem commit sinnvoll testet und sich seinem ergebniss sicher sein kann, ausser man frickelt alleine an seiner software. zumal der entwickler den bug-report in der regel nicht selbst geoeffnet hat und deshalb auch nicht entscheiden sollte, wann er zu schliessen ist.

[EXDW]

Bei uns im TFS (Firma hat so 230 Leute) läuft es so:
- <Irgendwer> kommt daher und macht ein Work Item (Bug) auf
- Ein Entwickler Triaged das Problem (ist es wirklich eins, tritt es immer auf usw) und setzt es auf "In Progress" (evtl noch ein Assignment)
- Ein Entwickler behebt das Problem und Committed es zu dem Work Item (Changeset mit Branch und alles ist dadurch bekannt)
- Er schreibt in das Work Item rein was das Problem war und wie er es behoben hat
- Er setzt das Work Item auf "Ready for Test"
- Ein GM wird gebaut und sammelt alle Work Items welche dort rein flossen (Bugs, Tasks, Requests)
- <irgendwer> verifiziert alle angesammelten Work Items zu diesem GM
- Wenn nicht behoben wird es wieder Reopen mit ein Comment
- Wenn nicht wird es Close

Dadurch hat man im Work Item direkt das Changeset assoziiert, man kann rein sehen welche Dateien für den Fix angefasst wurden.
Man kann die History des Work Items durch sehen und jedes Changeset diffen, direkt öffnen usw - ohne das man manuell Sachen hin und her kopieren muss.

Continuous Integration ist dadurch sehr einfach.
Z.B. läuft ein Build automatisch sobald zu ein paar Work Items was assoziiert wurden (oder gar bei jeder Assoziierung), und hat direkt alle Informationen beisammen was in den Build rein floss.

"Oh, ein neues Build - mal schauen - OK, Bug 1, 4, 9 und 15 sind darin gefixt wurden, das kann ich Testen"
Das geht alles Automatisiert ohne das ein Mensch die Comments noch durch lesen muss ^^

[lolhehe]

wir arbeiten so (tools: git, github, jira):

- bugs, features und change requests werden in Jira erfasst
- der jeweilige teamleiter macht die release planung: welche task wird in welcher version gemacht?
- während des sprints werden die tasks für die kommende version bearbeitet
- der entwickler legt sich einen branch an, z.b. task-123 (der master branch ist immer stabil und kann deployed werden)
- features branches werden ins zentrale repository gepusht (github)
- wenn das feature fertig ist oder wenn der entwickler feedback von anderen entwicklern braucht, erstellt er einen pull request für den branch
- jeder entwickler hat jederzeit einblick in alle pull requests und kann kommentare und verbesserungsvorschläge schreiben
- sobald das feature fertig ist, gibt es ein finales code review des jeweiligen teamleiters. wenn alles ok ist, werden die änderungen aus dem feature branch in den master branch gepullt
- von jedem branch kann jederzeit mit einem befehl eine testversion gebaut werden
- mit einem jira service hook kann der status einer task in jira per commit geändert werden (z.b. status auf gelöst setzen)
- continous integration server testet und baut alles, was in die master branches gepusht wird

ich sehe nicht, wo stärkere integration des bugtrackers ins vcs hier arbeit erleichtern sollte.

[Shade Of Mine]

mezzo mix schrieb:

lolhehe schrieb:

wobei ich es nicht mal für notwendig halte, dass ein commit direkt eine aktion im bugtracker auslösen kann/soll.

habe mich beim lesen von Shade of Mines kommentar allerdings auch gefragt, wie man vor dem commit sinnvoll testet und sich seinem ergebniss sicher sein kann, ausser man frickelt alleine an seiner software. zumal der entwickler den bug-report in der regel nicht selbst geoeffnet hat und deshalb auch nicht entscheiden sollte, wann er zu schliessen ist.

Naja, ist halt die Frage wie gross deine Software ist. Bei uns arbeiten vielleicht 3 Leute daran wenn es mal viel sind. Da ists sehr leicht sowas zu machen.

Ausserdem sollte man sowieso einen Test fuer einen Bug haben, wenn der Bug reproduziert werden kann, kann er mit einem Testcase als geschlossen bewiesen werden.

Wenn man natuerlich oeffentliche Bugtracker hat, ists komplizierter.

Aber ich habe dennoch explizit Ticket und nicht Bug gesagt. Denn ein Ticket kann weitaus weniger kompliziert als ein Bug sein. Ein Ticket kann zB "Kommentare in Datei foo.hpp fixen" sein.

Weiters muss man nicht zwangslaeufig ein Ticket schliessen mit einem commit, aber man sollte ein commit an ein Ticket haengen koennen. Das ist oft praktisch.

Je nachdem wieviel Leute mitarbeiten braucht man natuerlich unterschiedliche Abstraktionsebenen. Dann muss ein commit zB anstossen koennen dass jemand das Ticket neu begutachtet und schaut ob es jetzt geschlossen werden kann.

Wir sind wenige Leute, deshalb machen wir alles selber Bei 230 Programmieren wird alles natuerlich komplizierter...

[lolhehe]

Shade Of Mine schrieb:

Weiters muss man nicht zwangslaeufig ein Ticket schliessen mit einem commit, aber man sollte ein commit an ein Ticket haengen koennen. Das ist oft praktisch.

jo. wobei es imo schon ausreicht, die task nummer in die commit message zu schreiben. wenn man den task später noch mal bearbeiten muss, kann man ja einfach die commit history durchsuchen.