Development and deployment in ThoughtSpot
Table of Contents
When deploying embedded analytics, each organization will have defined practices for development, testing, and deployment of content to ThoughtSpot.
ThoughtSpot instances act as a constantly running service, so deployment only involves ThoughtSpot data models and content.
ThoughtSpot provides numerous tools for building a structured deployment process, built around the ThoughtSpot Modeling Language (TML) format for representing the objects within ThoughtSpot.
Best practices🔗
The primary tool for structured development and deployment in ThoughtSpot is called Orgs
Each Org in ThoughtSpot can be paired to a branch in a Git repository as a single environment.
Orgs are fully separated tenants on a single ThoughtSpot instance. For TSE customers and others who need a structured development and deployment process, Orgs should always be enabled.
Once your environments are configured, you can move data models and content from the initial "dev environment" to any other environment using the Git integration REST APIs.
Standard structure of Orgs🔗
When Orgs are enabled, the Primary Org (org_id: 0) should be treated as the "root" or "super-admin" Org, and all "real content" should exist on Orgs other than the Primary.
The most basic standard configuration for separated development and deployment, with a multi-tenanted "prod" environment, has the following environments:
-
Primary: only used for administration of instance and Orgs themselves
-
Dev: ThoughtSpot customer internal development team builds data models and standard Liveboards and Answers
-
Prod: Data models and standard content are published to this environment by service account. All end customers get READ-ONLY access to data models, standard Liveboards, and Answers.
RLS filters the shared data models on the "prod" Org so that standard LBs and Answers only show the right data for each end customer, who are all only added as users to the "prod" Org.
Prod Org per end customer model for single-tenant data models🔗
If the production end customer data models are single-tenanted (logical separation for each end customer), such that a different connection is necessary), then the standard deployment involves a "release"/"pre-prod" Org and then one prod Org per end customer.
Additional "typical" Orgs🔗
-
Test, UAT: Additional steps in the publishing process between Dev and Prod, for verification before changes are deployed into Prod
-
Internal Org(s): Org(s) for ThoughtSpot customer’s own business work, never to be shared with end customers
-
Separate 'dev' instance: Some people want a fully separated environment for dev, especially if doing MAJOR changes, even to cluster config. Recommend there be a 'Test Org' on the 'Prod Instance' to push to first, before pushing to 'Prod'
-
Separate regional instances: prod per customer Orgs may extend to multiple ThoughtSpot instances in different regional cloud data centers
Deploying content between environments🔗
Git deployment🔗
The Git REST APIs are designed for the best practice pattern of building on a Dev Org and then deploying to any number of Orgs through Prod(s).
The Git Deploy API automatically writes to a GUID Mapping File that records the GUIDs of the object in Dev to all of the other Orgs, and automatically substitutes the correct values for an environment when the deploy commits REST API is used to synchronize the content in a ThoughtSpot Org with the linked Git branch.
TML export/import REST APIs🔗
Everything done via the /vcs/git/ REST APIs can also be done within your own coded workflows using the /metadata/tml/export and /metadata/tml/import REST APIs.
You will need a GUID Mapping file that records the originalGuid of the source object and the mappedGuid of the object in the destination Org, at the time it is first created.
Multi-tenancy and data security🔗
The exact deployment pattern chosen will depend on the design of your data warehouse. Please see the full documentation on multi-tenancy within ThoughtSpot to determine which deployment pattern best fits your needs.