Parametric JIRA Workflow

Andrej Had

I have several teams which prefer Testing First approach, and several with Code Review First approach.

We have workflow (for several reasons) with 16 steps.
But this two approaches the rest of workflow is the same.

I'd like to have one JIRA workflow, with both "branches".

I would like to avoid situation with many workflows. As with growing customizations, number of workflow is rising exponentially.

Is it possible to somehow parametrize workflow to select one possibility for issue type and project ?

I know you can't add same status more than one time in the workflow.
So i was thinking to solve it via checks from transitions.

Something like:
1. Set this instance to be Testing First
2. When issue is Implemented and this is Testing First enable transition To Testing.
3. When issue is Tested and this is Testing First enable transition To Code Review.

 

This is diagram of the concept.

 

What is best approach ?

But, I don't know what is the best practice. As many workflows as team needs ?
What about propagating changes through many workflows ?

What about Workflow versioning, as it's impossible to have git as worflow storage .

We can use JMWE and Script Runner.

Trudy P Claspill

In my opinion...

Best practice is to minimize the proliferation of custom workflows. The more workflows you have, the more effort it takes to maintain them.

How can you minimize that proliferation? If you are working with Company Managed project then every project that needs  the same workflow should share a the Workflow Scheme or the individual workflows across multiple schemes, as much as possible.

As for the branching in workflows, if there is a way to set some criteria on the issues that need to follow each path (i.e. issue type, come custom field for categorizing the issues) then you can use Conditions on the workflow transitions to determine which issues have access to which transitions.

If you allow Team Managed projects you will have no control over the Workflows. They can't be shared with Team Managed projects, and users who have the Administrator role in the project can customize the workflows.