It’s been a while since we last covered Scripting/Automation in the Atlassian ecosystem with our 2019 webinar on “A Detailed Review of Automation & Scripting Apps for Jira, Confluence, & Bitbucket” so we thought that an update would be in order.
Back when we ran the webinar Code Barrel’s Automation for Jira had only recently been acquired by Atlassian and we could only speculate on the wider implications of this. Furthermore, Atlassian hadn’t yet announced that they were ending the support of server licenses and “Accelerating our journey to the cloud“.
Automation for Jira has now been fully rolled into Jira Cloud and the Cloud platform has been exploding ever since this announcement. These two developments have had some major implications on the Scripting/Automation category which we’ll get into below.
On top of this we’ll also provide a MARS analysis of the category, some examples of what you can use scripting for, as well as some things to look out for when using scripting in Jira.
What You Can Use Scripting For
We generally see four major uses for Scripting/Automation:
Things to Avoid when Scripting/Automating
Furthermore, while scripting and automating tasks in Jira can be powerful and has the potential to save users countless hours of time, there are also many risks involved. We thought that some insight into a number of issues that we’ve come across over our years of scripting in Jira would be useful:
- Performing certain ticket actions (e.g. create, update, delete) directly thus bypassing Jira permissions
- Creating and updating ticket links, breaking consistency
- Executing certain JQL queries that have a detrimental impact on the system’s performance (e.g. ignoring limits on the number of tickets returned)
- Directly setting the value of certain custom fields, breaking consistency, ignoring ticket history, and affecting the Jira index
- Executing actions impersonating other users
- Bulk creating, updating, and deleting user accounts, as the following example shows:
MARS Scripting Overview
MARS is our Marketplace Analytics Research Service database of 3rd party Atlassian Marketplace apps. Through MARS we are able to provide unique, data-driven, and unbiased insights into the Atlassian Marketplace.
For instance, we can see from Figure 1 that Scripting/Automation is the 3rd largest growing category (we assign our own “Meaningful Categorizations” rather than using vendor self-selected ones) with a rate of growth of a little under 5%.
Figure 1: App Categories by Size with 2021 % Growth
ScriptRunner for Jira is the market leader and has shown relatively impressive growth this year of 8%. The same can be said for ScriptRunner’s Confluence and Bitbucket variations with 9% and 7% growth respectively.
We can also see a number of Appfire’s 2020 and 2021 acquisitions showing strong market share with JSU, JMWE, Power Scripts, and Create on Transition all featuring among the top scripting apps.
Figure 2: Top Scripting/Automation Apps with 2021 % Growth
Figure 3: Scripting/Automation Market Share by Vendor
Since we started recording data in MARS in November 2018, Automation for Jira grew at a remarkable rate from around 6,000 instances to over 12,500 by January 2020. This was the last data point we recorded on Automation for Jira because Atlassian began rolling Automation for Jira into all Cloud Jira instances and thus is ceased to operate as a Marketplace add-on in the same way.
Looking back at Figure 1 we can see that Automation for Jira’s rise and subsequent acquisition by Atlassian has likely harmed the visible growth of Scripting/Automation as a Marketplace category compared to others since Automation for Jira, which was driving much of the growth in Scripting/Automation, is now a part of Jira Cloud and thus cannot be recorded in the same way.
However, ScriptRunner in particular, as a more intricate, customizable, and code-heavy tool is competing less with Automation for Jira.
Figure 4: Growth Trends for Largest Scripting/Automation Apps
- Automation for Jira
- Scriptrunner for Jira
- JSU Automation Suite for Jira Workflows
- Jira Misc Workflow Extensions (JMWE)
- Power Scripts - Jira Workflow Automation
- No-code rule builder that lets customers build if-this-then-that-rules based on events in Jira
- Used to automate processes, save time, and keep Jira up to date
- Acquired by Atlassian from Code Barrel in 2019
- Included in all Jira Cloud plans (differences in usage limits and global/multi-project rules between plans)
- On DC: 100 users = $370, 1000 = $3,000, 10,000 = $12,000 (all prices annual)
- Extends Jira and Improves UX with Groovy Scripts and JQL
- Versions for Jira, Confluence, Bitbucket, and Bamboo
- Largest Marketplace scripting add-on
- On Cloud: 100 users = $2,500, 1000 = $8,500, 10000 = $41,000
- On DC: 100 = $444, 1000 = $3,600, 10000 = $14,000
- Code-free Jira workflow customization
- Acquired by Appfire in 2020
- On Cloud: 100 users = $900, 1000 = $3,300, 10000 = $13,500
- On DC: 100 = $288, 1000 = $2,185, 10000 = $8,050
- No code workflow configuration
- Also acquired by Appfire in 2020
- On Cloud: 100 users = $1,250, 1000 = $4,775, 10000 = $15,325
- On DC: 100 = $331, 1000 = $2,513, 10000 = $9,258
- Deep scripting solution for general automation, customization, and integration in Jira
- Acquired by Appfire in 2021
- On Cloud: 100 users = $1,550, 1000 = $8,300, 10000 = $46,300
- On DC: 100 = $300, 1000 = $2,550, 10000 = $9,190
Scripting/Automation on Cloud vs DC
On top of Atlassian’s acquisition of Automation for Jira, the growth of Jira Cloud has perhaps had some detrimental impacts on the market for Scripting/Automation applications.
While on DC (and Server) Scripting/Automation add-ons have use of the Java API and thus unlimited access to all Jira core functions. Scripting/Automation apps on Jira Cloud are based on the REST API with a limited range of features.
The Java API is a library of software components, some of them provided by Java out of the box and some others provided by Atlassian. They run in the Jira server, and therefore have a faster response time, and some scripting add-ons allow the scripts they provide to also use the Java API. Therefore, Scripting/Automation add-ons on DC are more powerful, riskier, less stable, and require more code maintenance.
On the other hand, a REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style allowing for interaction with RESTful web services. This means that since scripts run on a different server, network latency matters. Furthermore, when compared to DC scripts they are limited feature-wise, albeit they’re considered safer, more stable, and can get by with less code maintenance.
We can see the more limited functionality of Scripting/Automation apps on Cloud in ScriptRunner for instance. The number of DC features is limited including workflows, scripted fields, built-in scripts, some listeners, script console, jobs, and fragments. Our technical team estimates that around 70% of features have been removed including behaviors, services, custom listeners, custom endpoints, database/LDAP connections, script editor, mail handler, and code insights. We would encourage customers to explore a wider set of apps for cloud because now there are so many, rather than custom scripting.
We hope that you’ve found our recap on the Scripting/Automation category informative and that you’ll be able to bring some insight from it forwards with you.
If you would like to get in touch with us please contact us at email@example.com.