Connected DevOps is here

Jira already provides out-of-the-box features which lets you connect DevOps related information (like PR status from code repository, feature flag related data, builds and deployments data from CI/CD) to your Jira issue. Say, you want to connect data from a DevOps solution to your Jira project. What if an integration that you are looking for is not available? Connected DevOps lets you build that.

What is Connected DevOps?

Thousands of software development teams use Jira to plan and track their work through the stages of the development lifecycle.

As teams grow, they often find themselves using a number of different tools, and managing work across these disparate tools can be a challenge. Connected DevOps is a way to bring all of these tools together, to improve visibility and create a seamless workflow.

For example, in Jira, event data is fed into issues by first and third party tools, giving users greater visibility into their entire workflow.

We have provided APIs that allows you to connect data relating to key elements in the software development process like builds, deployments, feature flags and branch, commits and pull requests.

You can read more about Connected DevOps in Jira experience from our docs. Also, we have a guide to Connected DevOps to help you get started.

Please feel free to ask any questions or feedbacks you may have in this thread :slight_smile:


@aagrawal2 - this is awesome. How do I get this data out of Jira and consume it as part of my app?

Thus, if the Git Integration for Jira app, or a Jenkins integration app push commits and builds, and I want to do something with that in my plugin, how can I do that?


@ademoss, let me counter your “how do I?” with “how do you want to?” I’ve seen engineering discussions about exposing this data but we’d like some input first. And more than technically how (like “through a REST API”), it would help to understand the kind of user scenarios you’d like to satisfy.

In the meantime, one way you can leverage the data (even before you can actually consume it) it to ask about issues via JQL in development fields.

1 Like

Are there also plans to add monitoring and security sections? Or more generically post-deployment?



I’m not sure if I can call them “plans” yet but we have “left room” for post-deployments. For events where there isn’t yet full understanding of what to do with them or how to render them, there are remote links. I often describe these as the “other” category. Right now, there is just 1 tab in issues for these, but I see concepts “graduating” as they get used and we do more with them.

Even remote links have a type, which has valid values: document , alert , test , security , logFile , prototype , coverage , bugReport , and other (I guess even other needs an other category :wink: ). Of these, we already have your security event. Meanwhile alert and logFile are examples of things we’re thinking about for monitoring.

What would you like to see Jira Software do with these kinds of events? Do you think other event types would better represent your intent?


@ibuchanan - I would love a REST API, as well as Webhooks I can subscribe to, to be notified about these things.

As for what I would do with the data, the general notion is:

  • reporting, analytics, rollups
  • associate the data with entities we might have in our plugin

A more concrete example might be…

  • aggregate all the commits made by a specific jira user, and show which tickets they worked on for a given period of time
  • associate a confluence page with a particular build or release, for release notes purposes,
  • …etc

Thanks for the details! I’m sure the engineering team will appreciate it.

aggregate all the commits made by a specific jira user, and show which tickets they worked on for a given period of time

This is particularly helpful because REST APIs are so closely coupled to the aggregation model. And, given the way the data goes in (more or less “by issue”), I think our “default” could easily be the wrong thing to aggregate by issue. For that matter, I’d have to double-check to know if commit events even know which user made the commit. So we might also need to expand the event definition.

As for webhooks, I love the idea. Even now you could start to “play with” some of the possibilities by triggering webhooks on Connected DevOps events in Automation for Jira (Connected DevOps has also been called JSW Data Depot Service).

1 Like

@ibuchanan We have a similar need as @ademoss to be able to do reporting using DevOps data in Jira Cloud.

eazyBI for Jira Server/Data Center has a standard integration with Bitbucket Server and Bamboo. We use Jira application links to access Bitbucket and Bamboo REST APIs to get pull requests and builds and we link them with corresponding Jira issues. We provide standard DevOps metrics and several sample reports and dashboards that can be used or customized to customer needs.

