JIRA Plugin for automatic synchronization with 3rd party software

[alexandreev]

I need to write plugin for jira which will synchronize jira issues with external project management software.

The key requerements to the plugin to achieve the goal are:

1) Plugin should run background tasks periodically to check external app for updates.

2) Plugin will need to establish network connection, most likely keep constant connection (using native java api)

3) Plugin will need to determine exactly wchi jira entities were changed since certain time.

I would much appreciate comments on feasibility of this task and would be very greatful for all advices / useful links.

[Nic Brough -Adaptavist- · Accepted solution]

I don't think your network structure matters really. My current client runs Jira on the internet, and there are services both inside and outside the corporate network that pull data from it.

As Bob says, we try to avoid putting highly customised stuff into Jira, we prefer to let other applications pull over REST or grabbing issues as XML - this keeps upgrades and support more simple on the Jira side, and has the added advantage that we don't need our Jira developers have to undersand both ends of the procedure.

If your process can be a standalone script or program, that can make it a lot more simple, especially if you do use the Jira CLI from Bob - it lends itself to scripting and takes away a lot of the stuff you'd normally have to re-invent a wheel for when writing an interface from scratch. It makes it really easy to do things like "a script that looks for updated Jira items and sends them over to another server in format X" - get the script working, whack it into cron and you're done.

[alexandreev]

Thanks Nic, it all does make sense for me. I will definetely will take this approach into consideration. But for example if I will have many jira instances from different clients to integrate with the pm software. It's simplier to let them just to install the plugin than configuring a script.

[Nic Brough -Adaptavist-]

Yes, if you've got one PM system, and several Jiras, it may seeem more easy to use a plugin. It'll work fine initially, but you could easily run into a mess when you have to maintain it as Jira moves on. With REST or XML, you'll find the data coming out of Jira remains independent of version, and the format is suprisingly stable between Jira versions.

You'd not mentioned multiple JIra instances before though, that would have swayed me more towards a plugin, but what I'm getting at is that it really is very much up to you how you do this, we're just making recommendations based on what we know.

[alexandreev]

I guess I have no choice but to deal with those maintenance issues. Maybe it's not so bad. Thank you for your answers. I will dig into plugin development.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

I don't think the number of systems matters either provided you are doing roughly the same thing for each. Scripts do very well with going though a list of systems doing the same/similar things either sequentially or via threads. An advantage is that your PM systems only needs to be queried once for changes. You do need to handle situations where one or more JIRAs may be unavailable. You might also want to consider splitting incoming from outgoing perhaps with different technique for each direction.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

I would guess you are talking about a custom environment. If so, then in my opinion, making this a JIRA plugin over complicates the situation from a development, maintenance, and operational perspective. I would only go this route if less complicated mechanisms have limitations that cannot be overcome. An external approach is more easily controlable, easier to test and debug, and can draw on existing tools. We have integrated a number of external systems (https://answers.atlassian.com/questions/21732/how-to-migrate-clearquest-to-jira/21743).

JIRA Command Line Interface provides easy access for doing JIRA things, your scripting language (like Groovy :)) can provide database access (read only for JIRA database if necessary), and you will need some technique that is dependent on the external product you are integrating with. Bamboo makes for a really nice way to run your automation with scheduling, logging and notification support.

[alexandreev]

I was not clear with environment. The JIRA server is supposed to be in separate location than the project management software to sync with. Separate servers, where JIRA server can be located in corporate network while the pm software server exposed on internet.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

I don't think that makes any difference. The automation would need to run from the corporate network and could run from the same server that JIRA runs on.

[Nic Brough -Adaptavist-]

I'm not a real developer so I don't think I'm qualified to comment on item 2 (although I don't think "a constant connection" actually makes much sense - I assume you want to log in once and then keep the session open, but that isn't "constant")

The other two are more Jira related, I would

1) Write a service, as they can be configured to run in Jira regularly

2) Inside the service, use a filter, and define it as "issues updated in the last X minutes" (and other criteria as required)

However, you could look at doing this on the other end - Jira exposes data via REST (and SOAP), and depending on what the other system needs, you could just get it to pull the data out over a RESTful connection.

[alexandreev]

Thanks Nic, from your answer I see that it should be feasible at least as I didn't know where to start. Standard Api will be not enough for me, and not possible to rely on due to environment limitations. (my comment to Bob)