Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

What is the best way to compare workflows?

Does anyone have a suggestion on how best to compare two workflows to see differences?

This is helpful when you have one you are testing out and making changes and need to compare it to production to know the differences so that you can modify vs recreate the new workflow in its entirety.

We tried the export workflow, but that just creates an unreadable file for import.

And, even if we could read it, we don't know if it includes any validators, conditions, post functions, and properties since the import doesn't import ANY of those (different story..but, not sure of the import's value when it doesn't import all the details).

And, yes, the workaround is two screens, side-by-side, painfully going through each workflow step and transition and manually comparing the properties, conditions, validators, and post functions.

Any other ideas though would be most helpful!

5 answers

1 accepted

2 votes
Answer accepted

Hello Karie,

our add-on Configuration Manager for JIRA

https://marketplace.atlassian.com/manage/plugins/com.botronsoft.jira.configurationmanager

enables you to automatically deploy changes from one JIRA instance to another, so you can implement automatated roll-out of the JIRA configuration from Test or Staging server to Production.

During the deploy there is a step in the UI that visualizes all the differences between the configurations of the Testing and the Production server. The diff UI works for all configuraiton objects in JIRA including workflows. The differences displayed for workflows specifically include validators, conditions, post functions and properties. In the screenshot example below you can see the differences between two workflow are one condition, postfunction and property were added, in addition to that the add-on does impact analysis to show how many projects will be affected.

Let us know if you are interested, if you have additional questions at support@botronsoft.com. In addition we can do a Live Demo of the add-on where you will see it in action and ask any questions that you might have.

--Peter T

Hi Peter -

That looks to be a very powerful plugina and could certaintly satisfy what we are looking for. Unfortunately, for this year, it is not in our budget as it is a bit pricey at $4k for us. But, will certainly consider it for next year's budget. Thanks for the recommendation.

I used to export the workflows as XML.
Not the easiest file format to compare for humans, but it sure beats clicking through the UI.

We did try the XML export because we were wiling to try it; however, we could never get a program to open the file. We are on a mac and it wanted to open in Parallels in our Windows side, but we kept getting errors it couldn't open it.

There are specialized XML editors/viewers.
However, as XML is just plain text you can open it with any simple editor.
I use TextWrangler or Sublime Text on my Mac.

There are also specialized XML diff applications that make it easier to compare XML files.

Using a tool like Oxygen Xml editor is good for doing diffs on Xmls. However, it is a little expensive. Other diff tools are available.

For me I did not just want to compare the workflows, I wanted to see which ones were the same - so that I could de-duplicate duplicated workflows. 

Assuming admin permissions to be able to view and export workflows.

I did this on my MacOS laptop by:

  • Navigate to Jira > Jira Settings > Issues > Workflows
  • Open each one up (in a new tab) 
  • Download each workflow as Xml into a temporary folder
  • Use a Text Editor to strip out the
    jira.updated.date
    element (which varies even on Workflows of identical structure)
    <meta name="jira.updated.date">1525947933167</meta>
    • Tip A: Most good text editors can do a find and replace on multiple files at the same time
    • Tip B: You can use the following regular expression to find all cases of that tag whilst ignoring the contents:
      <meta name="jira.updated.date">\d{13}</meta>
      Note the "\d{13}" pattern for 13 digits within the contents of the element.
  • Then open MacOS Terminal, navigate to your folder of Workflow Xmls and run a command to get the MD5 hashes of each file like so:
    •  find . -type f -exec md5 -r '{}' ';' | sort > md5hashes.txt
  • Then, open up the md5hashes.txt text file and copy the contents into a spreadsheet. (Bonus: If you had replaced spaces with tabs then the data would map neatly to columns).
  • Then, sort the spreadsheet data by MD5 hash.

If two files share an MD5 hash they are (highly statistically likely) to represent identical Workflows, if they don't then the Workflows are different in some way.

