I am looking for best practice info. My company has a jira server and we are implementing DORA KPI for all the projects in the company.
This means that all jira issues of the type hotfix needs to be queried and analyzed to generate reporting.
We have > 10,000 JIRA projects and it seems inefficient to query the JIRA Apis on a schedule for all projects. We thought of using JIRA webhooks to get notified. However the announcement says JIRA will be limiting the number of webhooks per JIRA instance (cloud and later to JIRA server)
My question is if we don’t create multiple admin webhooks but instead create one webhook and add the filter issueType = “hotfix” and no project will that be performance efficient and doesn’t cause too much strain on the JIRA server (as we have noticed very poor performance in our JIRA server while using the UI)
Looking for recommendations and ideas here thanks in advance for your suggestions
First, I’m not sure how your Jira instance is still running! With >10k projects, your instance is considered XLarge according to Jira Data Center sizing profiles. That’s puts your instance somewhere in the 99.9th percentile. And, if the other dimensions are similar (like >2M issues), then webhooks are probably dangerous at almost any scale. If they are in use, then very narrow scope is the best option. A wide scope like issueType = "hotfix" will really hurt. Jira’s webhooks just weren’t designed with sufficient asynchronous support to be used in such a “wide open” manner.
Second, I slightly disagree with your inefficiency of the REST APIs. If you were running on Jira Data Center, a dedicated node to REST APIs could probably handle that load. One of the benefits of REST APIs is the most critical resources are paginated and rate limited, with options to tweak at the server configuration layer. That means you can hit the APIs hard with much lower risk to performance (or even stability). But my slight disagreement is predicated on Data Center, not Server.
Third, I think trying to get that bandwidth of events out of Jira Server (let alone an XLarge profile) is probably not a good idea over either HTTP style. The ideal approach is probably to write a Java plugin that could quickly write events out to a log (in the broad sense of the word). A time-series database might provide the right kind of query logic to efficiently ask about DORA metrics (3 out of 4 of the standard metrics are “cycle times”), and the “log” structure is easy to replicate (with eventual consistency) so that you could separate write from read operations.
Even if ideal (by my standards), there are downsides. There is the overhead of development in the first place: the Java plugins model is “mature”, which is a polite way to say that it is well-understood by many, but not great for starting today. Look at into the Server & DC topics and you’ll find a lot of people getting stuck as they get started (with challenges in docs & tools), and not a lot of answers. Then there is the operational overhead: the key to the solution is to off-load the events from Jira as quickly as possible (faster than either webhooks or REST APIs), and that leaves additional infrastructure to manage on your own.
Overall, this is the kind of use case where Jira Cloud is a superior solution (or, more precisely, is becoming):
Or, if not as our Cloud offering, maybe this is good reason to leverage one of our technology partners who provides DORA metrics and other analytics. The core of the solution is the same: off load from Jira.
Thanks a lot for the insights and it confirms a lot of my assumptions and ideas as well.
Unfortunately I don’t have the influence to have my company move to the cloud offering. Yes my company is huge and has lots of historical data in Jira (on premise)
So we would need a middle ground until we are in a state to transition to cloud offerings.
I will assess the options you have laid out and decide on an action plan
