Motivation
...
how massive a project/workflow is (N_issues)
how dependent a project/workflow is on apps (N_REFS, N_DREFS)
is it current or outdated project/workflow (Latest Creation Date)
print out the generic workflow diagram
get representative issue tickets to drill further via IssueStepsTimeMachine tool
find the “driven-by-Mercury” Jira actions (all steps where username='squid')
use these params to show/hide/filter a specific field:
workflow_name=show | hide
issue_type=show | hide
app=show | hide
app_widget=show | hide
post-functions, validators, actions, etc - magical bits of automation trigerred implicitly behind the scene (send email, update custom field, create a new issue in another project, etc)
app_filter=all | atlassian | non-atlassian
“atlassian” app_widgets are believed to be easy to migrate since Atlassian is behind it
“non-atlassian” app_widgets are believed to be harder to migrate since 3rd party smaller vendors are behind it
filtered-apps N_REFS are still rolled up even if app=hide param is applied
wf_component_type=show | hide
in addition to “steps” a workflow could also have post-functions attached to “global-actions”, “common-actions” or “initial-actions” - all these are collectively called “workflow_components“ (or wf_components)
wf_component_type_filter=all | steps | global-actions | common-actions | initial-actions
filtered wf_omponent_types N_REFS are still rolled up even if wf_omponent_types=hide param is applied
how far in the past to look: days_to_look_back=4000
which Jira instance: jira=labopsjira | gpinfojira
project to look into: project=all|decisions_only | LCSET
“decisions_only” instructs JiraInspector to pre-filter only the projects destined for migration https://docs.google.com/spreadsheets/d/1slTstgaKmvBbJv-wXHVhfhINPqOsKk7f9EyTnE3-sLo/edit?usp=sharing
do you want to look into the browser or download to CSV: format=html | csv | tsv
actual_status_coverage=show | hide
group issues by actual statuses a ticket has gone through, it will also produce all users involved
...
Total N_REFs grouped by Workflow across all “destined to be migrated” projects, across all non-atlassian apps.
https://analytics.broadinstitute.org/JiraInspector/ProjectWorkflows?order_by=project&issue_type=hide&app=hide&app_widget=hide&project=decisions_only&jira=labopsjira&wf_component_type=hide&wf_component_type_filter=all&app_filter=non-atlassian&days_to_look_back=4000&actual_status_coverage=hideTotal N_REFs grouped by Workflow and “wf_component_type” across all “destined to be migrated” projects, across all non-atlassian apps.
https://analytics.broadinstitute.org/JiraInspector/ProjectWorkflows?order_by=project&issue_type=hide&app=hide&app_widget=hide&project=decisions_only&jira=labopsjira&wf_component_type=show&wf_component_type_filter=all&app_filter=non-atlassian&days_to_look_back=4000&actual_status_coverage=hideTotal N_REFs grouped by Workflow, “wf_component_type” and “app” across all “destined to be migrated” projects, across all non-atlassian apps.
https://analytics.broadinstitute.org/JiraInspector/ProjectWorkflows?order_by=project&issue_type=hide&app=show&app_widget=hide&project=decisions_only&jira=labopsjira&wf_component_type=show&wf_component_type_filter=all&app_filter=non-atlassian&days_to_look_back=4000&actual_status_coverage=hideTotal N_REFs grouped by Workflow, “wf_component_type”, “app” and “app_widget” across all “destined to be migrated” projects, across all non-atlassian apps.
This is one of the most granular datasets, a variety of rollups can be generated off it.
https://analytics.broadinstitute.org/JiraInspector/ProjectWorkflows?order_by=project&issue_type=hide&app=show&app_widget=show&project=decisions_only&jira=labopsjira&wf_component_type=show&wf_component_type_filter=all&app_filter=non-atlassian&days_to_look_back=4000&actual_status_coverage=hideTotal N_REFs grouped by Workflow and Apps across all “destined to be migrated” projects, across all non-atlassian apps.
https://analytics.broadinstitute.org/JiraInspector/ProjectWorkflows?order_by=project&issue_type=hide&app=show&app_widget=hide&project=decisions_only&jira=labopsjira&wf_component_type=hide&wf_component_type_filter=all&app_filter=non-atlassian&days_to_look_back=4000
...
All the ProjectWorkflow information is derived from the so the called Worlfkow descriptor XML recorded in Jira database. While some of this information is exposed in Jira’s Workflow pages, there is also a lot of information (like app dependencies) that is not visible in these pages. Also, even for the info available it would take dozens of clicking on multiple confusing pages to get to the info you need. So, a “bottom-up“ approach seemed an interesting option where we extract all the XML descriptors, parse out all the data, flatten it out into a table and make it available for further SQL-supported discovery JOINing with the rest of our discovery-datasets.
Don’t worry - even if just a small percentage of this dissection sticks with you it would still help you a lot when leveraging the JiraInsector “discovery“ tools.
analytics.broadinstitute.org/JiraInspector/WorkflowDescriptor?jira=labopsjira&workflow_name=LCSET Workflow with Plating
Let’s dive into a workflow descriptor XML to see how this works:
...
Every place in the Workflow XML where a post-function (or validator or condition) is mentioned we call it an “app-reference”, or just “reference”. While decoding all the references might seem like a daunting task, a lot can be discovered just by counting the “number of references” (N_REFS) rolledup by APPS, by Projects, etc. Every “reference” is a potential drag on the migration.
”Migrating a project” boils down to migrating over all the “workflow widgets” (post-functions, validators, conditions, etc) for that project, so the greater the N_REFS is the more difficult it is.
Another interesting metrics is the number of apps those N_REFS are distributed over. (for example “10 N_REFs supported by 3 apps” might be more difficult than “20 N_REFS linked to only 1 APP”)
...
How difficult to migrate my project is ? (could be read as “what are the chances of successful migration”?)
What is the N_REFS number for it ?
Is the N_REFS distributed across multiple APPS ? Which APPS ?
Are these APPS marked by JCMA as “Stage1” or “Stage2” , “Stage2” or “Not supported in Cloud“?
What remedies might be available for these features (app-widgets) which are not supported in Cloud ?
If it turns out it’s very difficult and/or expensive, shall I contact my stakeholders and discuss if we could give up that feature?
...