I was wondering if you guys experience the same.
If you look at the JIRA enterprise website http://www.atlassian.com/software/enterprise/overview.html
you'll find the following:
Data-portability: simple import and export eases migration and protects your investment
From my point of view importing from a test environment to a staging or production environment is pretty cumbersomer, having to manually re-create fields, schemes etc. before you have the ability of an XML import. Staging is crucial to larger companies!
Many companies have very strict workflow standards and without developing plugins or putting much effort in custom coding you're not able to meet those requirements.
If If I'm wrong, please correct me, but instead of putting effort in "like buttons", basic needs like validations, deployment mechanisms for staging servers or field level security should be addressed when speaking of "enterprise".
I don't want to bad-mouth JIRA since I really like the software and couldn't imagine working without it, I just wanted to know (maybe from Atlassian) if anything is about to be done to address the problems mentioned above.
See, when you are asking your question with this impact phrase "the future or just a joke", all your arguments below - which are good - are going down the drain. So you manage to get everybody's attention, but overall you scare customers (and your own customers, too) since most of them do not read or understand what's below the title (yes, I'm a cynical misanthrope).
Hey Radu, you're right. Changed the title and deleted the intro...(could have been the title of a "Daily Sun" article:-)) It wasn't my intention to scare people but I wanted to know if others are facing similar problems. I mean you see people commenting on regular Atlassian documentation pages, but not that much. I'd be happy if someone said, well just do X and Z and you can easily deploy configuration changes made in a test environment to a prod server...but I can't find any of those comments.
P.S. By the way, I posted this question on behalf of my customer who needs like 100 validations :-)
Agree 100% with you, transporting JIRA project structures through DEV - QA - PROD has been simply disregarded so far by Atlassian but i know they are working on something that let's you capture changes on a DEV system and reapply them to another system. On Thursday i'll have the opportunity to meet Sven Peters and i'll address this again (besides Archiving, which is something that i'll need soon)
If you have large workflows, with 100+ validations, maybe it's time for you to try this:
It was specifically developed for these kind of problems, it's backward compatible and does not change between the versions (insert happy face here). We have aliases for custom fields (instead of naming it customfield_12345, you define an alias for it to move your workflow easily on some other instance)
We are also preparing this plugin:
Plus, with https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-workflow-sharing-plugin things are much better when carrying a WF on some other JIRA instance.
I'm currently evaluating the WF sharing plugin (JIRA 5.0.6) but until now I didn't get it to work. I'll keep trying:-) My problem is that I don't need those validators (and updaters) as part of a workflow transition. I need them to execute in real-time...
That's what I have now but regarding https://answers.atlassian.com/questions/49613/jira-5-1-inline-editing-how-this-will-work-for-you
there is a chance that the plugin won't be maintained in the future
Most of my feelings on the subject were typed into https://answers.atlassian.com/questions/38696/is-it-just-me-who-has-a-shocking-price-rise-for-jira-5
A shorter version would be:
Frankly, field security isn't that important to most customers, and there's a decent commercial plugin for those who really do need it, so I don't see Atlassian implementing it. It's not actually something that any of the "enterprise" customers I've dealt with really care about. The world is going in the opposite direction anyway - hiding information means silos, and most of them are more concerned with collaberation, "breaking down walls" and information sharing as it's more productive.
The enterprise features that come up again and again are clustering (not split and integrate, but proper clustering for resilience and load balancing), archiving, reporting and scaling/performance. Stuff like the dev/test/live migration would be nice. Field validation really needs work, as you've got here. Most places really want the long-outstanding "priorities per project" fixed as it's pretty much a no-brainer given that every other field can be configured per project.
I've spoken to Atlassian about most of this in quite some detail. There's a blanket refusal to deal with clustering (I can understand why), but they're looking at archiving in detail, site licenses, scaling/performance, and probably hoping those reduce the clamour for clustering. I wouldn't like to guess at timelines on these, but there is definitely movement on these things. The only worry is that all these features that would move Jira to be able to fit the label of "enterprise" will cost yet more.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs