The Quintus Single Server Deployment Tool (SSDT) is created to circumvent the time consuming and error prone aspects of the DTAP project promote process on a single Spotfire server.
In many companies that use Tibco Spotfire®, key users would like to publish their dashboards and reports, including information models, to consumers and more casual users on the production server. While these reports are being used, the key user also would like to make changes the information model and the reports in a different environment, often in association with a different database
If the key user has access to a different server (development or test), this can be done on that server, and the work can then be promoted by an administrator to the production server. However, this is not so easy when this needs to be done on the same server, since links get lost.
The solution
To resolve this problem, Quintus has created the Single Server Deployment Tool. It allows users to easily promote work from development to test to production on the same Spotfire server, without losing important connections and links.
Problem definition
In a regular stepped development environment, named DTAP (Development, Test, Acceptance, Production) there are multiple Spotfire server instances with its own library. A project is promoted from Dev up to Prod using standard Spotfire library export and import functionality using library object guids as a guidance on what is to be added or replaced in the target system.
For mostly cost and maintenance reasons, an organization may decide to integrate each DTAP step into a single Spotfire server. Also, the organization may allow key business users only access to the production server. These key users in turn, may create on that production server their own functional development, test and production environments.
Problems arise on promoting a project from one stage to another, for example from Dev to Test. In a classic multi-server DTAP environment everything is based on identical library object guids in each DTAP server. Having multiple project DTAP steps in a single server however means that each library object has its unique object guid.
Current approaches and pitfalls
One approach is to develop in Dev first and then replicate each and every change in the Test folder. This is considered to be very error prone.
Another approach is to export the Dev project folder and import it as a copy to become the ‘new’ Test project folder. Unfortunately, additional steps need to be taken, such as renaming data sources and providing them with the correct database connection string to point to the Test database. Even worse, one has to replicate the security structure from the ‘old’ Test folder structure into the ‘new’ Test folder structure and then clean the up ‘old’ Test folder. And finally, external dependent objects, such as an analysis file on the desktop of an end-user that depends on an infolink in the ‘old’ Test folder, will fail to open properly as the guid of that infolink no longer exists. In all, this is also considered a time consuming and error prone process with no room for error, especially when a project is promoted to Production.
The Quintus SSDT tool is designed to circumvent these pitfalls. It provides an easy way to promote projects from one DTAP step to the next using a single button click.
Detailed information
For more detailed information, please request the full functional document at info@quintus.nl