We are currently evaluating Jira and have installed it on our server. We use it to play around with its functions. We have realized that the only way to really evaluate Jira is to use it on a real production project.
The problem I forsee is that we get a db which partly consists of a production project that we need to keep when we go live, and partly a db full of trial-and-error junk that we certainly don't want to keep.
Ideally, a second test instance would allow us to distingush between trial-and-error experimentation and real production project use. However AFAIK you cannot get a dev license under the trial program.
Any ideas of how we should address this? E.g. can we export specific parts of jira (say a project) and import it into a new fresh db?
An easy way is to use separate projects. Only allow a limited group of folks access to the 'test' project they can use as a sandbox. You can apply workflows, screen schemes, etc. by project so you can test anything in the sandbox without impacting the real projects. Then you can simply delete the test project and all the data if you want to. I always keep a test project in the production instance to test workflows and screen schemes. It is much easier than trying to reproduce the workflow in the production system. Export/import has limitations. We only use the test instance for trying out new versions and plug-ins.
If I create a test project and later delete it, does this cause cluttering in the db?
Because we are testing Trac and Buzilla imports, and the first run created lots of invalid users and the test-import projects and users were later deleted. My experience with databases is that nothing is really deleted, just deactivated/hidden. Thereof the fear of cluttered db's by doing multiple imports-then-delete cycles.
Hey there, Svein.
First and foremost, we definitely advice users to not have two instances connected to a single database (https://answers.atlassian.com/questions/15984/can-we-run-jira-on-multiple-application-servers) and yes, you are only eligible for the developer license when you are using the commercial or academic licenses.
In this case, you can do a project import and import it to a instance, not a fresh database. If you were to do this, you will eventually import the whole backup, not project specific. (https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup)
Mind you that you have to pay attention to every detail of the steps. It is important to ensure a smooth process. Good luck.
I was not thinking of having multiple jira instances towards one db, so that's ok.
IMHO it's a limitation that we need to combine the experimentation and the production project into the same db. As a part of the experimentation you can (intentionally or unintentionally) change settings which you perhaps don't want to keep in a production db. That's exactly why you have a test sandbox to go wild. To be able to successfully evaluate Jira within the limited time we have, we really need to have both go-wild experimentation and real project activities. But we only want to keep the latter.
So if I understand it correctly, we can do the evaluation this way:
Would this be possible?
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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