5 Replies Latest reply on Jul 15, 2013 11:37 AM by Sam Gechter

    Server instances best practices?

    Tim Kuhns

      In our organization it is a standard to have four server instances for code development environments.  They are development, test, stress test, and production.  I am curious to know what others are doing as best practice for environments for Tableau.  Seems there might be a different approach for Tableau given we do not develop code in Tableau.  Our needs are to create vis, test vis for both function and performance, and to promote fully developed and tested vis to a user space.  Do other do that using projects within Tableau server or some other means.   

        • 1. Re: Server instances best practices?
          Joshua Milligan

          Tim,

           

          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.

           

          Regards,

          Joshua

          • 2. Re: Server instances best practices?
            Russell Christopher

            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.

             

            HTH!

            • 3. Re: Server instances best practices?
              David Rowland

              Hey Russell,

               

              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.

               

              Thanks,

               

              David

              • 4. Re: Server instances best practices?
                Russell Christopher

                Hi David!

                 

                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).

                 

                Now, onward:

                 

                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!

                • 5. Re: Server instances best practices?
                  Sam Gechter

                  Tim -

                   

                  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.

                   

                  Sam