The cookbook is for migration because most people want to move off Clear Quest and on to Jira. Ideally, you should choose to drop one of them completely and migrate to the better one.
However, to "integrate" them, you need to decide exactly what you mean by "integrate" - it's far too vague a word to start from. "associate CQ defect with Jira iteration (version)" is far more useful, but you need to define what that association should do - how does it look to the user on either end? How is it stored in the two systems?
I'd propose two approaches, although there's probably more, and plenty of variations.
1. Simple linking. In Clear Quest, create a field for "iteration" and write a REST connector so that it can read the list of versions/iterations from Jira to allow people to populate it. In Jira, you'd need to write a panel or report or some way to display the results of a Clear Quest query "all items with field set to this version"
2. Duplication - create bugs in Jira on a 1-to-1 basis - each bug in Clear Quest is a bug in Jira too. A bit of code in Clear Quest to trap new bugs there and poke them into Jira would do the trick, along with something to trap changes and replicate them to Jira. You could make the issues non-editable in Jira, or better, allow people to edit in Jira and have a listener that pushes the changes in Clear Quest (of course, the logical extension of this is to do everything in Jira and drop Clear Quest completely...)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.