Test Environment

How difficult is it to setup a test environment; and how to transfer to production

1 answer

1 accepted

Jen,

I'm not sure if you're doing this in JIRA Cloud or on a server. If Cloud... can't help you there. If it's on your own server I do this all the time myself and it is, with JIRA, surprisingly easy. The steps I take are:

  1. Build a brand new, totally empty JIRA server of the version you want (same as production or whatever you want to try to update to).
  2. Once you get it up and happy and can log into and see the empty JIRA instance, shut JIRA down.
  3. On your source production system, run the XML backup
  4. Copy the <jira-data> directory from the source production in its entirety to your target test system replacing the <jira-data> directory created by the base JIRA instance install
  5. Move the export created from <jira-data>/export to <jira-data>/import
  6. Change the ownership of the directory and contents to whatever user you run JIRA as. If you don't you'll get an epic failure to start.
  7. Start the target test system JIRA instance. You still don't have your clone back quite yet
  8. Import the file you just exported to the system
  9. When the system settles down you have a clone of the system

NOTES:

  1. The above assumes that you are running the database on the same server as your JIRA instance, the host you are pointing to is "localhost" or "127.0.0.1". If you have a FQDN for your datasource even if it is local to your JIRA instance OR you point at an external DB server CHANGE THE DB CONFIG IN <jira-data> BEFORE YOU START JIRA. Other wise you'll bork your production data.
  2. If JIRA has a failure at one of these points, it's possible it's just unhappy with how things came over and can't sort itself out. This isn't a consistent failure; i have it so it doesn't fail at all or fails at different points of the steps above (from intial start to import, to final restart). To fix it at any of these points it fails and then just be able to carry on:
    1. Stop JIRA
    2. Delete the contents of:
      1. <jira-home>/caches directory

      2. <jira-home>/plugins/.osgi-plugins directory

      3. <jira-home>/plugins/.bundled-plugins directory

      4. <jira-install>/work directory

    3. Restart JIRA

When it's time to transfer to production... perhaps it's an awful hack but when I am happy with the migration and it's flawless after testing... I do the following:

  1. Take that last point in time backup of current production
  2. STOP the JIRA instance to keep people from making changes even if I've communicated to the community the server is being updated so leave it alone from X time to Y time.
  3. Shut down the server after you have the <jira-data> directory copied over
  4. Re-assign the IP address that was being used on the old production to the new production server.
  5. Do the migration steps above.
  6. When it's done, the new server is automagically... in production. If Something Bad happens on the migration, roll back is as simple as restarting the old server.

You CAN do this with a DNS Alias change but I found that the IP address swap had the new JIRA server come up without having to re-establish application links to anything and Crowd just happily authenticated users to it without having to reconnect the Crowd server as its user authority. With the DNS alias change you have to reconnect applications and tell Crowd about the new server.

This approach is also great if you want to slide a new OS and/or Database server under your JIRA application. For.... reasons... I've used this approach to go from CentOS and MySQL to Windows and PostgreSQL and to where it is now, Debian with PostgreSQL

Let me know if this helps

mike

 

 

Thanks Mike, we need it for cloud but this is a great reference to have.  Much appreciated.

For Cloud, there's no concept of "test" - a Cloud system is a Cloud system.  You can use it for whatever you want! 

So, if you set up two Cloud accounts, one production and one test, you can work in them separately, but your options to transfer between them are very limited - you'll be doing config and setup mostly by hand (or merging in local dev systems before re-uploading)

Got it, thanks so much Nic you are right on point smile

Short and very good description to setup a test environment. Two additional steps from my point of view:

  1. Remove incoming mail handler (I changed server to localhost in XML-File)
  2. Disable users to log in to test environment (for example remove them from group "jira-software-users")

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Feb 15, 2018 in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

1,208 views 6 19
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot