I'm not sure I understand - development usually means code, so moving something from development to production is a case of uploading the .jar or .obr file
I suspect you mean the configuration of the system, which isn't really development. There's no easy way to move config from one Jira to another, so most of us do it by hand (and some of us just work in live with hidden projects because we are familiar enough to get away with it). But there are some plugins which allow some of it to be automated - I've recently glanced at the Botron system which seems to be very comprehensive - https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager
I meant configuration of the system, as you understand.
By hidden files you mean duplicate issues+duplicate projects etc, for each configured object?
Or that is enough to make a copy of the project? and all other object are ,maintained in it?
maybee an issue participate in more then one project?
(is it optionaly?)
I'm not sure what you mean by "hidden files".
I did mention hidden projects - create a permission scheme that says "only people with admin rights" and use that on a project where you can then experiment with whatever you need. Once the config of that works, you simply start using the schemes you made for it on other projects.
Thanks. What I m looking for is the option to reverse to a working version.
Due to a luck of experiense, I have difficulties to return to a "working version". I forgot what was changed in my "tests", and it is a wasted effort to "Start all over again".
So, is saving a project- saves all its related objects, like a backup (I suspect that not), so do I have to save a BACKUP for all the objects? Is there a version option for the JIRA configuration process (as is common in development projects)?
The option you suggested is also good, for hidding from userd, but it is partial, for my dificulties.
There is no audit, or reversal of changes in Jira. You make a config change, that's it, it's changed. Remember that this is configuration, not development. If you make a mistake, you carry on and correct it, there's little need to go back, you just need to go on and make it work.
If you want a backup, you take a full system backup and restore it when you need it. This is not great, and if you make a mistake in production, you use the backup to create a test system which you can then use as a point of comparison, but you still can't restore the config.
This is a long-standing flaw in Jira (and the rest of the Atlassian suite), they expect you to test in test and then replicate the config by hand in production. It's fine for people like me (who have been doing it for so long, we know we can undo most mistakes we make - and I do still make quite large ones), but it's very bad for most Admins because we can't test and transfer, we have to do it by hand. This is why I like the look of the Botron stuff...
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