Test Environment

Jen Hamilton

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

Mike Rathwell

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