We had this same discussion at the OEM meetup at TC16. It isn't a Tableau specific problem. We run into it with numerous tools across our various solutions.
Our approach is to prevent clients from modifying the standard content. In reality, on premise clients can create all sorts of problems if they want, but we STRONGLY suggest that they create copies and modify those.
We completely replace the existing workbooks when we deploy content, so any changes to those will be lost.
The downside is that the client will need to copy and make those modifications to the new version if they want or need our enhancements.
Michael Kovner: Having a diff/compare tool for new versions might be an interesting new project. I think Cognos provides something like that.
Hi James - Thanks for sharing this. This is indeed a problem when bringing in third party applications for us. Not as big an issue for our native code as we have a (somewhat) working solution for locking down Core code that clients are not able to modify. Perhaps the solution would be if Tableau supported a notion of signing/tagging objects so that they can only be modified with a key. Or maybe it is just a read-only attribute that requires a site admin to disable.
A diff tool would be great too. At least that would allow our clients to inspect the deltas to proactively determine what to do.
Reading both your posts together. , how do you push the new content ?
Do you do it or is it done by the Client, through the tableau server after setting up the Data Connections ?
Hi Chandra - I've been away from this forum for a little while and hope I can still continue the discuss here. I am not entirely sure I understand your questions but I will do my best in answering them.
We software package content changes into a file (or multiple files) that licensed clients can download from a secure FTP site. Client implementers then GET those files and store them in their local environment. Then they use our installer tool that ultimately calls Tableau command line APIs to publish the new content into their local server environment. For some of our clients they will do this work on their own, others may use our services team or engage a third party implementer.
Locally our clients need to go through a similar process, when promoting changes from Dev > UAT > Prod. The only difference is that instead of us supplying them the package they will save it from their own lower environment for publishing in higher envs. When deployed in their Dev env, they may make customizations to the package we ship.