In the case of Jira Cloud, we want to provide the same functionality but instead of making individual requests to code repositories and build tools (like Bitbucket) we want to use development data that are already pushed to Jira. Our initial focus would be the same – to get pull requests and builds and associated Jira issues. For performance reasons we need bulk APIs to request these data (e.g. paginated requests to get all pull requests and builds) instead of making individual requests for each issue (which would be too slow for bulk data import).


Great news, glad to see that these core DevOps integration APIs/SPIs are getting some love again :slight_smile: - could you please clarify the naming choices though, I think the messaging might turn out to be a bit confusing for customers/developers:

  • Atlassian just announced Open DevOps with great fanfare as the customer facing rebranding/expansion of all the features that associate resources and tools with Jira Software workflows based on issue keys
  • You are now announcing Connected DevOps as the developer facing rebranding/expansion of the seemingly identical feature context

Is this a deliberate naming difference for the same feature context, or am I missing a key differentiator somewhere?


I would love to be able to proxy api calls through you to call api’s that you might not otherwise call to gather my own data. Ie. If you’ve already got authorisation for the user/instance to be able to get all of the open pull requests - I’d like to be able to call the same api’s (maybe with some other parameters) to fetch other data pieces.


@ibuchanan - the “other” category is most interesting indeed, we have many use cases right away :slight_smile:

Remote links seem to only work from a Connect app though (got that working), but not yet with OAuth via the REST API as outlined. The /jira/remotelinks route yields 404 (other than e.g. /jira/featureflags etc.) which suspiciously matches that there is no “Remote links” permission scope when creating the OAuth credentials either.

Can you confirm that this is not yet enabled for OAuth integrations? And of course, is there an ETA in case? :wink:

1 Like

@sopel, I confirm no 2LO for “other”. Connect only for now.

This is an example of why I use the ironic quotes for “plans”. There isn’t an ETA at this time. Do you have examples of tools you’d like to connect? And why 2LO works better than Connect? I know the team behind that will be interested to get some additional context so that will help me make a case for extending 2LO to remote links.

1 Like

Thanks for the confirmation @ibuchanan, and happy to provide examples, but first things first:

And why 2LO works better than Connect?

As of recently, the official Atlassian guidance is to implement new apps with Forge, and we are all in - given Forge is based on OAuth as well, and Connect apps cannot yet be migrated to Forge, I’d prefer to start with a future proof architecture, hoping the Forge team will keep up their velocity and deliver the few missing pieces soon :slight_smile:

Do you have examples of tools you’d like to connect?

We are working on an app dubbed ‘Develop with AWS’ that integrates applicable AWS services with (Open|Connected) DevOps. Absent proper Forge integration, our prototype ingests ‘obvious’ AWS DevOps events via 2LO (e.g. CodeCommit, CodeBuild, CodeDeploy, CodePipelne, CloudFormation, …), i.e. the user must provide us the OAuth credentials just like with an on-premise integration - that’s reasonably secure, but a maintenance/onboarding/UX hurdle, plus it lacks remote links :wink:

The ever growing AWS service portfolio sometimes matches the dedicated categories, but more often the remote links ‘other’ category would be the better/only fit, here’s one example per type:

  • document - Systems Manager Automation runbooks
  • alert - CloudWatch Alarms
  • test - CodeGuru Profiler
  • security - Security Hub
  • logFile - CloudWatch Logs
  • coverage - CodeBuild (coverage reports)
  • bugReport - Systems Manager OpsItems/Incidents
  • other - CloudWatch Dashboards

There are many more, and each requires a dedicated assessment and event transform and thus need to be tackled one at a time, still it would be great to support a few at least one right away to convey the value proposition! /cc @Nir


Hi @aagrawal2

Is it possible to get Marketplace Partner apps added to the labels used on the marketplace to highlight recommended devops app search?


Hey @markrekveld
I have reached out to our product team about this. You should hear back soon.

You can do that by raising a ticket from with ticket type as “Request to be featured”.

Cool thanks.

What feature choice should I pick for the recommended devops list?
I don’t see a devops options, Continuous Integration comes close next to Software Teams, but I suspect those are separate lists.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.