For the last few months, we’ve been hard at work creating the newest member of the Atlassian family, Jira Studio. Since this product is targeted squarely at developers, we decided it would be useful to engage the developer community to talk about what we are working on, both the good and the bad.


Our team uses a modified XP process that splits work into one or two week iterations, recording tasks using both Jira and the more traditional note cards. In this last iteration, numbered 114, our primary focus was to create a “FireBall”&#153 (our product manager makes us call it that), which is basically a tarball containing:

  • Confluence, Jira, Fisheye/Crucible, and Crowd WARs
  • Tokenized backups of each application.
  • An installation script that reads a properties file and modifies the backups for the specific instance to be installed (changing the hostname, mail server, etc)
  • README.txt detailing the steps to install the FireBall&#153

Our plan is to deliver this FireBall&#153 to Contegix, our hosting provider, for every new version. The system that creates this FireBall&#153 is our integration test system, since it needs to deploy the whole Jira Studio set of applications and run our integration tests against it. Granted, we use different backups for the tests, but the process is fundamentally the same. This means that every time Bamboo runs our integration tests, usually after every commit, we not only get a full integration testing of Jira Studio, but create the deployable FireBall&#153. Using the same system for release artifacts and testing helps ensure our release process is maintained and regularly exercised.

Speaking of functional tests, in Iteration 114, we went on a testing spree, writing heaps of tests for our project creation feature. In Jira Studio, when you create a Jira project, we create a:

  • Confluence space with the same key and name
  • Subversion directory tree (trunk/tags/branches)
  • Fisheye repository for the new Subversion directory
  • Crucible project with the same key

Obviously, there is a lot that can go wrong here, so we spent a week writing function tests to cover all the error conditions we could think of. Writing functional tests that cover so many products is tricky (and the performance of Maven 2 doesn’t help), but the benefit far outweighs the cost.


Finally, another core feature of Jira Studio is the navigation bar that sits above each application. The static images and Javascript currently comes from a directory, served by Apache, mounted at “/static”. To remove that step from installation, we wanted to bundle the static resources into each application. Jira and Confluence have a plugin type called a “web resource”, that allows you to define static resources to be made available to the page. It exposes the resource using a special unique URI that enables the use of the HTTP caching headers that encourage the browser to cache the resource for a year. This dramatically speeds up the application for the user.

Anyways, we moved the static resources into a new plugin that can run unmodified on Jira and Confluence, which just leaves Fisheye. The latest release of Fisheye/Crucible supports plugins, but didn’t have that plugin type available. Taking advantage of the Fisheye/Crucible guys a few desks down, we bribed them to add the web resource plugin type, so we now have a plugin that can run on Jira, Confluence, and Fisheye/Crucible, simplifying our deployment and speeding up Jira Studio in the process.

Well, that’s enough for now. I hope to keep the blog updated with our progress, and of course, feel free to let us know what you’d like to see in Jira Studio by commenting to this post or emailing our feedback address:

Developing Jira Studio Part 1