nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the best way to compare workflows?

Karie Kelly1

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!

Accepted answers

Peter T

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

All comments

rverschoor

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.

Peter T

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.

Karie Kelly1

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.

Karie Kelly1

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.

rverschoor

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.

Jirong Hu

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.

Dave Hollinden

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!

John Walker

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.

Darryl Lee

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.

Darryl Lee

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.

Darryl Lee

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.

Balázs Szakál [META-INF]

Hey,

Our app Glass Project Documentation for Jira is able to solve this problem!

We just released our newest feature: Jira Project Comparison, where workflows are compared as well!

You can export your config and upload on a different instance, and highlight changes!

Let me know if you have a question!

Best,
Balázs

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira