I've typically found that two environments -- Development/Test environment and a Production environment is sufficient for the needs of most of our clients. Using sites on Tableau Server would be another good way of providing an environment for development and testing prior to a production release. That would allow for a limited set of users to be involved in development, testing, and user acceptance testing.
Hey Tim -
When one buys a license for Tableau Server, you're generally allowed to install it 3 times with only one of the instances allowed to be prod.
So, I generally see folks install dev / qa / prod as "3 servers" is the path of least resistance. Customers will then use a combination of our tabcmd tool and their SC solution of choice to create a script which "gets" and "publishes" workbooks from one environment to another.
Thanks for the useful info. How do we set up the non-prod servers such that they don't count towards using the license that we intend to use for prod? Let's say I have a 8-core license, I don't want my 4-core DEV box and 4-core TEST box to eat into the 8 cores that I need for prod.
Also, can we get access to any sample scripts that help with the "get" and "publish" operations that you refer to as we are going to need that set up too.
First, I must cover my behind:
You must check with your sales rep to find out if what I'm about to say applies to you (but it should).
The Tableau Server EULA (http://mkt.tableausoftware.com/files/eula.pdf section 3.3.1) allows you to run one production instance of Tableau Server and two non-prod instances (test & dev, for example).
Therefore you should be fine. Just install Tableau Server three times...prevent your users from ever hitting test & dev, and you're legal.
Finally, I cover the rear-end again:
Remember to check with your rep! I'm a technical guy, and a licensing guy!
We use three environments: production, test and dev. Production is production, test is where we test new workbooks or changes to workbooks, and dev is where we test new versions of Tableau itself before upgrading the test and production servers. We use trusted authentication to embed the workbooks in our web app, and always want to make sure that the new versions don't break either the views or the embedding - it has happened several times. The first time was when we only had production and test, and would try out new versions of Tableau on test. The first time that broke, we weren't able to publish new workbooks without going straight to production. So that's why we like to keep it separate - if a new version of Tableau breaks anything, it doesn't impact making changes to workbooks for existing clients or rolling out workbooks for new clients.