Sharing Workflows

[Norman Abramovitz]

I am looking to add some statuses for reviewing an issue and for integration into the production system from the staging system. I suspect these are common ideas that people have done before. Is there a place where users can find or share workflows? It is the transitions with the conditions and validations that I am concerned about messing up.

[brainicorn · Accepted solution]

I know this was already alluded to in an earlier comment, but I thought I'd post an answer anyway...

You can now share workflows with the JIRA Workflow Sharing Plugin.

We also encourage you to post any awesome workflow bundles you export the the Atlassian Marketplace!

You can get the plugin here:

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-workflow-sharing-plugin

You can get "Workflow Bundles" here:

https://marketplace.atlassian.com/plugins?category=Workflow+Bundles

And you can watch a video about it here:

http://youtu.be/XnsJWSAXTdA?hd=1

- Jonathan

[Mark Symons]

I read this question when I was posting my question about security issue workflows tonight and thought about mentioning the workflow sharing plugin.

I am glad that you encourage use of the Marketplace as a means to share bundles. Maybe something might pop up there for those security issues. Or how about something to handle unit/integration tests (where the validation and approval process might be different to how a defect is handled)?

It would be nice to see some more structure in how bundles are listed in Marketplace. For instance, would people always be able to see the licensing of contained plugins before downloading a bundle from the Marletplace? Not that I am averse to seeing bundles that contain plugins. In fact, I look forward to seeing the first bundle posted that does contain a plugin... because then the workflow itself is likely to contain some interesting validators or whatever. So far, the posted bundles are fairly vanilla (although I have only tested 2 or 3).

[Norman Abramovitz]

Atlassian just introduced a workflow sharing plugin. This might be the answer to how to build a repository of workflows.

https://plugins.atlassian.com/plugins/com.atlassian.jira.plugins.jira-workflow-sharing-plugin

[Dieter]

Thank's for the hint to this plugin ... Ihis will definitely help to share workflows here

[Norman Abramovitz]

Here is my suggestion about simplifying your workflow, but keeping all the functionality.

Maybe you can simplify things by using the resolution field concept that I used. When an issue has been verified it could back into open state but with a resolution of development ready. When the issue is assigned the transition can clear the resolution field. So most of your ready states could go away. So a state with a resolution means no work and state with resolution field cleared means work is in progress.

The "On hold" and dropped states would also be a resolution field value. You would be able to close issues that are on hold or droppped and still be able to find them. When they come back to life, they can be reopened. The open issue count could be more realistic when reporting and your number of states drop.

I hope this helps and good luck!

[Norman Abramovitz]

Wow, so many questions and here are my answers.

An issue enters closed state when the change actually makes it into the production system or when the issue is has no more life left(user error, etc). We use the bulk operation to move from integration to closed state. We select all effected issues and then we are able to apply the same comment and version information across all those issues that have made it into production. So a developer transitions issues into resolved state, QA transitions issues into integration state, and the release manager transitions issues into closed state. So closed state means we should have no more work to do and that is reason why integration is before close.

The QA team did not want an "in process" state, so we made it mandatory to enter a work log when they transition into integration state. At least we get a rough estimate of QA time.

Thanks for the suggestion about "return to research" and your reason makes sense.

We use the resolution field for the concepts of "on hold" and "dropped". In this way the state still records where we are in the workflow and the resolution tracks the current behavior. It seemed to go along with JIRA's concept of open and closed states. Also issues can be on hold, for example, in any state and the state diagram stays simplified. I thought about using the resolution for the research concept but decided against that since a different team could do the research (eg. customer support). So, in my case each group has a state while development has two states.

I believe this model makes reporting easier for outside people to see the current progress since most of the information can be gained by looking at state and the resolution fields. I also considered using a custom field.
The reopen state is a bizarre state to me. I am not sure why we could not go back to the open state, but that was in Jira's default workflow, so I did not change it. Maybe I can, since open is not an initial state.

[Beth Schaefermann]

Here is what we are working with for stories, but we have already received feedback that it is too cumbersome for some projects; so likely we will offer two flavors - light and heavy:

https://docs.google.com/open?id=0B2gWnl__ODJNMjRjZTg4YmQtYTFjNS00NjYwLWJhOWEtMjg5ZjVhZmFhMTE3

I had to turn-off the transitions, because it was unreadable.

[Beth Schaefermann]

