Stash, Bamboo, Jira. How do they fit together?

My current client has bought into Atlassian products pretty hard this year, and I am loving it. Prior to the migration to Atlassian they had a home-grown solution that was less than ideal for software project management. It is nice when software just “works”. Especially when it is software specifically for software projects, written by a company whose sole purpose is to write software to manage software projects.

The language can get a little confusing if you are new to modern software project management, but at a high level these are the Atlassian products we are using, and how they related to each other:

Jira

JIRA is many things. At its most basic level, it is a way to track “issues” (aka tasks) for a given project, regardless of what type of project it may be: TODOs for support projects, project managers to track Agile projects, and everything in between. At a very high level JIRA allows you to create an “issue” for a given project and assign it to someone with a given priority. An issue can be anything, but is most likely to be a: Bug, Improvement, Task, or some variation of one of these. Issue types are highly customizable, so you are not limited to just these options.

Stash

Stash provides a visual way to manage your git repository, much like GitHub, but for the corporate world.

Bamboo

Bamboo is a Continuous Integration (CI) and build server. It will connect to Stash (i.e. git), and build the deliverable (i.e. artifact). The artifact will likely be an EAR, WAR, or JAR file in the Java world. Bamboo will also provide the deployment to the respective environments (Dev, UAT, Prod, etc.).

Combine them all

One of Jira’s most powerful features is that it allows you to create an issue in JIRA, associate it with a new branch in Stash, and a deployment within Bamboo. So if a user sees an issue with the Order Processing app, he can create an issue for this app and assign it to the project lead for the app. JIRA can then track the developer’s progress on this issue, and all collaboration between interested parties via comments in Jira to ensure the issue is fixed properly. Everyone will see that the build has been performed in Bamboo, and the newest version (e.g. 1.3.12) has fixed a list of issues, including the original issue reported.

There is a lot more available with these Atlassian products, but if interested, dial in to one of their many free webinars to better understand how they can help you.

Project Configurator for Jira

I’ve recently been performing a Jira upgrade and migration, and during this process it became apparent that we needed to have a test environment in addition to our production environment.

The test environment will allow us to test different Project flows and custom designs without mucking up our production environment with half-hearted ideas.

The problem with this design is that Jira does not provide a great way to export a single project with all of its custom fields, schemas, workflows, etc. But someone else has: Project Configurator

This add-on is a great way to bring your test Projects into production at a pretty cheap cost. Trying to do this by hand was tedious and cumbersome, especially if you have a great deal of custom additions to fields and schemas.

Jira Migration and Upgrade

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.

Ldap Config

This can be a bit tricky if you have a complex LDAP infrastructure, and want to use it to authenticate and authorize users.

User Directories

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.

The Migration

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.

end

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.