JIRA und SVN Subversion /Tortoise

[bernhard_LA]

unser Software Entwicklungsprozess ist vermutlich ziemlich ähnlich zu Euren

• Kunde kommt mit einem Bug oder Feature Request, dh. ich erstelle einen Eintrag in Jira
  
• wir arbeiten an der Problemlösung, erstellen eine neue Funktion, Source Code Dokumentation via Documentation Insight
  
• Den neuen Code via Tortoise auf den SVN Server spielen, dazu einen hilfreichen Kommentar dazu tippen
  
• sich die neue SVN revisions Nummer merken und jetzt den nächsten Kommentar in Jira eintippen ( Jira Ticket abschließen .....)

Frage : kann man SVN und JIRA verheiraten, kann ich meine Source Code Doku automatisch als Jira LOG verwenden oder ....

[Uwe Raabe]

Meinst du sowas? Integrating JIRA with Subversion

[bernhard_LA]

Genau sowas :-) Hast Du hiermit Erfahrungen oder sonstige Tipps ?

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1326991)

Hast Du hiermit Erfahrungen oder sonstige Tipps ?

Nicht mit SVN und JIRA, aber ich benutze das ständig mit Kiln(Mercurial/Git) und FogBugz. Zugegeben, die Integration gibt es dort quasi eingebacken, aber die ist sowas von genial!

[Der schöne Günther]

Wir haben überhaupt keinen dedizierten Bugtracker oder ähnliches. Was habt ihr für ... Mengen an Anforderungen? Tragen da nur Entwickler etwas ein, oder auch Leute aus dem Support oder gar Vertrieb?

Wir vermerken auch nicht die einzelnen Revisionsnummern, sondern nur das Release ab wann etwas umgesetzt wurde. Muss man das wirklich so genau wissen?

[vagtler]

Wir verwenden auch Jira als Issue Management System und in Verbindung mit Service Desk auch als Bugtracker. Dabei können in den Bugtracker sowohl Endkunden als auch interne Mitarbeiter Fehler melden, Features bzw. Anforderungen in Jira (als User Story) nur Produktmanager bzw. Product Owner und Tasks die Entwickler. Der Vertrieb hingegen arbeitet mit einem eigenen Jira-Board, das einen entsprechenden Workflow für neue Anforderungen hinterlegt hat - daneben gibt es ein Board mit einem anderen Workflow für die Angebotserstellung für den Vertrieb durch das Back-Office.

Und ja, gerade im Zusammenhang mit Bugfixing zum Controlling der vereinbarten SLAs halten wir Commits sehr genau fest. Das in Verbindung mit einem entsprechenden Branch-Management (hier Gitflow) ist schon ziemlich effektiv.

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1326999)

Wir haben überhaupt keinen dedizierten Bugtracker oder ähnliches. Was habt ihr für ... Mengen an Anforderungen? Tragen da nur Entwickler etwas ein, oder auch Leute aus dem Support oder gar Vertrieb?

Wir vermerken auch nicht die einzelnen Revisionsnummern, sondern nur das Release ab wann etwas umgesetzt wurde. Muss man das wirklich so genau wissen?

Ich mache seit einiger Zeit überhaupt nichst mehr ohne Bugtracker. Die Fälle werden dort entweder direkt von angemeldeten Benutzern eingetragen oder kommen per Mail oder von madexcept dort rein. So wird nichts vergessen (es gibt zumindest einen Eskalationsbericht) und man kann später nicht nur nachvollziehen was aufgetaucht ist und wann und in welcher Version es behoben wurde, sondern hat wegen der (ich sagte es bereits) genialen Integration auch direkt aus dem Fall heraus das ChangeSet mit den Source-Änderungen ansehen. Was weiß ich denn noch, was ich vor einem halben Jahr so alles gemacht habe.

Der Bugtracker hat auch den Charme, daß immer jemand gerade zuständig ist. Ein behobener Fehler wird automatisch an den Fehlermelder zugewiesen (außer per Mail/madexcept), der dann für die Validierung zuständig ist und den Fix zurückweisen oder den Fall schließen kann.

Bei einem Release bekomme ich vom Bugtracker auch ohen großen Aufwand die Release-Notes mit den behobenen Fällen ausgespuckt. Man kann sich damit die Arbeit schon sehr erleichtern - gerade wenn man so eine One-Man-Show hat wie ich...

[generic]

Wir haben uns Mantis zum Teil integriert.

Bei tortoisesvn gibt es ein COM-Server welche implementiert werden kann, der die Kommunikation sicher stellt.

https://tortoisesvn.net/docs/release...ugtracker.html