That's kind of interesting, because we had a debate internally yesterday over adding an "Integration" state or a "Ready for Deployment" state after "Closed with Sign-off." The result was that we decided to rely on "Closed with Sign-off" to indicate that a story was ready for deployment/ integration and that we would rely on the version assignment and release state of the version to indicate actual deployment.

In your workflow, does Closure equate to client or client-proxy sign-off? Some sort of user acceptance? If so, I am unsure why you would want to enable movement straight from Resolved to Integration. I would expect to only be able to move from Closed to Integration. Otherwise, the Closed state seems unnecessary. Unless Integration is before Closed in your ideal flow?

You might want to reconsider "Reinvestigate issue" to "Return to Research." Using the same words to describe the action helps people to follow the flow and remember what state to which they are returning.

I am assuming that In Progress is inclusive of Development and Testing and that you do not have a need to identify whether or not issues are getting held up with any frequency in either sub-state.

Two states you might consider: "On Hold" for whenever work has to be stopped on an issue for any reason (dependency, unexpected or unplanned emergency), and "Dropped" in case your users to not have permission to delete issues.

If you use a Reopened state, you might want to consider changing the generic event fired in the post action to a more specific event. To ensure that your charts are accurate, you might want to double check all of your generic events. I would assume that Reopen should only be accessible from whichever state actually indicates closure, and then you might want to consider it as a transition back to open, instead of a state.

[Norman Abramovitz]

Here is my workflow adding a state before open and state after resolve.

http://www.wix.com/nabramovitz/jiraworkflow1

[brainicorn]

Currently, sharing workflow XML is tricky at best. The XML only contains the workflow and does not contain the layout.

On top of that, the workflow XML depends on status IDs which are set at status creation time. Therefore, if you import a workflow xml that has different IDs for statuses or contains status IDs that don't exist in the target system you will get strange results.

We have discussed ways to improve workflow export/import and sharing of workflows across instances but we do not have a full working solution as of yet.

[Beth Schaefermann]

I understand there are still strides to make in terms of explicit workflow sharing. Still, for the purpose of discussion regarding "does this process make sense" or "sharing this is how we are handling it - how are you handling it" simply uploading a screenshot of the workflow from the visual workflow editor would be fairly sufficient I would think. In fact, I think that's the greatest utility of the visual workflow editor.

[brainicorn]

Sure, makes sense. The Workflow Designer has a button on the toolbar to export a PNG of the workflow screen.

This should make it easy to share the image.

[Jo-Anne MacLeod]

The general idea of sharing workflow concepts works. But sharing the actual workflows (as in the xml files) are not going to work because there are so many different variables. What works for one instance doesn't work for another.

How ever you will see, where people have posted questions describing their problems and the user community will provide options for either how they solved a similar problem, or advice on where they can look for answers.

If you have a specific question post it, and lets see what we can come up with to help you. Well actually search on some of the key values to see if we may have already answered it in the past. If nothing already exists, then post a new question and we'll try and help.

[Norman Abramovitz]

I can imagine the issues, but it looks to me that the workflow is mostly self contained. The workflow plugins probably need to match, but otherwise it should import. I was able to export/import my workflows between my test and production machines using xml. I did lose my layout though :<( Your point is well taken though.

[Beth Schaefermann]

Just to clarify your question (for which I do not have an answer), are you looking for an open community like this forum where others have shared workflows they have created? Or are you looking to share workflows internally with your teams? I am assuming the former and would be interested in the same.

[Norman Abramovitz]

Thank you for your comment. Using your clarification, yes, I am looking for an open community like this form where others have shared workflows they have created.

[Beth Schaefermann]

The specific "workflow" you reference - moving from staging to production - sounds less like a workflow and more like an upgrade process. Atlassian has some support documentation for upgrades: http://confluence.atlassian.com/display/JIRA/Upgrading+JIRA When you are defining the movement from staging to production, it's likely that this still is not a "workflow" and is instead a series of tasks associated with a story to spin up an environment or install a plug-in; that is, unless this is some sort of special-case issue type where you are frequently logging migration requests.

If I have misinterpreted your need, and you are, instead, looking for examples of workflows, such as for closing a defect or resolving a support request, I would be happy to share.

[Norman Abramovitz]

It is really a poor person release management step. The developer 'resolves' the issue. The QA person then tests in the staging area and when completed states its ready for integration in production system. The issues stay in the integration state until it is time push it out to production. QA/Development can add test cases for those issues. Once the issue fixes gets into production, then the issue will be closed.

[Norman Abramovitz]

Sigh, I tried putting my workflow XML here but it did not work. It just hung when I hit the comment button.