Mixing real project and trial-and-error junk when evaluating Jira

[Svein Seldal]

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?

[Joe Pitt]

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.

[Svein Seldal]

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.

[AhmadDanial]

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.

Warm regards,

Danial

[Svein Seldal]

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:

• Run the trial with the combined trial-and-error sandbox and the production project
• When trial is over, we can export the production project only. (What happens to issue types, workflows, etc.?)
• We decide to purchase Jira and install it on a production server on a blank db (to avoid cluttering from the trial experimentation)
• Import the production project

Would this be possible?