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:
issue_type=show | hide
app=show | hide
app_widget=show | hide
post-functions, validators, actions, etc - magical bits of automation trigerred triggered 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
...
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.
-- all the “custom fields” for that project
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 supported by only 1 APP”)
...
How N_REFS can be leveraged:
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”, “Stage2” or “Not supported in Cloud“?
What remedies might be available for these features (app-widgets) which that 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?
...