We have finally started adopting Jira en masse, and it has been amazing to see. We have heard that we want to be more “agile”, but I think many people who have never seen agile in action do not know what this really means. Adopting Jira in the bottom-up manner we have is a significant culture change for my place of work.
The good and bad of this is that now people want Jira, I have to create a Jira ecosystem that is more capable of standing on its own. The recent steps were to upgrade from 6.1.7 (MySQL) to 6.3.7 (Oracle) before we start to push it to the whole company as a true project management solution.
The migration process is well documented by Atlassian, and for the most part I followed their instructions to a ‘T’. However, there were a few quirks to the process, and lessons learned.
Install on New Machine
We are running Jira as a stand-alone application, and the install on the new machine was very straightforward.
I did almost send emails to the entire company because I did not disable email before performing the upgrade. There were a few rogue emails that were sent on the first attempt, but luckily there is an easy JVM param to include in your CATALINA_OPTS: -Datlassian.mail.senddisabled=true.
This can be a bit tricky if you have a complex LDAP infrastructure, and want to use it to authenticate and authorize users.
Every situation is different, but we wanted our LDAP to be the sole source of users (except for the first created super user during the install). A few things to keep in mind:
- LDAP Permissions: Read Only, with Local Groups
- this will bring in a user’s groups, but allow Jira to enhance them with Jira-specific attributes. Leaving the original LDAP system untouched.
- Default Group Memberships: jira-users,jira-developers
- we want to empower users, and give them as many capabilities as possible, without the risk of administrative uh-ohs. So we give all users the jira-developers authority as well at first login.
- User Schema Settings
- This is where we use an LDAP filter to limit users to only those in IT. When we eventually bring in the business reps, we will create a new group, and give it to that side of the company as needed. Hopefully we will eventually give it to all of them.
We have a decent amount of data in 6.1.7 using a MySql DB (test01), and the new, dedicated machine will run 6.3.7 with an Oracle back-end (jira00). I tried to use the “System > Backup Jira Data” and then import the data via “System > Restore System”, but this does not seem to be working because the issues for each project were not brought over.
I looked at the files generated from the export, and entities.xml contains project and issue data, but it was not brought into the 6.3.7 machine.
<ChangeItem id="23443" group="34545" fieldtype="jira" field="Workflow" oldvalue="34513" oldstring="DEVOPSADMIN: Simple Issue Tracking Workflow" newvalue="476345" newstring="Simple_Support_WorkFlow"/>
<Issue id="09873" key="OPSADMIN-32" number="32" project="64354" reporter="bobsmith" assignee="johndoe" type="4" summary="Update security to reflect knowledge gained from Jira config" priority="3" status="1" created="2014-10-28 05:22:43.0" updated="2014-10-28 05:22:43.0" votes="0" watches="1" workflowId="43233"/>
According to the documentation, the XML export is intended to make the process database agnostic, which means I am doing something else wrong.
Since we have support for Jira, I contacted them to ensure that the export was correct while I troubleshot from other angles, and they were able to successfully perform the import with the exact some version and DB settings I have. They recommended that I re-index the jira00 machine to see if that fixed the issue, but that did not help.
I knew that I had exceeded the 10 user limit of my license, and I thought that was a possible cause since when you exceed your license you cannot create issues. I suggested this to the Jira support, but they did not seem to know the details in this area.
I decided to prove this concept one way or the other on my own and got an eval license for jira00. An eval license allowed me unlimited users, so the 10 user limit is no longer an issue.
I then tried to perform another import of the old test01 data, and it at least made progress. However, it became stuck at 90%, and since I had other things to work on, I let it ride for close to 3 hours until it was nearing the end of the day, just escaped out of the browser process.
I could not access anything within jira00, and it appeared to be completely down. I then restarted the instance, and all of my issues were available, even though the import did not appear to end smoothly.
I tried this process a few more times, and every time it hung at 90%. I spoke with the DBA, and each time I performed an import, the DB was only being hit for about 10 minutes. I looked all through the jira00 logs, and I saw nothing of interest that points to a specific error. Their support informed me that it was possibly a combination of the installed add-ons were not playing nice with each other, so at some point maybe I will remove all add-ons and see if that helps the situation.
Overall the process was not too bad, but there were a few quirks about the migration. Something we tied ourselves up with was pointing to a test database instead of just starting with the production one ready. It is easy to update the dbconfig.xml file (assuming your username and password are the same), but things are less complicated when your new machine starts with the DB it plans to use at go live.
I may have been able to perform the import and then the LDAP config to avoid the user limit issue, but I wanted to ensure that all user data was there so projects were linked appropriately. Next time I will hopefully just be doing an in-place upgrade, but if there is a new machine, I will start by just grabbing an eval license.