Copy Crucible/FishEye to create a staging system, inc upgrade and migrate database

Martin July 6, 2018

We currently have a FeCru (v3.3.1) in a linux VM with an Oracle database - this is the live instance.

We also have JIRA on 6.1.1 and Bitbucket 5.7

I need to enable application links between Bitbucket and JIRA and have tested this successfully by creating a JIRA staging, importing the data from a live backup and upgrading through v6.4, v7.0 and then v7.10.

However, I need to get FeCru up to v4.4 so that it can continue to integrate with JIRA.

I have created a Windows VM for FeCru to sit on but earliest version that will install on Windows is 3.4. How can I use the current live FeCru on v3.3.1 as a source to create a viable staging system running Windows, FeCru v3.4 and SQL as an external DB?

I have a db backup of the v3.3.1 but cannot just import it to v3.4 pointing at an empty SQL database?

If I use the documented migration process, what happens to the live source database on Oracle - will it be deleted?

 

Any pointers gratefully received!

Thanks.

1 answer

0 votes
Aaron
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 11, 2018

Hello Martin,

 

Welcome to the Atlassian Community!

 

Before we go through all of your questions, I'd like to point out that since you are running in a VM you should test your disk access speed for Fisheye just to make sure your VMs are performant enough to ensure Fisheye can run smoothly.

 

From what you have said, it seems that you should create a test instance on another Linux box first and upgrade that and then migrate again to a Windows box (if getting to windows is your final goal). This document for migrating Fisheye between servers should be what you are looking for to get that up and running. Be careful to not have the migrated staging instance point to your production database before upgrading (or you'll accidentally upgrade your prod database and you'll have to upgrade fully as an emergency upgrade).

 

When you say "but I cannot just import it to a 3.4 pointing at an empty SQL database," that is a no. You can't just import tables from a 3.3.1 backup and have a 3.4 use it. Fisheye won't start that way. This backup document should be able to tell you everything you need to do to take and restore a backup to a staging instance (again, make sure you don't restore it to the same database).

 

So basically, you can do this:

  1. Take a backup of your production instance
  2. Restore it to a new Linux VM at the same Fisheye version and some SQL database
  3. Upgrade that to your desired version of Fisheye
  4. Migrate to a new database type (If you would like to do so after the restore)
  5. Migrate Fisheye to the Windows VM
  6. When you are ready to make it your production you can either repeat the steps for prod, or use a reverse proxy to point to staging (now will be production)

 

Regards,
Aaron Levinson
Dev Tools Support Engineer

Martin July 12, 2018

Thanks Aaron, lots of useful info there and I think I now have a way forward to make progress.

By empty SQL database, I just meant a db that had been created but not yet populated via data migration.

Aaron
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 12, 2018

Ah, then yes. And I'd like to make a correction. You can restore to a different SQL database type as far as I know. I'll make that edit above as well. You should be able to take a backup of one database and restore it to another type of database. And you do have to create it first. The restore script won't create the database for you.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events