Migrating to JIRA – Technical

When migrating from ClearQuest to JIRA, there are some several technical pitfalls which one may encounter. In this post I will detail the main issues which I tackled during the migration process.

The general strategy is to use as much of the built-in JIRA fields as possible, since many abilities and plug-ins uses them by default (such as JIRA Agile). It required effort, but it certainly paid off.

Let’s discuss the details, then:

Continue reading

Advertisements

Migrating to JIRA: Retrospective

It’s been over a month since we deployed JIRA as our issue tracking tool, replacing IBM Rational ClearQuest.

It took me a few months to prepare for this move. At first I thought it would be a good opportunity to make some very needed changes in our issue tracking processes, but later on I realized it would be too much for the users, to handle both a new tool as well as major process changes.

Hence, the guiding concept for this migration was: let’s make it as close to our ClearQuest schema as possible (fields, workflows, screens, etc.). Then, as time goes by and we get to know JIRA better, we can make any changes we want to improve the process.

One exception to this was later added – try to adhere to JIRA’s ‘vanilla’ objects (fields, states, etc.) as much as possible. This is because many charts, reports, add-ons (e.g. GreenHopper) and other items expect certain fields or statuses to be present in order to utilize them properly.

Here’s how I prepared the migration:

Continue reading

Workflow Considerations

While evaluating ClearQuest to JIRA migration, I noticed there are some major differences in their default defect tracking workflows. They have different approach to even the most basic issues such as assigning or reopening a defect. In this post I would like to focus on some of the key differences, and suggest my opinion about them.

Before I start, you may ask why do I care about the default workflows? Every modern issue tracking tool is very customizable, after all. But the way I see it, the default workflow say something about the tool developers and their vision of defect tracking, so it may be something interesting to look at.

Continue reading

Set field requiredness in JIRA based on another field

I am new to JIRA, currently evaluating if we could use it as a replacement for ClearQuest.

One of the early challenges I encountered was to perform the task mentioned in the title. Specifically, when the other field is a checkbox. Let’s say we have a checkbox called ‘Related Document’ and a textbox called ‘Document name’. If the checkbox is ticked, then the user must supply the document name, and if the checkbox is cleared, then the text field should be read-only.

In ClearQuest it’s quite straightforward:

  1. Create a perl script as the ‘Value Changed’ event of the ‘Related Document’ field.
  2. Add the following code to the script:
 my $value = $entity->GetFieldValue($fieldname)->GetValue();
 if ($value)
 {
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_MANDATORY);
 }
 else
 {
   $entity->SetFieldRequirednessForCurrentAction("DocumentName", $CQPerlExt::CQ_READONLY);
   $entity->SetFieldValue("DocumentName","");
 }

In JIRA, it’s a bit more involved:

  • In ClearQuest, you define a field, and then attach it to a widget. In JIRA, the field type is also the widget, and usually it’s impossible to change it once set. So I need to use a checkbox-type field.
    There is no ‘single checkbox’ field type in JIRA, so I created a multi-checkbox field called “Documentation” with a single option, “Related Document”.
  • There isn’t an easy way to add ‘Value Changed’ events to fields in JIRA itself; I installed a plugin, called ‘JIRA Behaviours Plugin‘, which adds a lot of customization abilities.
So here’s what I did after creating the relevant fields and installing the plug-in (This took a bit of trial-and-error until I got it right…)
  1. Add a new Behavior (Administration > Plugins > Behaviors)
  2. Add the checkbox field to this behavior, and within it, add the following server-side validation script:
FormField relDoc = getFieldByName("Documentation")
String val = relDoc.getValue()
FormField docName = getFieldByName("Document Name")
if (val == "Related Document") {
 docName.setReadOnly(false)
 docName.setRequired(true)
} else {
 docName.setReadOnly(true)
 docName.setRequired(false)
 docName.setFormValue("")
}

It all seemed to work, except that when you initially open the form, the text field is enabled even though the checkbox is not marked. So, I edited the behavior, added the text field, and set it as ‘read only’.

Configuring JIRA is a very different experience than ClearQuest, both in concept and implementation; I’ll post more general CQ vs. JIRA thoughts later this month.