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!
Leave a Reply