When I did this, I found I had many Workflows which were identical to either one of two formats. The remainder varied. I marked them up as either Type A, B, C,etc for convenience.

  • Hash Type Workflow
  • 17a64a5654017c19a89036e367b6c8c7 A ./Software Simplified Workflow for Project a.xml
  • 17a64a5654017c19a89036e367b6c8c7 A ./Software Simplified Workflow for Project b.xml
  • 17a64a5654017c19a89036e367b6c8c7 A ./Software Simplified Workflow for Project c.xml
  • 17a64a5654017c19a89036e367b6c8c7 A ./Software Simplified Workflow for Project d.xml
  • a338d18c0ca488d090205925c749f3b4 B ./Software Simplified Workflow for Project h.xml
  • a338d18c0ca488d090205925c749f3b4 B ./Software Simplified Workflow for Project i.xml
  • a338d18c0ca488d090205925c749f3b4 B ./Software Simplified Workflow for Project j.xml
  • a338d18c0ca488d090205925c749f3b4 B ./Software Simplified Workflow for Project k.xml
  • a338d18c0ca488d090205925c749f3b4 B ./Software Simplified Workflow for Project l.xml
  • ed813d879decdc4ce321282fe6daca9b C ./Software Simplified Workflow for Project m.xml
  • 6692c2b1f79bac16ea14f1c37b18dd3a D ./Software Simplified Workflow for Project n.xml
  • 7b24784c075950925a6c8d97530b651f E ./Software Simplified Workflow for Project o.xml
  • 898e5b988558774442433622efc80029 F ./Software Simplified Workflow for Project p.xml
  • cdfc2f0b38b67abef2ea894242a24286 I ./Software Simplified Workflow for Project q.xml
  • dcd563058fcf795c0308f4b3548d0ee9 J ./Software Simplified Workflow for Project r.xml

So, given this information I found it useful to see which Workflows could be merged into one.


Hey - I used this technique to "compare" screens, many of which were duplicates.

Screens can be downloaded as JSON files by hitting the API:

https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-screen-tab-fields/

The tricky part is I first had to get the Ids of the tab(s) for each screen. Thankfully on this instance, they had not done more than one tab per screen.

https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-screen-tabs/#api-group-screen-tabs

Anyways, I used CLI's renderRequest and Excel to generate a list of screen names, and Ids for screens and tab, then iterated through that list in Perl, passing them each to another renderRequest call to get a nice list of JSON screens:

acli -a renderRequest --type JSON --request '/rest/api/3/screens/${screenid}/tabs/${tabid}/fields' --file '${screen}.json'

Then it was md5 funtime, which is very similar to what John did above, but I didn't need to strip out a unique date or anything.

As a sidenote, if you have a lot of workflows, it would be way faster to use CLI to download the XML files than going through the UI.

You can use CLI to get list of all workflows here:

acli -a getWorkflowList > workflows.csv

(Weirdly the list includes deleted ones. That's ok. If you export these, they're 0 length, so easy to delete.)

Anyways, then you'll can use the exportWorkflow action to download the workflow:

acli -a exportWorkflow --workflow '${workflow}' > '${workflow}.xml'

Bob says this should be compatible with runFromWorkflowList. I can't remember if I tried it, but I ended up parsing and then iterating through the list with Perl.

Ah, this worked:

acli -a runFromWorkflowList --common "-a exportWorkflow --workflow \"@workflow@\" --file \"@workflow@.xml\"" --continue

The --continue gets you past the errors about deleted workflows that don't exist.

Like John Walker likes this

Any update on this issue? I just joined a new company. There is v5 in production and v6 in the development server, want to know what's the differences.

Export the two workflows as XML. 

Open the XML docs in TextEdit or other text editor. 

Go to an online diff checker website such as https://www.diffchecker.com/

Copy and paste the contents of the XML docs into the two diff checker fields. 

Click Find Difference!

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you