CODEWITHSUNDEEP
deploymenttableau-api
Kotvitsky Peter
Kotvitsky Peter

Reputation: 3

How to optimize deployment strategy for Tableau dashboards?

We have two environments (TEST and PROD) to publish dashboards to. Data for those envs resides on the same RDBMS server, 1 schema per env. And we want to publish 1 dashboard to 2 envs, so that 1 dashboard looks at TEST schema, and the other looks at PROD schema.

That's the approach we came up with, but it's not working as expected: we can not find a way how to deploy Tableau dashboard to 2 envs (and use 2 separate schemas) without actually maintaining 2 versions of the same dashboard (one for TEST and one for PROD).

So either we chose a bad deployment strategy for Tableau, or we're doing smth wrong with it. Could anybody please share your experience on how to deploy Tableau dashboards to separate envs without having to manually edit dashboard for every env? Or what's the problem with our approach?

Upvotes: 0

Views: 982

Answers (2)

Ly Phan
Ly Phan

Reputation: 1

Your situation sounds like mine. I need to publish exact same report to different environments using different server/database configuration. This is what I do:

  1. Maintain single source of truth, which is production version.

  2. Create an utility converting report to different environments. You can also do it manually as following:

    • Save your workbook (Tableau file) as .twb
    • Open twb file with any text editor. It is xml like. Tableau creates connection and renders graphic from this information.
    • Text search for username, server, port ... You will see all your configuration information here.
    • Replace those information by target environment information.
    • Save and open it again using Tableau Desktop and publish.

  3. If you have automation tool like Jenkin, you can develop one click solution for deployment using Tableau commands.

Upvotes: 0

Sam M
Sam M

Reputation: 4166

You didn't specify your RDBMS in the question so my answer will make a broad statement that may not necessarily apply in your specific case.

I think you've chosen a poor approach for your testing and production database environments. Normally, test and prod are on completely separate database instances and in many cases, separate servers. Having them together on the same instance or server means you are using up production hardware resources during testing, with the possibility of locking up the server because of run away queries against the non-production schema. With a single instance, it would be very easy to bring your production instance down inadvertently or maliciously without even being logged into the production schema.

Your better approach is to have two separate database instances: one for test, one for prod. The two instances could be on the same server but are isolated db instances. Both instances have the same users and same schemas. Then you can easily point your Tableau data sources to the respective instances without needing to update your workbooks or keep two copies of each workbook. For example, if you are using Oracle, keep the TNS aliases the same on both Tableau servers but alter the connection details in tnsnames to point to either the test or prod db server.

Upvotes: 2

Related Questions