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.
@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.
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 ). 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?
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.
@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 - 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
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?
@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.
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
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
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
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.
). Of these, we already have your