Making the Move from Bugzilla to Jira
We’ve finally decided to make the jaunt at AE from Bugzilla to Jira, and it feels oh so good.
Lordy Begordy Why?
To be clear, Bugzilla was working for us. The world was not coming to a halt because of our antiquated issue tracker. It got the job done for years for our small dev team. As we started to grow, however, we began to notice patterns in the pain points we were coming across time and time again. We kept turning a blind eye to it, however, in favor of more pressing engagements. Finally, after our Holiday launch this year, and some much needed backing from our boss, Patrick, we were able to get the switch in the works.
There were a few things we knew we needed in our issue tracker, and a couple that we didn’t (but I’m happy to have anyway):
- Project tracking
- Integration with dev tasks and bugs
- Ease of edit-ability, be it users or global settings
- Release notes (and releases in general to tie issues with)
- Active directory integration (so internal users can log in with network credentials)
Setup and Bugzilla Integration
First, we setup an internal installation of the 30 day trial. This was nice, as it gave us pretty much all the bells and whistles to try out, as well as some time to look at how we were going to organize the future, and current, issue data. After our infrastructure guru Steve got active directory setup, were were off to the races.
We elected to create a legacy project for the outstanding issues left in Bugzilla. There were a few reasons for this. We wanted to keep the Jira setup as clean as possible, and there were many old, outdated issues in Bugzilla. Corralling these into one project would make it much easier to purge going forward. We headed into Administration > System > Import & Export > External System Import and selected Bugzilla. We were lucky, as our antiquated version just squeaked into the supported version list. After some fenangling to open up the bugzilla DB to remote connections, as well as just finding the connection info in the config files, we were off to the races.
The import went pretty well. We had to locate a good bit of the Bugzilla info in config files (thanks Steve), and many attributes in Bugzilla were either added, removed, or mapped to current attributes in Jira. This proved to be pretty simple, save for the bug priority level.
In Bugzilla, we had both priority and severity attached to issues. Severity noted the work level of the bug (major, minor, critical, etc.) and priority noted to the developer which bugs should be worked on first (P1-P5). This proved to be quite useless, and much too convoluted. Our solve was to map these to the default priority levels in Jira, and manage Tasks, bugs, etc. through those only. During the import, we mapped the following levels from Bugzilla to Jira:
- Critical,P1 > Critical
- Major, P2 > Major
- Major P4-P5, Minor P1 > Medium
- Minor, P3, P4 > Minor
- P5 > Trivial
A Few Other Extraneous Odds and Ends
The importer lets you map a custom field called External issue ID, which includes the bug ID from the old Bugzilla system. We will leave it up for a bit, so anyone working through a bug can reference the original if they need.
Finally, a note on organization. We decided to map our current components list in Bugzilla to labels in Jira. We did this because labels are project-agnostic. This worked best for our needs, as we keep a steady flow of numerous projects, and this allowed for users to easily view issues relating to certain pieces of the site regardless of the project. We are also starting to make the move to a more agile flow using the GreenHopper tool, but I’ll write more on that later.
Anyone else out there working with Jira or Bugzilla? We’d love to hear about your workflow!
Comments (11)
Leave a Reply
Greenhopper rapidboard is a excellent way to track your bugs etc.
Link to commentThanks Dipti! We’ve been using the Kanban board in Greenhopper, and I really like it so far. Haven’t made the jaunt to user stories yet, but soon…
Link to commentThe real power of Jira is connecting it the rest of Atlassian’s stack. We use the Jira key ex: “MYPROJ-123 some commit message” to bind code to the story or bug a developers working on. In this way anyone can quickly see the specific code a developer worked on referenced from the Jira ticket. Combined with Bamboo for continuous integration, it’s pretty killer.
Link to commentWe just set up Stash integration, and it’s working well. Bamboo is next!
Link to commentWe are also migrating from BugZilla to Jira right now.
We are only a two-man team, but since our responsibilities include development, testing, support and project management etc… (I call that a Micro-DevOps team), Jira is much more conducive to managing all of that in one place.
Still configuring the last bits and bobs, and importing our old issues from BugZilla is next on my list.
The tip to map BugZilla components to lables (tags) instead of Jira components is Genius! I can absolutely see your point there and we will do the same!
Great post!
Link to comment-Patrick-
Glad I could help Patrick! You can also map the components to the components in Jira as well. Either way, you can’t see them across multiple Jira projects, so beware of that. You may not run into that problem on a smaller team, however.
Link to commentI did create components first and thought to map them over. But most of our systems should be available in most of our projects (e.g. Support / Bug Tracking, new enhancement and development projects), since everything we do is related to at least one of them.
That’s why using labels (which should really be named ‘tags’, though) is a lot more convenient for us.
In fact, our various applications and systems used to be Products in BugZilla, now they are mere labels and it’s awesome (I’ve been playing with this all day).
Link to commentGreat to hear Patrick!
Link to commentThanks for this information. We have been using Bugzilla for 9 years and it has worked well. But now we are looking at other products because we need something that will integrate well with a support ticketing system. Can anyone share some information on what they use for their customer support agents to tracking issues and how that integrates into development tickets.
Link to commentI can’t speak to specifics Julie, but Jira has a number of plugins, as well as an api that might do the trick.
Link to commentThanks for the article, very useful (with 77 Projects)
Link to commentBut, there’s one that has been a pain…it has 33K bugs and when I try to import it with the tool, it crashed.
Any ideas?
I’m trying to split out this huge project into 30 mini-projects, another idea was to export BZ data in XML and then import it on JIRA (But I don’t know how).
I would really appreciate your help.
Thanks!