CODEWITHSUNDEEP
processbug-trackingjirarelease-cycle
Peter Kahn
Peter Kahn

Reputation: 13046

How do I encourage code sharing and limit the bug tracking overhead while maintaining flexibility in my releases?

How are you tracking changes, testing effort for bugs that impact multiple artifacts released separately?

Code sharing is good because it reduces the total number of paths through the code which means more impact for fewer changes and less bugs (or more bugs addressed with fewer changes). For example, we may build a search tool and an indexer that use the same file handling package or model package.

We need to be able to ensure that changes get tested in all the right components and track which changes were included with which released tools. We also don't want to be forced to release the change in all applications at the same time.

Goal: one bug to be tested, scheduled tracked independently against each released application. With automated systems that understand the architecture guiding us to make the right choices.

Bug Split Release Scenario:

We may release a patch of the search tool that contains a performance fix in a util library. Critical for the search tool, the fix is less visible in the indexer so it can wait until the next maintenance release. We want the one bug to be scheduled-tracked-released with the search patch and deferred for the indexer's next maintenance release.

So, when I create a bug in our tracking system (JIRA) I want it to magically become multiple objects.

How can we make the user experience of code sharing low effort to encourage more of it without becoming blind to what changes impacted which releases or forcing people to enter many duplicate bugs?

I'm sure that large scale projects from Eclipse to linux distros have faced this kind of problem and wonder how they have solved it (I'm going to poke around on them next).

Do any of you have experience with this kind of situation and how have you approached it?

Upvotes: 0

Views: 208

Answers (2)

Chris Latta
Chris Latta

Reputation: 20560

In Jira you can allow sub-tasks so you could assign sub-tasks to the main task. You can also allow time tracking on the issues so you know how much time each task is taking and what the difference between estimated and actual is.

You can also enable versioning so you have a road map of what is being done in the next release with a change log. The problem with the road map is that it is only for one project so you can't have a road map that covers all of your projects.

Finally, you can create your own custom workflows to do almost anything you want to do. I've never tried this because we'd have to learn a new language to do it and the reason we got Jira was to decrease development overhead, not increase it by having to customise our bug tracker - but it is possible.

Upvotes: 1

Joe
Joe

Reputation:

For jira, make use of the affects versions and fixed in versions (plus you can add multiple custom fields, like verified by QA in versions)

Upvotes: 0

Related Questions