Previewing Changes Before Pushing to Production | Sisense for Cloud Data Teams

With the Git Integration, analysts may want to develop a workflow where they can preview all of their changes in the Sisense for Cloud Data Teams application before publishing for all of their end users to see. Below is the suggested workflow for this use case.

Note: This solution requires the Git integration, 2 spaces and recommends the Slack Integration. The Git integration, Spaces and the Slack integration are add-on features. Site administrators can reach out to their Account Manager for more information.

Overview

There will be 1 space dedicated to development and 1 space dedicated to production. The development space should only be visible to analysts and editors. The production space will be used for external use and end users.

Each space will be connected to their own separate Git repositories. One repository cannot be connected to two different spaces in Sisense.

All changes in the development space will be migrated to the production space with this solution. Be sure that the entire development space looks exactly how the production space should look before migrating. After the migration, both spaces will be identical to each other. There should be no changes made directly on the production space or repo for this workflow to work, all edits in the production space should be copied from the development space.

The Slack Integration is recommended in order to be notified of any errors during the process. Errors can also be found as Git Tags in the repositories. If any errors occur during the process, resolve the errors before continuing. Check the bottom of the Git Integration page for more details on troubleshooting Git.

Steps

Make edits and preview changes in the development space. Be sure to be on the periscope/master branch.

Run git pull in the development repository.
Make desired changes in the development repository and git push to origin in order to preview any changes in-app.
Be sure to run git pull after any pushes, and if there are changes made in-app that need to be synced to the repository.

Once the development space and repository are in the desired state, it is ready to be copied over to the production space.

Run git pull in the production repository.
Delete all dashboard directories in the production repository. DO NOT commit or push after deleting.
Copy all dashboard directories from the development repository to the production repository.
Commit and run git push to origin once the production repository looks identical to the development repository.
Run a git pull.
Observe changes in the production space.

Note: The hash token appended to the end of directory names is automatically generated by Sisense. In this use case, the development version of a dashboard should always have the same token as the production version of the dashboard.
Do not delete dashboards from the production space and then run git push. Pushing dashboard deletions from the production repository and then trying to copy it back from the development repo will change the 32 character token appended to the directory name. This can lead to unexpected behavior between the two dashboard versions. This workflow requires that the suggested steps be strictly followed in order to produce the expected behavior.

‍