How to choose your way to manage Tableau Server Deployment

Tableau Reports Deployment Environment

Prabhakar Pandey
5 min readSep 18, 2020
Are you ready for Tableau Reports migration

Deploying and managing a Tableau Server involves a set of responsibilities that we can categories into two different roles — one role that owns or administers the content on the server (the content admin), and another that architects and maintains the server and underlying system (the system admin).

We can have UAT/Production. That’s fine, but we can also have a sandbox area where we can play around. Develop in Tableau Desktop, then publish to Tableau Server for testing and finally, promoting to production.

Environments?

Common names for these environments are development, test/QA, staging/pre-production, and production. There are typically three to four environments (staging/pre-production is often omitted). These environments can exist as either separate projects or as sites on the same Tableau Server instance. Or each one might be a separate instance of Tableau Server.

QA/Dev Process:

The QA process is straightforward when we look at it from a high level. Below is a simplification of the workflow. Realistically we will have a back-and-forth between the QA analyst and developer as issues are found.

Tableau Server Environment
Tableau Server Environment

Tableau Deployment Process Flow Diagram:

Tableau Server Deployment Process Flow
Tableau Server Deployment Process Flow

Tableau Server->

We should have two virtual servers; one to be used for development and the other for both testing/production use.

Version Control: -

In Tableau Server we can manage version control with simple but uniform naming convention or use the landing area as a historical record of everything and only publish to a different Project/Site when the changes are ‘ready-to-deploy’.
We can add a sheet (dashboard) to each workbook called “changelog.” We can put the date, username, version number (assigned by us), and what changes were made. This has been very helpful as we develop dashboards. We, too, use “dev/QA” and “production” projects.

Tow Folders in PROD Env’s Site:

Editor Workspace: We will create new folder in PROD for each site with name (Editor Workspace), when we will deploy the report in PROD after Qa, and assign the report for UAT (User Accepting Testing).

Version: We will create new folder in each site, we will place the old report in Version folder when we deploy the report in PROD’s final folder and replace old one.

How do I move all the things?

Once we’ve decided on a process to migrate the workbooks, the next step is to determine how we will be migrating them across the environments. Below we will outline the options that are available and then discuss how to choose the right one for migration.

Migration options:

There are a few different options for migrating the workbooks. There are trade-offs to each and we will discuss the pros and cons of each. Currently, the options available for migrating the workbooks and data sources are:

1- Tabcmd Script
2- REST API
3- TabMigrate
4- Enterprise Deployment Tool (EDT) by InterWorks

Check List for all the above option:

Check List

Tabcmd

Tabcmd is the utility that comes with Tableau and allows us to interact with Tableau Server through a command line. By using tabcmd within a script, we can migrate our workbooks. We simply do a “tabcmd get” from the source and “tabcmd publish” to your destination.

Sounds easy enough, right? The challenge is that if We need to make any changes, like modifying data sources, we’ll have to programmatically manipulate the. twb XML (Tableau report), which is very error-prone.

Tabcmd also does not carry over permissions for the workbook and you must manually apply permissions to the new workbook.

Another limitation is that tabcmd’s publish will fail if there are two live data-source connections in the workbook.

Tableau REST API

An API is a programming interface and the REST simply denotes the way in which a programmer interacts with the API. Tableau’s API allows a programmer to interact with Tableau Server through various API calls. Like tabcmd, we may “get” and “publish” workbooks and data sources, but unlike tabcmd, we can also set permissions programmatically.

The largest drawback to using the REST API is that it we will have to develop the entire process code.

TabMigrate

TabMigrate is an open-source project released by Tableau and is a software utility created by Tableau developers to migrate workbooks and data sources. We can use TabMigrate as is, or, TabMigrate has a minimal UI that allows us to export all the workbooks and data sources from one server to a local folder then upload those files to another server. We can manually do transformations on the files once We have them in our local folder. There is some editing of XML and other files required to configure the migration.

TabMigrate makes it possible to do repeatable bulk migrations as well as limited transformations, like data source replacement. One limitation of TabMigrate is that it does not set permissions on migrated data sources.

Enterprise deployment tool (EDT)

Enterprise deployment tool (EDT) is a third-party software tool for doing workbook and data source migrations. EDT has a wizard-type interface that walks you through selecting workbooks, applying transformations, setting permissions, then deploying your workbooks and data sources. It also includes rollback functionality, letting your rollback an entire deployment if you use its archive workbook feature.

EDT allows you to save your migrations and rerun them later or execute them from a command line or via script.

EDT is the most full-featured option on this list, but it’s also the only one we must purchase, which is its biggest limitation.

What’s the right decision? Decision is yours !!

The right decision is what works best for us. The first step we need to take is to understand our needs. Start by considering these questions.

1-How many workbooks or data sources we are deploying? How much time is required?

2-Are we using separate projects, sites, or Tableau Servers as our environments?

3- Do we have separate data sources for each environment? For example, the test environment uses a separate database than the development environment.

4- Are any transformations being applied during the migration?

The more complex your deployment scenario, the good option is to write the scripts process necessary to do the deployment. As your deployments get larger and more complex, it makes sense to begin looking at TabMigrate and EDT to see which one will best suit your needs.

If you find it useful, do clap and share it among your enthusiastic peers.

More to come! Stay tuned, and thanks for reading :)

Happy Learning !!

--

--