Jira 5.0 was a massive (yes, massive) release for the Atlassian ecosystem and everyone building integrations with Jira. We introduced all sorts of goodies for developers building Jira plugins, and created new possibilities for remote developers. For the first time, remote applications could:
- Fully create and modify Jira issues with a stable REST API
- Create links from Jira issues to their remote application using remote issue links
- Post activities into the Jira activity stream with the Activity Streams REST API
As a result we’ve seen hundreds of new plugins on the Atlassian Marketplace and a huge increase in the number of remote integrations to Jira.
Jira 5.2 follows up from 5.0 with another feature for remote integration developers: Webhooks!
Je ne parle pas le webhook
What’s a webhook? Rather that give you a dry, textbook definition, what that means practically in Jira is this: If you have an app that should be notified when an issue in Jira changes, then webhooks are for you.
Why would I use a webhook?
Changes to Jira issues indicate that it’s time for something else to happen. If what comes next is activity within a remote application, you can use a webhook as the trigger. A few examples:
- Build apps: Trigger a build of your code base anytime an issue is moved into the “Done” status
- Support apps: Notify customers when an issue that affects their case is resolved
- Testing apps: Automatically assign validation tests to QA engineers when a critical bug is fixed
Webhooks are outbound. When you want a trigger or update sent from Jira after an issue event occurs, use a webhook.
The anatomy of a webhook (safe for work)
You can create a webhook directly in the Administration section in Jira.
When you create a webhook, you simply specify
- your URL: Jira needs to know where to send the notification that an issue has been updated. All we need is an address, no postage required.
- issues: You can use JQL (Jira Query Language) to narrow down what issues should trigger a webhook. For example, you can configure your webhook so only updates to critical bugs in your mobile dev project are sent to your application.
Alternatively, you can use the REST API to let applications automatically create the webhooks they need.
Webhooks are simple and lightweight – you can configure them via the Jira Admin UI, so the events can start firing before you event write a line of code to catch them. If you want to quickly give webhooks a try, there are free services like requestb.in and postcatcher.in you can use to “catch” the webhook events.
Ready, Aim, Fire
A webhook is triggered in Jira one of two ways:
1. A change to an issue
You can trigger a webhook simply by specifying when you want your application to be notified. Your app can be notified when Jira issues are created, modified, deleted, or when worklogs are changed.
2. A workflow transition
You can create a webhook that fires only for a specific Jira workflow transition. Using this approach you can start doing “Story Driven Development.”
With the power of webhooks in Jira and the flexibility of Bamboo tasks and plans, you can automate even more of your dev process:
- Execute a plan branch for each issue to run continuous integration tests anytime an issue is moved from development to QA
- Perform a Git merge from a story branch to master to happen anytime a story passes QA
How? Just create a Jira webhook pointing to the URL of Bamboo’s REST API for kicking off a Bamboo plan, then fire that webhook anytime an issue goes through a specific workflow transition. Now Jira makes Sarah’s GreenHopper-to-Bamboo-to-Bitbucket automation even easier.
Get hooked
Webhooks will be fully supported in Jira 5.2, but in the meantime, you can learn more about webhooks and their “shape” on our Webhooks Overview, or start playing with them today:
- OnDemand: OnDemand customers have early access to webhooks as a “Jira Labs” feature.
- Download: And, as a part of our Jira Early Access Program, Jira 5.2 EAP is available now, so you can try the full power of webhooks for yourself!