Following the tremendous success of the Configuration Manager for Jira, and the continued requests from customers to extend its capabilities for Jira Service Desk, for the past two quarters Botron Software’s team has been actively working to deliver end-to-end support for Jira Service Desk.
In the following interview, George Dinkov – Botron Software’s co-founder and lead of the Configuration Manager team – shares some of the challenges and benefits of implementing Configuration Manager for Service Desk.
Q: Extending Configuration Manager’s capabilities to Jira Service Desk has been one of the most frequently requested features by customers – when did the development start and why did it take as long as it did?
George D.: We made a proof of concept in September 2017, followed by an architecture. The development stage of the feature started in December 2017.
The primary reason for not releasing earlier was that it took a lot of time and effort to implement a fully-functional, scalable architecture that allows us to support multiple Jira Service Desk versions at the same time. We wanted to ensure that we will be able to quickly add support for future versions, all with a single binary distribution.
The consensus amongst the team members was that we would provide 100% coverage of all Jira Service Desk features with the very first release. We believe the final product was worth the patient wait.
Q: Can you share some of the challenges the team experienced during the development process?
George D.: The biggest challenge was the lack of API in Jira Service Desk for the retrieval and manipulation of configuration. This roadblock drove us to implement a facade that would give an API to be used in Configuration Manager for Jira, and allow us to support multiple versions of Jira Service Desk easily.
The other major challenge we encountered was the sheer amount of different kinds of configuration and data we had to handle and continue to support in the future.
Q: With such complex challenges, how are you ensuring quality?
George D: Well, the only two metrics for measuring success in our company are product quality and customer satisfaction [laughs], it’s a good business strategy. First, we focused on providing full coverage with automated tests across all versions of Jira Service Desk, the same way we do for Jira Software. These automated tests consist of unit tests, integration, API and UI testing.
Second, we engage with our active customer base – they perform comprehensive and thorough tests in the field with their staging and production data and provide an invaluable feedback-loop for our team.
Last, but not least, Configuration Manager for Jira Service Desk is supported by our Integrity check feature, which detects corrupted data before it is deployed, allowing users to roll-back and correct it.
Q: Configuration Manager has a competition – Adaptavist’s most recent acquisition, Project Configurator. They released a Jira Service Desk support earlier this year. What are some of the benefits that Configuration Manager has over Project Configurator in the context of Jira Service Desk support?
George D.:The main benefits are that Jira Service Desk is fully integrated in our data protection and enterprise features – the roll-back model in case of an error, deep change and impact analysis, detailed audit log, integrity checking – all things that are part of the core Configuration Manager product, were integrated into our support for Jira Service Desk.
Additionally, we released full Jira Service Desk support including all configuration and data types, while Project Configurator has opted to release partial support and add to it incrementally – at the time of this writing we cover more Jira Service Desk features than the latest version of Project Configurator.
Q: Now that we have Configuration Manager for both Jira and Service Desk, what can we expect from your team regarding future product development?
George D.: Right now we are working on many exciting features for Configuration Manager for Jira. Some of the most notable are:
- Power Admin: the tool will allow Jira admins to easily find configuration objects understand its dependencies and usage, e.g., answering questions like where a given custom field is used and if it can be safely removed;
- Extension SPI: we have been working on this for a while, and hopefully we’ll be able to release it soon. Ultimately, this feature will allow any developer to extend Configuration Manager for Jira with custom configuration and data, e.g., from a 3rd party applications;
- Auto-fix in Integrity Check: we’ll introduce options to enable the admins to automatically fix some of the most common and hard to resolve problems that CMJ’s integrity check detects.
- Selective merge: we’ll provide options to allow the deployment of parts of the changes that CMJ detects and removing/altering other parts in the deployment wizard.
We’ve also started work on Configuration Manager for Jira cloud, Configuration Manager for Confluence and Configuration Manager for Bitbucket. We already have working prototypes that our Professional Services team has used for various migration initiatives, but our teams are working hard to release them to the general public.