Skip to main content
Supercharging DevOps with ScriptRunner
Share on socials
Illustration of a Jira board
An orange circle placeholder
Chirag Harendra
26th September, 2017
Jira
Confluence
Data center icon
Cloud icon
Server icon

Supercharging DevOps with ScriptRunner

Stuart King, DevOps Engineer at Vestmark, explains how the wealth management solutions company supercharges DevOps with ScriptRunner for Jira & Confluence.
Stuart King, DevOps Engineer at Vestmark, tells us about how they use ScriptRunner for Jira and ScriptRunner for Confluence. The company builds technology solutions for the wealth management industry, delivering speed, transparency and convenience for its clients.
ADAPTAVIST: In a nutshell, what does ScriptRunner do for you and your team?
STUART KING: Here in the DevOps team at Vestmark Inc., we leverage ScriptRunner for Jira and Confluence to customise our instances and improve usability. If an employee approaches us with a business problem that we can’t tackle with the default functionality, our first step is to see if we can use ScriptRunner. While we have a standard set of approaches and have started using the product in more interesting ways, we can always count on ScriptRunner’s support team to assist with any questions or issues.
How does ScriptRunner for Jira help you in your day-to-day?
Jira is the primary product where we utilise ScriptRunner. Our most used built-in scripts are the copy project and switch to a different user. When we bring a new client on board, rather than manually implementing a project for them, we simply copy a main template that has set standards for things like workflows and permission schemes. This script saves us time and helps us maintain a standard across all client projects. We use the switch to a different user feature for troubleshooting problems. It’s very helpful to determine if a user’s issue may be browser related and it also helps with permission checking that the standard Jira permission helper might not be able to do.
The team is also a huge fan of the workflow customisation that ScriptRunner for Jira offers. We utilise scripted post functions quite often, but it can be a pain to manage changes if the post function is applied to multiple workflows. In that case, we utilise scripted listeners to perform tasks such as automatically setting watchers, or applying versions from our main product’s project to other projects.
Can you tell us about something interesting that you've done with ScriptRunner for Jira?
A while back, our QA team’s manager asked if we could solve a problem for him. For every new feature in our product (and there are a lot!), the QA manager would need to manually create multiple QA tasks. The tasks followed a convenient procedure though, which meant that the process could be automated! The tricky part was getting everything to line up, as the new features were created in a main project as an epic, and then the engineering tasks were generated in other projects as tasks related to that main epic.
The first implementation had us setting up a post function. If the main project epic transitioned to a particular state, first we’d generate a search string that encapsulated all of the linked tasks and then create a master list of Jira issues. We could then easily iterate through all of the issues and spawn the necessary QA issues. Then we’d link the issues back to the engineering tasks for tracking, ensuring there is direct visibility between QA and Engineering.
We ran into two hiccups while implementing this. The first was how to handle if the workflow looped back through the same step twice. We definitely did not want duplicate issues, so we decided to implement a custom field in the engineering tasks that we would set during this process. This was the first time we learned that Jira’s API does not automatically save and index custom fields during another issue’s transition, but otherwise, it was manageable to implement.
Screenshot of Spawn QA Issues on a Jira ticket
The second hiccup was a bit more interesting. As our products team changed their workflow, it wasn’t always guaranteed that our original trigger would take place. We needed a button. Thankfully ScriptRunner offers this in the form of script fragments and REST endpoints! We wrapped a REST endpoint around the old post function and created a button that would hit that REST endpoint with the necessary details. Now our QA manager can create QA issues on demand, leading to improved process efficiency.
What about ScriptRunner for Confluence?
In Confluence, we use ScriptRunner less often than we’d like, but for more complex tasks. As with Jira, we use the switch to a different user script to easily troubleshoot problems and confirm permissions. We’ve also used functions like rename labels and the URL conversion script to clean up our space. For custom functionality, we have a script that propagates labels to child pages, as well as a space with pages for each client that is generated by a central template. We’ll talk more about that later.
And what have you done with ScriptRunner for Confluence?
A problem that many organisations face is how to aggregate data. If each department has data related to a specific client, how do we provide that information in a central location while still allowing each group to follow their standard operating procedure?
Screenshot of code
We took advantage of ScriptRunner for Confluence to write a script that populates a new space with aggregated client information. This included data from not only Confluence but also our Salesforce instance. Conceptually our script is very simple. First, we pull a list of our clients as well as Salesforce data from databases within our company. We have a template page in place that has placeholder characters for substitution. The script then generates a page for a particular client while also swapping out values as appropriate. This includes values such as the client’s name, Salesforce data points, and custom links to other reports. We also include Confluence pages from other departments wrapped in an expand macro. That allows for a simple view of each client’s page with a ‘drop-down’ mechanism to view further details.
The only other considerations here are how to make sure the data doesn’t get stale. We leveraged a script job to run this update on a nightly basis while first purging the space’s trash. This ensures that we’re not filling up database space while also accounting for any changes in client names that may be taking place that an update of the page wouldn’t account for. This new space has proven very useful for new employees and veterans of the company as a place for client-specific information. Without ScriptRunner we would not have these capabilities.

Get started with ScriptRunner