February 7th, 2022 by inflectra
We are very excited about the upcoming release of Spira 7.0 in a few months time. In previous articles we've described some of the new plugins and integrations coming to SpiraTest, SpiraTeam and SpiraPlan in this release. However even more exciting than that is the actual plugin architecture itself. Also known as the Spira Extensibility Framework, our new plugin architecture will let us add new specialized features and extensions much more easily. In addition, the future plans are to open up the plugin architecture to allow technology partners, solution partners, and customers write their own plugins and extensions to further customize Spira to better suit their needs.
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:
However we found that there were some use cases that were limited by the lack of a plugin framework within Spira:
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!
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.
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.
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:
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.
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:
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.
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:
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:
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.
And if you have any questions, please email or call us at +1 (202) 558-6885
Are you looking for a platform that helps you deliver better software, faster?