Tableau development environment setup alternatives with and without Data Migration from Development to Production
Development, Test, QA and PRODUCTION – With Data Migration
Description: Common names for environments for Tableau development 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 either as separate projects or as different sites on the same Tableau Server instance. Or each one might be a separate instance of Tableau Server.
Development and Deployment Flow:
Below is a simplification of the workflow. Realistically you will have a back-and-forth between the QA analyst and developer as issues are found.
On Tableau Desktop (Local):
- Developer creates workbook or data source
- Developer tests workbook or data source for correctness
On Development Site
- Developer publishes workbook or data source to development environment of Tableau Server
- Developer tests workbook or data source in development environment.
On Test/QA Site
- Developer pushes to test environment of Tableau Server
- QA analyst tests workbook or data source in test environment
On Production site:
- Release manager pushes to production environment
- Release manager does final testing on production environment
(Source: Tableau Community)
Once you’ve decided on a process to migrate your workbooks, the next step is to determine how you 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 you. The first step you need to take is to understand your needs. Start by asking these questions:
- How many workbooks or data sources are you deploying? How much time is required?
- Are you using separate projects, sites, or Tableau Servers as your environments?
- Do you have separate data sources for each environment? For example, the test environment uses a separate database than the development environment.
- Are any transformations being applied during the migration (e.g. watermarking workbooks)?
- Do you have a software developer available to help with your project?
- The more complex your deployment scenario, the harder and longer it will be to write the scripts 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.
Development, Test, QA and PRODUCTION – Without Data Migration
You can keep 3 environments Test, QA and Production for every project or you can create sites for Test, QA and Production (all three) and sometimes only on Test and QA. You can assign your team according to business needs and site roles (you want to provide). Sometimes you don’t want groups to use production, they can use tableau public server for prototyping in this case.
Developer creates a workbook or data source in tableau desktop. Then developer test workbook or data source for correctness in tableau desktop. After testing on tableau desktop, we publish them to test (this is for development stuff) and then for UAT we publish same report to QA and our testing team perform performance testing on it, when developer get sign off from testing team, then they can request same UAT contents to move to production and on this request we add one of our team member as an additional approver, so when that request comes to QA team we review its content size and performance from their end and either approve or reject it. Here there is no involvement of any of the migration (site/workbook/view/project/data source).
On production site:
We will ask developer to list down all the components which are supposed to be moved to production. Then we will ask the user about the time barrier within which they want us to make changes to the tableau production server. After we approve all the changes done by developer in Test and QA, Release Manager or User will now publish these listed workbooks/data source to production site during change time window. And when change time window finishes project manager will verify that only listed reports/data source are published to production.
Regarding projects setup it is site admin’s responsibility how they want to set it up. They can have multiple projects within one site and it’s not necessary same projects will be on other environments. For example, assume we have HR group we created HR site on all three (TEST, QA and PROD) and HR Site Admin will divide their reports into multiple projects like HR_EMP, HR_ADMIN, HR_FINANCE etc. And they will have same setup in all three TESTs, QAs and PROD environments. So same report published from desktop only to all three, no data migration used.
Other Approach – Uploading Workbooks Directly
This approach is to create multiple project names on the different servers as TEST, STAGING or PRODUCTION.
As we proceed through the different workbook development phases i.e. TEST, STAGING and PRODUCTION, we name the workbook with a prefix of the project name e.g. “Test-Workbook Name” and when we get to Production, we just name the workbook as the “Workbook Name“. Realistically we will have a back-and-forth between the QA analyst and developer as issues are found.
The reason for having different names is that even though you can publish one workbook with the same name to multiple projects, the project is not like a folder on a file share. Publishing under different projects seems to me to be just an attribute of the workbook name. As a result, a change to the workbook and then publish just to one workbook under a project results in the views changing on the other workbooks (with the same name) that reside in other projects.
With having a unique name for all published workbooks means that they are not shared but treated as their own unique workbook. As a result, I can publish a workbook to Production but work on new enhancements under the Test project and not affect the Production workbook until I publish and overwrite current version.