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.
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.
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, but these key users to 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.
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 finally clean the up ‘Old’ Test folder.
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.
For more detailed information, please request the full functional document at email@example.com