Plugins Aplenty Coming to SpiraTest, SpiraTeam and SpiraPlan

Why Are We Adding Support for Plugins?

One of the key tenets and philosophies in our development of Spira is that it should have all the functionality you need to plan, manage and test software engineering projects. As part of our Harmony ideal, we have designed Spira to enable stakeholders in different disciplines to work together to do their job without needing third-party plugins or extensions. For example, business analysts, developers, project managers, software testers and quality assurance professionals can all work in Spira seamlessly. This is in stark contrast to some other platforms where every single feature requires a different plugin or extension. So therefore you may be asking, why have plugins at all? This is a good question as Spira already provides numerous way to configure the system:

• Customizable project templates
• Customizable types, statuses, priorities and workflows
• Custom fields / properties
• Customizable reports and graphs

However we found that there were some use cases that were limited by the lack of a plugin framework within Spira:

• Integrations with other tools that work best with an in-application user experience (vs. data synchronization or API integration)
• Niche features that users will want to be able to enable or disable for specific projects
• Customized process workflows and support for business processes that are more sophisticated than can be handled with the current workflows system

So therefore in Spira 7.0, one of the biggest new features is the Spira Extensibility Framework / Plugin Architecture that will make all these things possible!

Managing Plugins

Inside Spira you will be able to see the list of plugins available in your instance:

You can activate any of the available plugins for use in your Spira instance. Once you do that, you will then be able to enable any of the activated plugins for use on selected products:

When you choose a specific product, you will be able to see which ones are enabled for that product:

This allows you to have different plugins in use on different products in the same Spira instance.

Plugin Settings

Depending on the specific plugin, there will be settings available that you will need to configure to enable the plugin to operate successfully. For example, when integrating with GitLab you will need to enter credentials:

and at the product-level you will have settings, such as specifying the GitLab project that the Spira product corresponds to:

Once you have filled in the appropriate settings, the plugin is ready for use.

What Will Plugins Be Able to Do?

Each of the different plugins will be able to take advantage of the different extensibility features available in Spira. In general, plugins will be able to run code on the Spira pages, call external APIs, call Spira API endpoints, listen for key events such as an artifact page load or save event and add UI elements to the Spira user interface. Here are some key examples you can expect:

Menu Entries in Toolbars

The plugins will be able to add menu entries into the various toolbars in the pages in Spira. These toolbar menu entries can have icons and text entries:

When users click on these menu entries it can either open up an external URL or call plugin-specific code on the Spira page. In the example above, clicking on the Run Pipeline button will call an internal Spira API to get the release information and then use that to call the GitLab REST API to start a new pipeline event.

Plugin Dashboard Widgets

Plugins will be able to publish their own custom widgets for use on the various dashboards (My Page, Product Home, Program Home, Portfolio Home, Enterprise Home, Reports Center). In this example, the FMEA risk management plugin is displaying a new grid in the Product Home dashboard that shows the FMEA risk priority number:

These UI widgets will be able to query Spira data using the standard Spira REST API (with an internal library that simplifies the authentication and connection). Rendering of the data into different forms will be done using the following standard JavaScript libraries that Spira already uses:

• MustacheJS for rendering tables, grids, treeviews, lists, and other HTML elements
• C3 / D3 for rendering graphs and other graphical elements

Custom Grid Columns

In addition to menus and dashboard widgets, the plugin framework will let plugins display their own columns in the various list pages and grids. For example, the WorX plugin displays a set of custom buttons in the test case list grid that will launch the WorX manual testing accelerator plugin for those specific test cases:

Plugins will be able to display a variety of data and other elements in the columns, for example calculated fields, hyperlinks and/or buttons for accessing other systems.

Scripted Event Actions

In addition to the display of UI elements in the various pages, another key aspect is the ability to have customized business processes enabled by a plugin. In this case the plugin will be called whenever an artifact is loaded and saved so that it can perform specific business actions. For example, in the FMEA plugin, whenever you change the probability, detectability or impact of a risk, the Risk Priority Number (RPN) field is auto-calculated:

This kind of event-driven plugin will be useful for many other use cases, including:

• Changing which dropdowns are visible based on other dropdown values
• Calculating values based on other values (e.g. financials)
• Changing the value of a dropdown based on other values. For example, auto-assigning a defect based on the selected Component

What Kind of Plugins are You Planning?

We believe that it will be important to release the first version of the Spira plugin framework with a meaningful set of useful plugins so we have prioritized the following plugins for the initial release of 7.0:

• CI / CD plugins for GitLab, GitHub and CircleCI
• Risk management plugin that enables FMEA support
• Migrated existing support for WorX to a plugin
• Integration with other SaaS automation tools
• Accelerators for common artifact tasks and workflows

Who Can Write Plugins?

Initially, to ensure a high quality user experience, the plugins will be written by Inflectra to provide integrations or niche functionality that does not make sense to build in the core application. However once the plugin framework is released and any improvements and feedback are incorporated, we anticipate opening up the development of plugins to our technology and solution partners. We will use this to ensure we have robust documentation for third party plugin development and a secure code review and approval process in place. Once that is in place, the final step will be to open up the plugin architecture to customers so that they can create custom plugins that are unique to their own needs.

How Are Plugins Coded?

In order to get ready for writing your own plugins, you will need to have some basic JavaScript and TypeScript coding experience. All of the plugins will use HTML and JavaScript as their coding language:

The core plugin manager in Spira is being implemented in TypeScript and you will need to be knowledgeable in JavaScript, JSON and REST APIs to take full advance of what our plugin framework offers.