Skip navigation

A question was asked today on Twitter about the handling of production Tableau Server environments.  There were a variety of responses and they varied according to the needs of the particular company, thus there was no -- and never will be! -- one singly correct answer.  However, I did notice that there were those who were not employing their Tableau Server environment in accordance to Tableau's EULA (End User License Agreement)   Tableau only allows the following:

  1. One production environment:  Where content (workbooks, data sources, etc.) is published and consumed in ALL ASPECTS, be it QA/testing, user acceptance, and production usage.
  2. Two non-production environments:  Where software testing can take place.  For example, new software version testing and/or beta testing.  I believe very specific trouble-shooting can happen here if it would normally impact the production environment.

(Like how I used a numbered list that matches the EULA requirements?  )

 

In a nutshell

What this means is that Tableau does NOT allow the common SDLC usage of non-production report testing (QA/DEV) in one server environment and then pushing production-ready reports into another, separate [production] server environment.  All QA/DEV and PROD work must happen in a single Tableau Server environment!

 

Oops and now

Well, we used to follow the common SDLC as that is what is used by our Cognos team and what the prior BI supervisor expected.  It wasn't until some time later, during a move from a single node to a 2-node environment, that we discovered we were not following the EULA   Our Tableau sales reps were very understanding in allowing us time to make the change.  Luckily, due to the self-service process already in place there was very little consternation and my end users took to the new process quite rapidly   When our 2-node environment was switched over, becoming our production environment, we implemented our new Tableau BI paradigm, the continuously-improving life cycle a.k.a. CILC.

 

How CILC came into being was driven by me but decided by my end users.  Yep, I gave all 200+ publishers the option to vote on the method they wanted to employ!  I've attached the two page document I sent to my publishers, SDLC_Proposition.docx.  I briefly explained what was going to happen and gave five options on how to begin the new SDLC.  They were given ample time to respond and provide any feedback.  These were their options:

  1. Have a QA Site and a PROD Site
  2. Have a QA Project and a PROD Project
  3. Use a suffix or prefix on workbook names to designate QA or PROD
  4. No QA on the Tableau Server at all.  Instead, have a "continuously improving", or agile, PROD Server.
  5. A combination of any of the above.

 

The overwhelming vote was for #4 with only one needing to have separate QA and PROD areas (I had them use option #2; this was before child Projects were implemented in TS).  Technically speaking, there's nothing stopping Project Owners from implementing options #2 (as child Projects in our latest version of TS) & #3 if they wanted and this works just fine within the spirit of CILC. 

 

I thus began working on what "continuously improving" meant and how to convey it to my end users.  The below document is what came about after the voting.  Since my end users are notorious for not reading emails and documentation...or at least not reading them comprehensively...I had to keep it short, providing just the necessary info.  This is one of the first documents my users need to read when they are granted the site role of Publisher.  It's also attached if you want to copy and use it in your own organization.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

The Tableau Self-Service & CILC Paradigm

By Toby Erkson, Tableau Administrator, February 2018

With our multi-node environment we are truly an organization that functions in the self-service and continuously-improving life cycle methodology.

What does this mean?

Well, by using Tableau you are already involved in self-service BI (business intelligence reporting).  It basically means you don’t have to rely on another team or person to create your reports because you can easily do it yourself.

What does continuously-improving life cycle mean?  This is where we’re making a slight change to what is called the software development life cycle, or SDLC, which is how tradition BI reporting works (think Cognos). This is basically what it looks like:

Many of you are used to creating a workbook (Design & Develop), publishing it to the QA Server (Develop & Testing), getting end user acceptance (Testing), and then publishing to the PROD Server for production use (Deploy & Maintenance). Well, this is going to change just a little bit…

The QA Server as you know it in the SDLC is gone.  This is 100% driven by the end user license agreement (EULA) from Tableau because they consider how we were using the QA Server as a production environment and the EULA only allows for one production environment[1].

 

So what you will now be doing is what I’ve termed continuously-improving life cycle, or CILC for short (pronounced silk).  You will develop the workbook in Tableau Desktop and when it gets to the point where it’s working for the end user you will publish it directly to the production server (PROD Server).  The end user can use it immediately and if it needs updating/tweaking/maintenance you will make the necessary changes and publish over it, thus creating a revision history.  Rinse and repeat.  This is similar to agile software development and is actually not uncommon in other companies that use Tableau for enterprise reporting.

 

Not too crazy about this? Does it seem too millennial?  Fear not!  You have options to revert back to a more traditional SDLC:

  • Add a suffix or prefix to the workbook name that designates it as a QA report.
  • Set its permissions such that only certain people can see and interact with it while it’s in the UAT phase.
  • Create a sub-project for QA that has greater permission restrictions.  Once the workbook is ready for production usage you simply move it from the QA sub-project to the production project.
  • Or implement a combination of the above options.

It’s up to you or your Project Leader or Project Owner to decide upon the particular development life cycle you wish to implement, SDLC or CILC, as there is no wrong way thanks to Tableau’s fast and flexible reporting environment.

-- End Of Document --

 


[1] We are allowed two non-production environments.  For example, testing Tableau Sever software before implementing it into production.