How do you create and operate your staging/testing JIRA and Confluence instances?

Atlassian Developer Tools
,
1

We all know the drill.

  1. Atlassian application releases come out fairly quickly, they support every sort of OS and DB combinations.
  2. As a cross-product of JIRA/Confluence/Bitbucket version * operating system * database * etc., the number of possible combinations quickly grows to several hundreds.

And we want to be sure that we ship great quality add-ons for all the combinations!

Of course, we have automated tests (unit and integration), but we also run ad-hoc or planned manual smoke testing.

In our experience, testing against every point release may not be very important, and luckily OS or DB is rarely a source for bugs, but even with that, you may need to maintain tens of test instances of JIRA and Confluence. Plus you want to do that with pre-populated test data and with sharing among your team members.

How do you guys handle that?

You have a server running every sort of combos that your staff can use? You have VM images? Docker? Vagrant? Puppet? Chef?

1 Like
2

I’m curious… why would your add-on be affected by OS / DB combinations? The Atlassian host product should take care of that for you. If your add-on uses the Atlassian API’s (for instance for caching) or Active Objects for database operations, you should not need to care about the underlying OS / DB.

Which operations are you performing that might break due to quirks in the OS / JVM / DB?

3

@remie Active Objects are not DB agnostic! And any add-on code that write to the file system (for example) will need testing across OSes.

We tend to write integration tests and run the same set of tests against different versions of the applications/DB etc using Maven profiles or similar.

Arquillian (and an extension we wrote for it) is worth looking at for straight forward setup/teardown of application content.

2 Likes
4

Which operations are you performing that might break due to quirks in the OS / JVM / DB?

My first memory is that we needed to wrote a SQL query with an IN(…) clause where potentially lots of items were enumerated. MS SQL has an upper limit for the number of items, while other DB vendors doesn’t have that limitation.

So, AO clearly hides most of the DB dependent parts, but definitely not everything (and that isn’t a realistic goal, either).

1 Like
5

And this is a “fine” example for a bug in Confluence core that only happens with certain JVM versions!

TimSort has been introduced in Java 7, it is a stable sort that was designed for relatively expensive comparison operations. Only used for sorting objects, not primitives. Its problematic code path is only reached for collections with size >= 32

6

And for OS dependent functionality, our automation actions (here and here) that write to the filesystem are great example of stuff to test at least on U*x and Windows.

So, there is lots of opportunities to fail. :slight_smile:

7

I stand corrected :innocent:

8

I will check out Arquillian, thanks for the hint @jbevan.

9

We’ve run into a couple of similar issues. One of them being deleting more than 2000 entities in one swoop (MS SQL didn’t like that). Or using .count() (Oracle didn’t like that).

1 Like
10

We use snapshots on Digital Ocean to generate the base configurations of products and then have our setup/teardown methods reconfigure things as appropriately. We have a quick write up about it at Conquer your CI infrastructure: Continuous Integration that's lean and nimble .

1 Like
11

Thanks for the suggestion, @daniel, will definitely give this a try.

12

Oracle has (had?) a limit of 1000 clauses per query, and each item in your IN counts as one. MSSQL doesn’t have any issue there IIRC.

13

Well it’s not an issue with MSSQL but rather the jTds driver: [JRASERVER-38790] Ofbiz generates queries with large IN clauses that result in SQL Server errors - Create and track feature requests for Atlassian products.

That said I think there are enough documentation(are issues documentation?) at ActiveObjects - Issues - Ecosystem Jira to warrant testing on multiple combinations… :frowning: