Creating a test environment for Jira Cloud

[Salim Bouassida]

Hello there,

We currently have a Cloud instance (Jira, Confluence, and Jira service Desk) with 370 users.

As a best practice, we would like to test our changes on a test environment before doing them on production.

I saw this guide:

https://confluence.atlassian.com/confeval/other-atlassian-evaluator-resources/atlassian-cloud-staging-and-testing-environment

Are my best options to:

• Set up a free environment (5 users) and deactivate all my users, and do a manual export and import?
• Set up a trial environment (and create a new one every time it expires) and do a manual export and import?

My ideal goal would be to have test environment with Jira and Confluence, that syncs every night, in order to have an identical environment to test on (projects, groups, users, confluence spaces)

This might be too much to ask, but is this in Atlassian roadmap?

[Earl McCutcheon · Accepted solution]

Hi @Salim Bouassida ,

As covered in the Article you linked the methods you noted would be the best approach, as your ideal setup is not currently possible, because there are not any methods to automate an import in Jira cloud, but I put together a workaround you could user that would automate a good portion of the overhead below, Noting that I would not recomend this for production data without extensive testing to verify but for a dev environment you should be good to go for a rapid copy for testing, and This is a bit rough and could be modified as needed to script it out a bit more, noting I did a test run in an instance with a limited test data set so if you run into any errors on your end let me know and I could take a closer look.

First is a partial Automation on Exporting data that you can look into that we currently do have scripted out, follow the processes outlined in "How to Automate Backups for JIRA Cloud applications" to automatically generate your backups of the production site, however as mentioned above there is not currently any method to automatically restore and that would still be a manual process for restoring to the test environment as needed, And an additional limitation is this is a exact export of the Production data.  Where per the workaround noted in the KB you linked you will have needed to have already Deactivated the user accounts prior to exporting to be able to import to a 5 user free tier, so the exports in this script will contain a full active user list causing a hiccup in the restore.

For this scenario you could get around this by editing the export files manually (or script this part out as well) so that the import to a free instance will not fail if the active user list in the import file is >5 active accounts.  To do this the Additional workaround of modifying the backup file directly to flag all but the desired users inactive is below and a bit rough but could be added to a scripted process and have daily backups of the prod site ready to import to the 5 user free test environment.  

Export the backup.zip file using the script in the KB above then extract the zip, then in the entities.xml file what to look for would be a section that looks like the following, there will be 1 entry for each of the users:

<User id="10101" directoryId="1" userName="User_Name" lowerUserName="user_name" active="1" createdDate="2020-02-19 19:56:39.011" updatedDate="2020-02-25 21:19:49.026" displayName="User Name" lowerDisplayName="user name" emailAddress="User_Name@domaine.com" lowerEmailAddress="user_name@domaine.com" credential="nopass" deletedExternally="0" externalId="####:######.....etc..." localServiceDeskUser="0"/>

Notice the portion active="1"  if you change the 1 to a 0 the user will be imported as inactive, but doing this manually would take a lot of effort, I put together the following SED command to edit this file that you could do or an equivalent regex edit in your favorite text editor/scripting language to locate lines starting with <User id= containing the active="1" flag then set them all to 0:

sed -e '/<User id=/s/active=\"1\"/active=\"0\"/g' entities.xml > entities.xml

But you will also need to re-activate the sysadmin (locked admin account that must be enabled for the import to work) and the desired user you want log in as for testing and you can do another SED for each user to do this replacing "sysadmin" for the subsequent runs for the 1 - 5 users that you want activated in the test instance:

sed -e '/userName=\"sysadmin\"/s/active=\"0\"/active=\"1\"/g' entities.xml > entities.xml

Repackage the activeobject.xml and entities.xml zip with the file structure described in This KB and you should be all set to import that file into the 5 user free instance.  

Regards,
Earl

[Salim Bouassida]

Hello Earl,

Thank you so much for this walkthrough!
My import failed 3 times, and I assumed that the number of active users might be the issue.

My other issue was that my Jira is 12GB, but the allowed space in the free environment is 2GB.

We have multiple project on a "Archive" Scheme that I don't need to get to imitate the production. Do you know if I could select a subset of project to import?

[Earl McCutcheon]

Hi @Salim Bouassida ,

Thanks for the update and the 12GB of additional attachments will definitely be an issue importing to a free site, as the free site will fail if there is greater than 2GB, So options there would be to import without attachments to the test site, or delete uneeded attachments from the backups.

Also per your question on Project imports, Cloud Does not have project imports yet, and this one has several moving parts to pull togather and we are tracking this feature at the following links for the main portions, This is still a ways out but is something we will be adding in the future:

• https://jira.atlassian.com/browse/JRACLOUD-72570
• https://jira.atlassian.com/browse/JRACLOUD-31806
• https://jira.atlassian.com/browse/JRACLOUD-40464
• https://jira.atlassian.com/browse/JRACLOUD-7020
• https://jira.atlassian.com/browse/JRACLOUD-4052

Next, looking over the steps I listed yesterday I wrote them out incorrectly (sorry about that) and in the current form are written to directly overwrite the existing entities.xml but in my testing I had actually iterated the file names and then renamed back to entities.xml as a final step.  In the commands while re-testing the steps, I was seeing that the direct overwrite after the first SED the file will just be left blank,  so doing it like this would fix that issue:

sed -e '/<User id=/s/active=\"1\"/active=\"0\"/g' entities.xml > entities1.xml 

sed -e '/userName=\"sysadmin\"/s/active=\"0\"/active=\"1\"/g'  entities1.xml > entities2.xml

sed -e '/userName=\"admin\"/s/active=\"0\"/active=\"1\"/g' entities2.xml > entities3.xml 

 sed -e '/userName=\"testuser\"/s/active=\"0\"/active=\"1\"/g' entities3.xml > entities4.xml 

mv entities4.xml entities.xml

So that process was for a instance I set up with 2 users accounts to migrate where there were 20 additional users created on the instance And the last "mv" command is overwriting the original entities with the final modified one, so you could also add in a step to back the file up first if you wanted to save the original entities file for additional rapid recovery options in testing this.

Check this one out and let me know if you hit any other errors in the process.  And if you do get another error on import grab the output of the error message so I can check out the syntax.

Regards,
Earl

[serge calderara]

hello @Salim Bouassida , did you manage to build your staging intance correctly ?

I am in the same situation as you for a customer and need to get a proper steps.

What solution did you select and steps did you go ?
What happen with the plugins configuration, are all be kept or did you have to reconfigure them all ?

Thanks for sharing

Serge